Netwatch mikrotik не работает

Netwatch mikrotik не работает

Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов

Перестал запускаться скрипт

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

1. Назовите технологию подключения (динамический DHCP, L2TP, PPTP или что-то иное)
2. Изучите темку «Действия до настройки роутера».
viewtopic.php?f=15&t=2083
3. Настройте согласно выбранного Вами мануала
4. Дочитайте мануал до конца и без пропусков, в 70% случаев люди просто не до конца читают статью и пропускают важные моменты.
5. Если не получается, в Winbox открываем терминал и вбиваем там /export hide-sensitive. Результат в топик под кат, интимные подробности типа личных IP изменить на другие, пароль забить звездочками.
6. Нарисуйте Вашу сеть, рисунок (схему) сюда. На словах может быть одно, в действительности другое.

Здравствуйте
В моём RB951G в настройках Netwatch при событиях UP или DOWN запускались скрипты по команде —
/system script run name_script_up

Всё работало довольно долго и стабильно, но вот уже некоторое время (затрудняюсь точно сказать, но около двух месяцев) скрипты не запускаются.
В Netwatch события фиксируются. Сами скрипты кнопкой RUN запускаются.
В чём может быть причина ?

Здравствуйте
В моём RB951G в настройках Netwatch при событиях UP или DOWN запускались скрипты по команде —
/system script run name_script_up

Всё работало довольно долго и стабильно, но вот уже некоторое время (затрудняюсь точно сказать, но около двух месяцев) скрипты не запускаются.
В Netwatch события фиксируются. Сами скрипты кнопкой RUN запускаются.
В чём может быть причина ?

Источник

Netwatch mikrotik не работает

Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов

Netwatch, Help

Добрые день, нужна помощь.
Есть у меня Mikrotik RB951UI-2HND, в него подключен 3G Модем Huawei. Проблема в том что когда он зависает у меня срабатывает netwatch ребутает его по usb и он заново начинает работать отлично.(/tool netwatch add comment=Reboot_USB down-script=»system routerboard usb power-reset duration=10″ host=8.8.8.8 interval=5m),
только вот заметил такую проблему, что если он отключил usb и модем заново не поднялся, netwatch не пробует его перезагрузить еще раз через 5 минут,уходит в down и все!
Когда модем был просто включен в комп на прямую у меня работал в планировщике такой батник.

title Testing connection.
goto begin

:begin
cls
@echo Testing.
@ping -n 1 8.8.8.8 | find /I «TTL» > nul
@if ERRORLEVEL=1 goto error
@if ERRORLEVEL=0 goto ok

@echo Testing.
@ping -n 1 8.8.8.8 | find /I «TTL» > nul
@if ERRORLEVEL=1 goto error
@if ERRORLEVEL=0 goto ok

@echo Disabling interface.
@devcon disable «huawei_enum_vbus»
@timeout /t 3
@echo Enabling interface.
@devcon enable «huawei_enum_vbus»

@echo Testing.
@ping -n 1 8.8.8.8 | find /I «TTL» > nul
@if ERRORLEVEL=1 goto error
@if ERRORLEVEL=0 goto ok

@echo Testing.
@ping -n 1 8.8.8.8 | find /I «TTL» > nul
@if ERRORLEVEL=1 goto error
@if ERRORLEVEL=0 goto ok

@echo Disabling interface.
@devcon disable «huawei_enum_vbus»
@timeout /t 10
@echo Enabling interface.
@devcon enable «huawei_enum_vbus»

Помогите написать скрип на подобие того что у меня было в батнике.(Я не шарю в скриптах)
или расскажите как заставить netwatch делать ребут по usb до тех пор пока не появится связь.

Источник

Dual Wan и особенности реализации NetWatch в MikroTik

«Если в простой конфигурации микротик не работает, значит вы не умеете его готовить… или явно что-то упустили.»

Как работают вместе failover и netwatch. Взгляд изнутри.

Почти каждой более-менее подросшей компании начинает хотеться качества коммуникаций. Среди прочего, заказчику часто хочется отказоустойчивый «Dual WAN» и VoIP телефонию. Тоже отказоустойчивую, разумеется. Руководств и статей по каждой теме в отдельности написано много, но внезапно оказалось, что совместить первое и второе получается не у всех.

На Хабре уже есть статья «Mikrotik. Failover. Load Balancing» от vdemchuk. Как оказалось, она послужила для многих источником копипасты кода в маршрутизаторы.

Хорошее, рабочее решение, но SIP-клиенты из LAN, подключающиеся к внешней IP-АТС посредством NAT, при переключении теряли связь. Проблема известная. Связана она с работой Connection tracker, который запоминает имеющиеся соединения вовне, и сохраняет их состояние независимо от других условий.

