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