Хронометраж ситуации с отключением оптики на коммутаторе провайдера основного канала:
Первый пинг снаружи на WAN1 пропал в 11:44:30
Первый пинг снаружи на WAN2 пропал в 11:44:30
Основной маршрут отключился в 11:44:54
Первый пинг снаружи по WAN2 появился в 11:44:57
Дальше оптику подключили обратно через минуту-две (это делал не я, посему точно сказать не могу).
Первый пинг снаружи на WAN1 появился в 11:47:15. Но, как-то очень не стабильно. Потери были порядка 70-80%. Видимо оптический канал "стабилизировался"..
Основной маршрут активировался в 11:50:14
По пингам ситуация стабилизировалась с 11:50:17

Вот, примерно такая цепь событий.


syslog ситуации прилагаю. С 11:44:30 до 11:50:14.

у них один коммутатор на двоих ?

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

И еще.
Так же я поставил пинговаться оба шлюза обоих провайдеров из локальной сети.
И что интересно, шлюз для WAN2 (резервный провайдер) из локальной сети пиновался абсолютно стабильно вплоть до 11:45:04! Т.е. до момента переключения на резервный канал!

Нет конечно! У них у каждого всё своё: приходящая оптика и коммутатор!
Я ж не настолько прям... ну это...))

Могу приложить статистику по пингам в этот период, как снаружи, так и из локалки.. если нужно..
Пинги в обоих случах на шлюз для WAN1 и WAN2.

Вот, буквально 10 минут назад опять отвалился инетрнет. Пропало аж 11 пакетов подряд.. примерно на пол минуты.. Соответственно, упала и телефония...
В логах переключений на резервный маршрут нет. Вообще никаких записей RFO нет.

ну тут , наверное последнее .....
брать L2 коммутатор . ставить перед DFL , зеркалить порты , и ...... ждать .
у меня идеи кончались , по полной

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Самое интересное, что такая же ситуация была и на DFL-860e! А DFL-870 я поставил всего как неделю.
Но, больше всего меня мучает момент, почему при отваливании канала на WAN1, у меня перестают отвечать снаружи WAN2 на какое-то время? При этом, изнутри он пингуется..

Подключаем любой терминал. Например putty по rs232, в настройках для надежности включаем еще и логгирование в файл. Уходим. Когда-нибудь приходим и смотрим в этом файле сообщения от system

Интересно а такие сообщения по snmp ссыпятся? Тогда вообще не проблема, любую ловушуку поставить и гулять, придти разобрать.

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Скорее всего крэши (на то они крэши) не вылетят по snmp. Поэтому самый-самый из доступных первоисточников - именно консоль по RS232. Там можно увидеть то что происходит еще до загрузки ядра - т.е. до того как подгрузятся модули сети, проинициализируют интерфейсы и т.п.

Я не против. Я уже подключил консоль на COM-порт.
А дальше куда там идти? как смотреть?
Я попадаю в обыкновенное консольное меню для настройки маршрутизатора.. как при том же SSH доступе.
Сорри, но я с консолью не дружу совсем. Не работал никогда.

Все почти так, только в консоли по rs232 можно увидеть процесс загрузки ядра и даже вмешаться (но там мало что можно сделать)
Туда же в консоль пишутся всякие проблемы.
Ну и в итоге в момент пропадания связи/подвисания - можно увидеть что-нибудь аномальное, что происходит вне работы самого софта файера.

параметры мониторинга?
это скорее всего из-за параметров мониторинга
но не так давно участвовал в сборке перекрестной схемы vpn failover, в местном представительстве Длинк
были подобные "чудеса" из-за мониторинга, причем это не диагностировали, просто на это указал спец. длинка, при этом когда параметры поправили, схема стала отрабатывать мгновенно

и роутин руле тоже в студию

в вашем логе почему-то нет событий conn_open/conn_close

Фишка в том, что я мониторинг вообще отключал. Изменений не происходило.
Вчера поздно вечером решил потестить, как будет система работать, если сделать основным маршрутом WAN2. Тупо в таблице маршрутизации выставил меньшее значение на маршруте через WAN2.
Началась какая-то жесть вообще! Потеря пакетов порядка 15-20% стабильно! При этом, отклики, что приходят - от 4 до 10мс, не более.. Вернул приоритет на WAN1 - ситуация стабилизировалась.. Я уже вообще ничего не понимаю

Насчет событий conn_open/conn_close. Я оставил в syslog только:
0. Emergency
1. Alert
2. Critical
3. Error
4. Warning
5. и добавил по просьбе коллег 41 RFO.

Если нужно что-то добавить - скажите, я добавлю.


Таблицу маршрутизации прилагаю. Она очень простая.