Понять почему так происходит можно посмотрев на диаграмму packet flow:

Для транзитного трафика процедура обработки connection tracker выполняется всего в одной цепочке — prerouting, (т.е. до роутинга), до выбора маршрута и исходящего интерфейса. На этой стадии еще неизвестно, через какой интерфейс пакет пойдет в Интернет, и отследить src-ip при нескольких Wan-интерфейсах невозможно. Механизм фиксирует установленные соединения уже пост-фактум. Фиксирует и запоминает на время пока через соединение идут пакеты или пока не истечет заданный таймаут.

Описанное поведение характерно не только для маршрутизаторов MikroTik, но и для большинства Linux-based систем выполняющих NAT.

В результате, при обрыве связи через WAN1, поток данных послушно направляется через WAN2, только SOURCE IP прошедших через NAT пакетов остается неизменный — от интерфейса WAN1, т.к. в connection tracker уже есть соответствующая запись. Естественно, ответы на такие пакеты идут на интерфейс WAN1 уже потерявший связь с внешним миром. В итоге, связь как будто есть, но на самом деле её нет. При этом все новые соединения устанавливаются корректно.

Hint: увидеть с каких и на какие адреса делается NAT можно в колонках «Reply Src. Address» и «Reply Dst. Address». Отображение этих колонок включается в таблице «connections» с помощью правой кнопки мыши.

На первый взгляд выход выглядит довольно простым — при переключении сбросить ранее установленные SIP-соединения, чтобы они установились заново, уже с новым SRC-IP. Благо простой скрипт по просторам интернета бродит.

Три шага к фейлу

Шаг первый. Копипастеры добросовестно переносят конфиг для Failover recursive routing:

Шаг второй. Отследить событие переключения. Чем? «/tool netwatch», естественно! Попытка отследить падение шлюза WAN1 обычно выглядит так:

«:5060»] do= <
:log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
/ip firewall connection remove $i>»
up-script=»:log warning («WAN1 UP»)
:foreach i in=[/ip firewall connection find dst-address

«:5060»] do= <
:log warning («clear-SIP-connections: clearing connection src-address:$[/ip firewall connection get $i src-address] dst-address:$[/ip firewall connection get $i dst-address]»)
/ip firewall connection remove $i>»

Шаг третий. Проверка.

Админ гасит первый аплинк WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!
Админ включает обратно WAN1 и вручную запускает скрипт. SIP-клиенты переподключились. Работает? Работает!

В реальной обстановке такой конфиг работать отказывается. Неоднократное повторение шага №3 приводит админа в состояние озлобления и мы слышим «Не работает ваш микротик!».

Разбор полётов

Всё дело в непонимании того, как происходит работа утилиты Netwatch. Применительно в отношении именно рекурсивного роутинга, утилита просто пингует заданный хост согласно основной таблице маршрутизации, используя активные маршруты.

Проведем эксперимент. Отключим основной канал WAN1 и посмотрим и интерфейс /tool netwatch. Мы увидим, что хост 8.8.8.8 по-прежнему имеет состояние UP.

Для сравнения опция check-gateway=ping, работает для каждого маршрута в отдельности в т.ч. рекурсивно, и делает сам маршрут активным либо НЕактивным.

Netwatch использует уже активные на данный момент маршруты. Когда что-либо происходит на линке до шлюза провайдера ISP1 (WAN1), маршрут до 8.8.8.8 через WAN1 становится неактивным, и netwatch игнорирует его, отправляя пакеты в новый default route. Failover играет злую шутку, и netwatch считает, что всё в порядке.

Второй вариант поведения netwatch, это двойное срабатывание. Механизм его таков: если пинги от netwatch попадут в таймаут check-gateway, то на один цикл проверки хост будет признан DOWN. Сработает скрипт переключения канала. SIP-соединения корректно перейдут на новый линк. Работает? Не совсем.

Скоро таблица маршрутизации перестроится, хост 8.8.8.8 получит статус UP, вновь сработает скрипт сброса SIP-соединений. Соединения второй раз переустановятся через WAN2.

В результате, при возвращении в строй ISP1 и переходе рабочего трафика на WAN1, SIP-соединения так и останутся висеть через ISP2 (WAN2). Чревато это тем, что при проблемах у на запасном канале система этого не заметит и телефонной связи не станет.

Решение

Для того, чтобы трафик на используемый для мониторинга хост 8.8.8.8 не заворачивался на ISP2, нам нужно иметь запасной маршрут до 8.8.8.8. На случай падения ISP1, создаем резервный маршрут с большим значением distance, например distance=10 и type=blackhole. Он и станет активным при пропадании линка до WAN1 Gateway:

