Как работает mikrotik netwatch?

Question

[Виталий]

Всем доброго!
Как то в гугле не нашел :(
Мне интересно как работает утилита netwatch в mikrotik? У меня на ее основе стоит переключения между провайдерами, но что то часто она у меня срабатывает... Сколько пакетов должно реджектнутся чтобы состояния переключилось на "down" или оно срабатывает даже если пропал один пакет? И если ето так (статус "down" после одного утраченого пакета), то что будет лучше по производительности (что меньше грузит систему) , написать собственный скрипт (аля netwatch, но с переключениям после заданого количества потерь) или все же стандартная netwatch ?

Answer 1

[Александр Романов]

Здравствуйте. Нетвоч срабатывает при потере одного пакета. Переключение провайдеров делается средствами маршрутизации, без скриптов и нетвотчей. А последний правильно использовать исключительно для оповещения.

Comments

[HawK]

С помощью средств маршрутизации переключение провайдеров будет работать, только если провайдерский шлюз окажется недоступен. Как быть, если шлюз провайдера доступен, но из-за каких-либо проблем у провайдера доступ в интернет через провайдерский шлюз отсутствует?

[Александр Романов]

HawK: используйте рекурсивную маршрутизацию с проверкой шлюза. В кратце говорю об этом в выступлении в Иркутске: mum.mikrotik.com/2016/RUI/agenda

[HawK]

Рассматривал и опробовал этот вариант и другие, замечательно и молниеносно отрабатывает при потере доступности шлюза, Но он бесполезен в случае если шлюз доступен, а интернета за этим шлюзом нет, из-за каких либо проблем у провайдера. У нас это очень частая ситуация, поэтому используется менее изящное, но более надежное решение на все случаи жизни.

[Александр Романов]

HawK: как раз рекурсивная маршрутизация проверяет внешний ресурс. И если он недоступен – маршрут становится неактивным.

[Александр Романов]

HawK: делается это с помощью значений scope и target-scope в маршрутах. Посмотрите презентаху, я как раз в ней определяю доступность 8.8.8.8 через основного провайдера.

[HawK]

Александр Романов: У меня не получалось настроить надежное переключение между провайдерами этими сложными способами, поэтому на костылях все работает, но надежно. А рекурсивную маршрутизацию, опробую на досуге на стенде, попытки ранее были безуспешные)

[HawK]

Александр Романов: Разобрался с рекурсивной маршрутизацией, не нашел принципиальных отличий от моих "костылей". Те же пинги, те же изменения маршрутов. Однако, время не было потрачено даром, механизм был усовершенствован - резервные маршруты теперь всегда enable, но значение distance установлено большее чем у основных , а скрипт только disable/enable основные маршруты. Таким образом, при падении интерфейсов провайдеров, соответствующие маршруты становятся неактивными и переключения происходят мгновенно и не нужно ждать интервала опроса netwatch. В итоге, результат достигается точно такой же как и в случае использования рекурсивной маршрутизации, плюс в моем случае происходит более точная проверка доступности интернета, за счет использования двух независимых адресов (у гугла или, скорее, на каком-нибудь транзитном узле тоже могут быть проблемы). Не нашел для себя аргументов менять настройки, ради достижения того же результата. Спасибо Вам, узнал для себя много нового.

Answer 2

[HawK]

Можно написать отдельный скрипт, но проще в netwatch настроить дополнительную проверку. Для повышения точности проверки доступности интернета, для исключения ложных переключений, например, при возможных проблемах на опрашиваемой стороне или кратковременных сбоях в сети, потерянных пакетах и т.п. — используется 2 независимых проверочных адреса (можно использовать адреса различных публичных dns, например Google и Yandex) — x.x.x.x и y.y.y.y Адрес x.x.x.x — указывается в настройках хоста Netwatch, если пинга нет — начинает работать «down», который делает 5 попыток пинга к y.y.y.y и если все 5 попыток также неудачны — скрипт продолжает работу и активирует/деактивирует маршруты в соответствии с comments в таблицах маршрутизации. Первая удачная попытка прерывает дальнейшее выполнение скрипта, при этом никаких изменений маршрутов или других действий не происходит. К этим проверочным ип-адресам прописаны статические маршруты через шлюзы соответствующих провайдеров, а в фаерволе добавлены правила, запрещающие исходящий пинг на эти адреса через другие интерфейсы.
В скрипт добавлен вывод сообщений в лог, а также отправка СМС с информацией о том с каким провайдером и в какое время возникла проблема. Отправка СМС реализована с помощью сайта sms.ru.
api_id=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX — уникальный id — выдаваемый при регистрации на sms.ru
to=79********* — номер телефона, на который осуществляется отправка СМС. Если в качестве номера указывается тот же, что и при регистрации на сайте — 5 СМС в сутки бесплатно.
Вот мой вариант конфига:

«down»:

/log warning "server x.x.x.x fail…"
:local time [/sys clock get time]
:local checkip [/ping y.y.y.y count=5]
:if (checkip = 0) do={
/log error «ISP1 IS DOWN»
/ip route set [find comment="main"] disabled=yes
/ip route set [find comment="reserve"] disabled=no
:delay 1
/tool fetch url="http://sms.ru/sms/send?api_id=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX&to=79*********&text=ISP1_IS_DOWN_$time" keep-result=no
}

«up»:

/log warning «ISP1 IS UP»
/ip route set [find comment="main"] disabled=no
/ip route set [find comment="reserve"] disabled=yes

Comments

[Александр Романов]

Вот зачем людей неправильным вещам учите? Не говорю, что это не будет работать, но это, извините, велосипед на костылях.

[Александр Романов]

Оповечать нетвотчем можно. Кстати, вместо громоздкой команды удаления файла, добавьте к fetch после ссылки keep-result=no, и файл даже не будет создаваться

[HawK]

За keep-result=no спасибо, поправлю. Просто я не нашел за много лет другого способа, кроме как эти "костыли", чтобы гарантировано определять пропадание интернета, а не доступности шлюза, поделитесь вашим опытом, если не секрет)

[Виталий]

HawK: У меня скрипт тоже похож на Ваш, но вместо смс, отправляю mail. Тоже вначале хотел средствами маршрутизации, даже стаття у них на wiki есть, но что то оно не совсем хорошо работало :(

[Владислав Созонтов]

Александр Романов: Александр, можете предложить более оптимальный вариант определения пропадания интернета и переключения на резерв?

[Александр Романов]

Владислав Созонтов: я не Роман.

[Александр Романов]

https://mum.mikrotik.com/2016/RU/agenda/EN
Выступление Андрея Сычёва. Всё по делу.

[Владислав Созонтов]

Александр Романов: Александр, прошу прощения за невнимательность. Не узнал Вас сразу. Спасибо за MTCNA и за дельный совет)

Answer 3

[kiranananda]

Кстаити на последних версиях прошивки можно настроить netwatch и icmp что бы он посылал не один пакет а например 10 и срабатывал только при 90% потерь...