Недавно я провел в свой офис оптоволоконный кабель, и, за исключением некоторых странных проблем, все работает хорошо, а скорость работы сети просто потрясающая.
Проблема в том, что время от времени мой маршрутизатор отваливается и теряет пакеты. Это не линия и не коммутатор. Это сам маршрутизатор, и я поменял оборудование, и оба устройства делают это. Часть оборудования, которую я использую, это Juniper Netscreen SSG5. Вот симптомы:
Я делаю pingflood на «внутренний» интерфейс, с
ping -f -c 10000 <internal-ip>
и я получаю 10 000 ответов. Каждый раз. Затем я делаю то же самое, только с IP-адресом внешнего интерфейса (но все еще на том же устройстве). Он теряет где-то от 10 до 15 пакетов из 10 000. Я провел тот же тест на каждом другом шлюзе в компании, и больше ничего не показывает такого поведения. Я в недоумении.
Я общался с поддержкой оптоволоконной компании, и оба наших интерфейса жестко запрограммированы на 100 Мбит с полным дуплексом, если это вообще может быть причиной проблемы. Кстати, при пинговании внешнего интерфейса изнутри маршрутизатора я никогда не теряю пакеты, что заставляет меня думать, что это не сам интерфейс. И локальный интерфейс никогда не теряет пакеты, так что это не коммутатор.
Честно говоря, я не уверен, где может быть проблема, кроме как в конструкции самого оборудования. Я смотрел графики, и даже во время pingflood я даже близко не приближаюсь к максимизации ЦП или памяти на маршрутизаторе.
Какие-либо предложения?
Редактировать
Для Тома: Оптоволокно 13 Мбит/с, но когда я пингую интерфейс, он не переходит на оптоволокно. Локальная локальная сеть работает на скорости 100 Мбит/с, и внутренний интерфейс отвечает на каждый пакет. Мне нужно будет посмотреть, смогу ли я одолжить другое оборудование, но у меня есть несколько старых моделей Juniper (5GT) на разных сайтах, которые не показывают тех же симптомов.
решение1
Имейте в виду два момента:
- Маршрутизатор, скорее всего, будет ограничивать направленный на него ICMP-трафик, хотя я не знаком конкретно с SSG5.
- Скорость пересылки 140 Мбит/с предполагает, что трафик идетчерезмаршрутизатор; трафик адресованкмаршрутизатор вызовет дополнительное снижение производительности, поскольку каждый пакет будет передаваться в собственный IP-стек маршрутизатора и потребует генерации ответного пакета.
Вот несколько тестов, которые стоит попробовать:
- Попробуйте выполнить pingflood из вашей локальной сетичерезмаршрутизатор; возможно, удаленный конец канала WAN? (Я предполагаю, что это будет что-то с большей вычислительной мощностью, если оно принадлежит вашему поставщику услуг.)
- Бегатьiperfмежду узлом в вашем офисе и чем-то внешним в Интернете, чтобы получить хорошее представление о том, к чему вас готовят.
решение2
Просто идея.. Но какова скорость оптоволокна? Может ли объединительная плата маршрутизатора на самом деле перемещать пакеты на такой скорости? У меня была похожая проблема с заполнением буферов Ethernet на Cisco 857 путем максимального использования соединений на портах коммутатора.
Работает ли SSG5 на последней версии ScreenOS? Последние обновления прошивки?
В спецификации указано, что он может передавать 140 Мбит или 30 тыс. пакетов в секунду. Так что, возможно, это не так, но, возможно, более мощный маршрутизатор справится с трафиком?
Не могли бы вы одолжить у кого-нибудь устройство большего размера? Возможно, Cisco 2811 или Juniper J2320?
решение3
У нас были похожие проблемы, когда мы перешли на оптоволоконный/метро Ethernet (AT&T).
Интерфейсы вашего маршрутизатора показывают какие-либо ошибки? Мы используем Cisco и увидим ошибки CRC или ввода, в зависимости от интерфейса.
В конце концов мы решили эту проблему, переключая различные методы согласования между автоматическим, 10/половинным и полным и 100/половинным и полным для каждого из наших местоположений, пока либо автоматический, либо 100/полный не «застрял». Вы также можете попросить своего провайдера временно снять ограничение в 13 Мбит/с, чтобы проверить, связана ли проблема с ограничением пропускной способности.
AT&T обвинила в этом коммутаторы, которые они использовали (тоже Cisco), но не стала менять их на альтернативные модели. Мы перестали беспокоиться, пока не перестали получать ошибки и 100/full заработал (либо с помощью жесткого кодирования, либо с помощью автоматического согласования).
По сей день в некоторых офисах у нас все еще есть автоматическая система, а в некоторых — 100-полная, просто потому, что она работала, и мы не хотим ее ломать.