Mikrotik Scripting отсылка команд на управляемые свичи

[Senter]

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

Собственно есть 2 провайдера(вообще можно на 1 рассматривать или на 3 или больше, но это к делу отношения не имеет), одна подсеть и 2 Mikrotik.
На Микротиках первый порт настроен на 2 vlan(для приема провайдеров), второй порт под локальную сеть, 3 порт под управление. 1 и 2 порты на микротиках имеют одинаковые mac(соответственно портам естественно). Суть в том, что Slave через 3 порт периодически проверяет(arp-ping) жив-ли Master, если Master не отвечает, то гасит на свиче порты в которые подключен master(кроме управляющего) и поднимает порты к которому подключен Slave. Если Master снова отвечает, то возвращает порты в предыдущее состояние. Вопрос только в том, как реализовать управление свичем(telnet/snmp) средствами Mikrotik, может кто подскажет варианты?

P.S. Отправлять письмо на сервер, который по его получению переключит порты свича не вариант.

[vqd]

ни как.

Только я понять не могу. Зачем схема такая?

VRRP + резервирование скриптом на микротах

[Senter]

Есть решение на скриптах, но там тоже много заморочек.

Схема такая: Есть Master и Slave на 1-3 портах одинаковые mac, 5 порт под управление. Slave проверяет состояние master, если он не доступен(предположительно сломался полностью) активирует свои порты. Но если Master не полностью сломался(выгорел порт, или пользователь кабель выдернул), получим ситуацию что в сети будет и Slave и Master, как итог коллизии и ничего не работает, поэтому master тоже проверяет доступен-ли Slave и если не доступен(порт выгорел или пользователь кабель выдернул), то выключает у себя порты с 1 по 3. Но тут появляется ситуация, что из строя вышел Slave, тогда Master посчитает его недоступным и выключит свои порты с 1 по 3 в итоге сеть не работает.
Про vrrp уже была тема, он не дает предсказуемого времени переключения, плюс возвращаясь к скриптам, сели на Master настроить master-интерфейс vrrp, то скриптом нельзя будет отслеживать его состояние(он всегда будет MR).

В схеме со свичем Master ничего не знает про происходящее вокруг(ну максимум может проверять жив-ли slave и оповещать, если нет), можно не использовать vlan на портах, тогда при выходе из строя свича достаточно сказать пользователям куда переткнуть кабеля.

[vqd]

Ну это смотря как вы выполняете проверку ))) Если использовать ARP то конечно

[Senter]

Ну а как еще? Если использовать обычный ping(или кидаться файликами по ftp/ssh), то та-же ситуация.

[vqd]

ну обычный пинг через нужные каналы наружу
Анализ таблицы соединений

В принципе первый способ вполне внятно работает. Вторым в данный момент занимаюсь, но там в проекте нужно максимально быстрый вывод канала из агрегации. 10с который я сделал с помощью пингов не прокатили в том проекте, надо не более секунды добиться

[gmx]

Есть еще вариант - третий микротик, который только пингует и включает/выключает PoE на нужном порту и больше он ничем не занят. Соответственно, при включении резервного, обязательно выключается порт основного и наоборот.
Есть еще специальные устройства для этого - NetPing.

[Senter]

ну обычный пинг через нужные каналы наружу
Анализ таблицы соединений

В принципе первый способ вполне внятно работает. Вторым в данный момент занимаюсь, но там в проекте нужно максимально быстрый вывод канала из агрегации. 10с который я сделал с помощью пингов не прокатили в том проекте, надо не более секунды добиться

Тут именно аппаратное резервирование, Одновременно с интернетом(и сетью) работает только одна из железяк(с обоими провайдерами), так что ping на ружу немного не то.

Есть еще вариант - третий микротик, который только пингует и включает/выключает PoE на нужном порту и больше он ничем не занят. Соответственно, при включении резервного, обязательно выключается порт основного и наоборот.

Третьего микротика(с несколькими POE) в наличие нет, а вообще думал в подобном ключе: подключать Master через POE Slave, если перестает пинговаться. то просто гасится POE и поднимаются порты, но как Slave узнает, что Master снова работает(без ручного включения POE) и опять-же, если Slave выходит из строя нужно напрягать пользователей и перетыкать питание в Master.

[vqd]

Ну опять же решений несколько
Например получить у оператора дополнительные ИП

Опять же в вашем случае вы хотите резервировать железо по большей части. То есть если у вас канал сдох и мастер это видит то передергивать роутеры смысла нет

[Senter]

Опять же в вашем случае вы хотите резервировать железо по большей части. То есть если у вас канал сдох и мастер это видит то передергивать роутеры смысла нет

Master и Slave соединены кабелем напрямую и проверяет состояние друг-друга по этому кабелю, так что если отвалится один из каналов во внешний мир переключения не произойдет.