Мониторинг перехода на резервный канал.

[teamkoff]

Добрый день, имеется большая сеть из нескольких десятков коммутаторов l2-l3 cisco. Физически два интернет канала находятся в разных концах города и постоянно активны. в случае выхода из строя до первого канала трафик начинает ходить через второй. Как заставить забикс отправлять сообщение о том, что маршруты изменились и трафик начал идти через второй канал.

[tuban]

Добрый день, имеется большая сеть из нескольких десятков коммутаторов l2-l3 cisco. Физически два интернет канала находятся в разных концах города и постоянно активны. в случае выхода из строя до первого канала трафик начинает ходить через второй. Как заставить забикс отправлять сообщение о том, что маршруты изменились и трафик начал идти через второй канал.

Создать триггер, если на первом канале загрузка упала, либо упал порт, а на втором поднялась = alarm.

[sadman]

Вопрос в том, как физически выглядит переключение. В случае с падением нагрузки логика определения слишком нечетка. Например ночью (или в иной период) наступит затишье на канале - будет ли это свидетельствовать о смене маршрута?
Если решать вопрос быстро и незамысловато, то я бы отслеживал появление в выводе tracert появление гейтов того или иного провайдера.

[teamkoff]

Решил пока сделать проще, обьем трафика проходящего через резервный канал превышает объем трафика проходящего через основной канал = alarm

[Zentarim]

Добрый день, имеется большая сеть из нескольких десятков коммутаторов l2-l3 cisco. Физически два интернет канала находятся в разных концах города и постоянно активны. в случае выхода из строя до первого канала трафик начинает ходить через второй. Как заставить забикс отправлять сообщение о том, что маршруты изменились и трафик начал идти через второй канал.

Если у вас каналы на разных провайдерах организованы через разные vlan-ы и, соответственно, разные IP адреса (через динамическую маршрутизацию), то вы можете просто пинговать адреса, принадлежащие vlan-ам, с которыми связаны операторы.
в zabbix-е это штатно реализуется через два интерфейса. Данная схема протестирована и работает уже много лет.

Поскольку неизвестна топология вашей сети, посоветовать что-то более правильное невозможно.

[sadman]

...то вы можете просто пинговать адреса, принадлежащие vlan-ам, с которыми связаны операторы.
в zabbix-е это штатно реализуется через два интерфейса. Данная схема протестирована и работает уже много лет..

Это если gw первого провайдера не пингуется через второго и интернет.

[Zentarim]

Это если gw первого провайдера не пингуется через второго и интернет.

Я предлагаю пинговать непосредственно подключенный к провайдеру интерфейс. Ответы на все пакеты, направленные адресу этого интерфейса будут отправлены во vlan, к которому он привязан. А раз связи нет - ответы там и застрянут, пинг пропадет.

UPD: Если хотя бы на одном конце интерфейс будет поднят и будет распространяться - то схема сработает. Если упадет линк - там все от топологии уже будет зависеть.

[sadman]

Давайте l2 с l3 не мешать. У нас же не arp-ping. vlan вычеркиваем.

                    [chan1] 10.11.12.2 <-[a]-> 10.11.12.1 [isp1 gw] <--> [ white routers] 
                        |                                                          | 
[zabbix] <--> [internal router]                                                    |
                        |                                                          |
                    [chan2] 13.14.15.2 <-[b]-> 13.14.15.2 [isp2 gw] <--> [ white routers]

Допустим, что все адреса белые. [internal router] переключает каналы.

Положим, что [chan1] активен, [chan2] ожидает. Пинг от заббикса проходит на 10.11.12.1? Проходит через [chan1].
Произошел разрыв в точке [a]. "Упал" [chan1], [internal router] сменил гейтвей, "поднялся" [chan2]. Пинг будет проходить на 10.11.12.1? А куда он денется? Пойдет через [chan2] и [ white routers]. А если провайдеры пирятся, то пакеты только просвистывать будут.

Хорошо, будем пинговать 10.11.12.2. И он будет пинговаться вплоть до смерти [internal router] - это же его физ-интерфейс. Ну, изменился gw с isp1 на isp2, но интерфейс же активен.

Или я что-то неправильно понимаю, если схема работает годами?

[Zentarim]

Или я что-то неправильно понимаю, если схема работает годами?

Я вам свою топологию не показывал. Автор темы свою вроде бы тоже не раскрывал, а описал в очень общих чертах. О своей и о предложенной вами топологии я спорить не собираюсь. Мне кажется, что стоит подождать появления автора, который сможет уточнить необходимые детали.

P.s. Относительно вашей топологии все верно. В этом случае надо прибить два статических маршрута через двух провайдеров к заведомо поднятым адресам (к примеру 8.8.8.8 и 8.8.4.4) И упавший пинг до одного из них покажет вам сдохшего провайдера.

Однако автор темы упоминает несколько десятков коммутаторов. Поэтому непонятно - с какой стороны канала у него находится сервер ну и т.д.

[Zentarim]

Хорошо, будем пинговать 10.11.12.2. И он будет пинговаться вплоть до смерти [internal router] - это же его физ-интерфейс. Ну, изменился gw с isp1 на isp2, но интерфейс же активен.

Кстати это не всегда так. По крайней мере на catalyst, если во vlan-е не остается активного физического интерфейса, логический тоже отключается. В случае с отключенным switchport поидее должно произойти то же самое.

[tuban]

Меж тем, автор слился.
Если строить триггер на загрузку менее 1Кбит/с, то он не будет срабатывать ложно. А если падает порт - все проще.
Вариант с пингом неплох, если на сети не настроена балансировка трафика. Так что, не зная топологии проще всего строить триггер на основании загрузки. Хотя, если Т.С покажет топологию сети, возможно появится более изящное решение.

[rough-84]

Не проще сделать маленький скрипт, который будет лесть в инет и давать инфу о том какой сейчас внешний ip. Если у Обоих провайдеров статика, то сделать триггер будет элементарно. Я так мониторию смену ip у виртуалок в azure, даже не знаю зачем правда, програмеры почему то не пользуются dns именем...