В моей организации есть Juniper SSG20-WLAN, который направляет наш трафик во внешний мир. У нас периодически возникали проблемы с нашим интернет-соединением, поэтому я написал скрипт Python для проверки связи внутреннего интерфейса маршрутизатора, внешнего интерфейса, пары наших внутренних серверов, маршрутизатора интернет-провайдера, с которым общается наш маршрутизатор, их вышестоящего провайдера, и Google и Yahoo для хорошей меры. Так происходит каждую минуту.
Я обнаружил, что когда наш интернет выходит из строя, наш маршрутизатор Juniper перестает отвечать на эхо-запросы внешнего интерфейса. Все, что было в прошлом, конечно, недостижимо. Внутренний интерфейс и наши внутренние серверы продолжают беспрерывно передавать эхо.
Ни один из счетчиков не показывает отброшенные пакеты любого типа. Все они выглядят нормально. Журналы жалуются на недоступность VIP-серверов, но в остальном ничего не указывает на проблемы с сетью.
Вот мои вопросы:
ОБНОВЛЕНИЕ: Оказалось, что один из переключателей между моим блоком мониторинга и маршрутизатором был самим маршрутизатором и иногда переключался со шлюза на себя. Престижность тем, кто сделал предложения в этом направлении. Не совсем уверен, какой ответ отметить как принятый, так как в комментариях действительно было то, что было правильным.
Спасибо за предложения.
Я работаю на интернет-провайдера, и что я могу рассказать вам о маршрутизаторах, которые мы предоставляем для наших T1, так это то, что когда интернет-соединение прерывается, он делает интерфейсы WAN и LAN нулевыми для ping. Мы не используем Junipers, но это относится к Cisco 1841s, samsung ubigate 1000s и netopias, которые мы используем. Это связано с тем, как предоставляется IP, и как маршрутизируемый блок предоставляется через WAN IP, что делает их недоступными без подключения к нашим основным маршрутизаторам.
Как часто случаются капли? Любой шаблон, который можно определить (время, загруженность трафика и т. Д.)? Проявлялась ли эта ситуация после определенного периода, когда что-то работало правильно в прошлом? Какой тип носителя используется у вас в WAN-интерфейсе (Ethernet, T1 WIC и т. Д.)?
Если это действительно Ethernet, вы можете проверить, настроен ли он для автосогласования. Если да, то вы можете попробовать «жестко закодировать» настройки линии, на всякий случай, если это проблема автосогласования, которая возникает достаточно часто.
Если это интерфейс T1, то вам следует начать с просмотра статистики / счетчиков T1 - поиска сбросов, FECN (прямое уведомление о явной перегрузке), BECN (обратное явное уведомление о перегрузке) и т. Д. Большое количество этих счетчиков может указывать на проблемы. с оператором связи (необходимо сбросить LMI, проблемы с настройкой LMI / кодировкой строк и т. д.).