/ip route add distance=10 dst-address=8.8.8.8 type=blackhole

В итоге имеем дополнение конфига всего лишь одной строкой:

Данная ситуация характерна именно при падении последней мили, когда шлюз ISP1 становится недоступным. Либо при использовании туннелей, которые более подвержены падениям в силу цепной зависимости.

Надеюсь, статья поможет вам избежать подобных ошибок. Выбирайте свежие мануалы. Будьте в курсе, и всё у вас «взлетит».

Источник

Netwatch mikrotik не работает

Mon Apr 23, 2018 8:57 pm

I posted this is General forum but think its more appropriate here:

I have this in my Down option:

Everything runs EXCEPT for the /system script run NoVpnReboot
The script does work when I run it from the terminal?

I’m running 6.42.1 RouterOS?

Any help really appreciated.

Re: Can’t launch script from Netwatch

Tue Apr 24, 2018 3:40 am

It might be something to do with this:

What’s new in 6.42 (2018-Apr-13 11:03):
netwatch — limit to read, write, test and reboot policies for Netwatch script execution;

I have just upgraded my router to v6.42.1 (due to the latest in a growing list of very troubling security flaws, thanks Mikrotik).
Netwatch was working fine until then. I find that I can still put an entry in a log file using Netwatch, but I cannot change a variable from a Netwatch script.

So I am guessing the issue is to do with permissions. I have no idea if these can be changed. I have not found a handle for it yet, if indeed this is the issue.

Perhaps someone else can enlighten us.

Re: Can’t launch script from Netwatch

Tue Apr 24, 2018 3:54 am

OK so in your particular issue, not being able to call a script, if you go to the script itself and uncheck all policy options with the exception of read, write, test and reboot, you should be able to call the script (it worked for me).

Assuming of course you script does not require other policy options to function correctly.

Re: Can’t launch script from Netwatch

Tue Apr 24, 2018 4:11 am

So my issue is still not resolved:

I am no longer able to change the value of a global variable from within Netwatch.

If I create a script to change the global variable, and call that from Netwatch, the global variable will not change unless the policy option «policy» is checked for the script.
I verified this by a manual run of the script.

Since Netwatch can now only call scripts that have (at most) policies «read», «write», «test» and «reboot» — the script will not call when I check the «policy» option, as is seemingly required in order to modify a global variable.

Intuitively I would have figured that the «write» option would be enough to allow us to change a global variable. However it is the «policy» option that appears to allow us to do this. Not sure if it has always been this way, or if it is a bug.

Anyhow it appears that the usefulness of Netwatch is somewhat limited moving forward.

Re: Can’t launch script from Netwatch

Tue Apr 24, 2018 12:51 pm

I have the same issue with netwatch on v6.42.1 (current).

Not able to write global variables by netwatch up or down event and scripts will not be launched.

Re: Can’t launch script from Netwatch

Tue Apr 24, 2018 2:39 pm

Thanks very much for he reply. I wound up putting my script in the down section. It’s not very large.

Is there a problem in doing that?

Re: Can’t launch script from Netwatch

Tue Apr 24, 2018 2:54 pm

Yes you can put the entire scripts in the NetWatch Up/Down script windows.

However in my case — writing to a global variable — this ceased to work with the new software version no matter whether I put the function in the NetWatch script window, or I called a script with the function in it, as explained above.

So I guess it is just a matter of what you are doing in the script — as some script permissions (functions) seems to have been removed for NetWatch.

Re: Can’t launch script from Netwatch

Tue Apr 24, 2018 4:03 pm

The time for a workaround and rewriting all other script is too high and I am using the scheduler instead netwatch. Don’t waiste time with netwatch!

Here the example for our case:

Re: Can’t launch script from Netwatch

Thu May 03, 2018 8:39 pm

So my issue is still not resolved:

I am no longer able to change the value of a global variable from within Netwatch.

If I create a script to change the global variable, and call that from Netwatch, the global variable will not change unless the policy option «policy» is checked for the script.
I verified this by a manual run of the script.

Since Netwatch can now only call scripts that have (at most) policies «read», «write», «test» and «reboot» — the script will not call when I check the «policy» option, as is seemingly required in order to modify a global variable.

Intuitively I would have figured that the «write» option would be enough to allow us to change a global variable. However it is the «policy» option that appears to allow us to do this. Not sure if it has always been this way, or if it is a bug.

Anyhow it appears that the usefulness of Netwatch is somewhat limited moving forward.

Источник