+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Netwatch на ROS7 — ложное отключение?

Netwatch на ROS7 — ложное отключение?, RouterOS

RandyRiver88

Guest

16.11.2022 02:42:00

Привет, у меня проблемы с новым Netwatch. Я пытаюсь отслеживать, работает ли мой Wireguard-VPN и проходит ли через него трафик. Создал простой статический маршрут для, например, 8.8.8.8/32 через Wireguard-шлюз и второе правило для 8.8.8.8 как "черная дыра". Использую ICMP-проверку в Netwatch. Настроено так: Хост: 8.8.8.8 Интервал: 00:01:00 Интервал пакетов: 1.00 Количество пакетов: 10 Порог по потерям: 10 Netwatch случайным образом сообщает, что хост недоступен (DOWN). При проверке статуса последней проверки вижу: Отправлено пакетов: 10 Получено ответов: 10 Потерь: 0 Процент потерь: 0% Как думаете, что может быть не так? Я использую версию 7.7 b6, но эта проблема была и в предыдущих релизах, можно даже сказать, с тех пор, как ввели новый Netwatch. Делаю ли я что-то неправильно или это действительно баг? Я также тестировал с 1.1.1.1, 9.9.9.9, 8.8.8.8 и другим публичным сервером — результаты похожие и нестабильные, на трёх разных роутерах и локациях. Вот пример с 9.9.9.9 при интервале 5 минут:

Статус: down С: 15 ноября 2022, 21:44:24 Выполнено тестов: 274 Провалено тестов: 23 Отправлено пакетов: 60 Получено ответов: 60 Потерь: 0 Процент потерь: 0.0% Среднее время отклика (RTT): 123.666 мс Мин время отклика: 82.502 мс Макс время отклика: 160.734 мс Джиттер: 78.232 мс Стандартное отклонение RTT: 17.151 мс

Статус: up С: 15 ноября 2022, 21:49:24 Выполнено тестов: 275 Провалено тестов: 23 Отправлено пакетов: 60 Получено ответов: 60 Потерь: 0 Процент потерь: 0.0% Среднее время отклика (RTT): 99.896 мс Мин время отклика: 61.099 мс Макс время отклика: 152.939 мс Джиттер: 91.840 мс Стандартное отклонение RTT: 21.360 мс

challado

Guest

11.08.2023 13:18:00

Я не согласен. Да, это космическая наука, потому что каждый поставщик по-своему понимает слова, природу, глобальное потепление и так далее. В инструкции просто написано «thr-loss-percent». Но ЧТО такое thr? Это среднее по всем тестам? Что это вообще? А thr-rtt-avg? Что это? И, понятно, эта информация скрыта в статусе. Отображается только базовая информация, и ты ничего не можешь с этим сделать, потому что не можешь угадать значения.

pe1chl

Guest

11.08.2023 13:52:00

Согласен, это действительно путанно и неполно. Как и во многих других главах в системе HELP, сразу начинается объяснение свойств без единого абзаца с общим описанием того, как всё должно работать вместе. Сначала, когда я увидел новые режимы в Netwatch, подумал, что смогу просто сделать обычную проверку пингом с каким-то порогом отказов. Например, хочу посылать по одному пингу в минуту, но считать систему "недоступной" только после трёх подряд необработанных ответов. Но, судя по всему, новый тип "icmp" именно так не работает, разве что очень тщательно настраивать конфиг. Он посылает 3 пинга подряд каждую минуту и сигнализирует, если ни один не отвечает, но при этом сложно сделать мониторинг, который, например, мог бы "проглатывать" перезагрузку удалённой системы и возвращаться в рабочее состояние в течение трёх минут. И если это вообще возможно, то мне придётся самому выстраивать нужные настройки.

Amm0

Guest

11.08.2023 15:19:00

Документация могла бы быть лучше — полностью согласен, не хватает пояснительного текста и примеров. Но настоящая проблема в том, что у всех ICMP-параметров есть значения по умолчанию, которые используются, если их не задать. Меня устраивают значения по умолчанию, НО для netwatch ICMP они слишком жесткие. Например, именно эти агрессивные настройки по умолчанию вызывают «ложные срабатывания» — а так как вы могли не менять проблемный параметр, понять, что не так, совсем непросто… И значения по умолчанию в интерфейсе тоже НЕ очень заметны, поэтому понять, что именно не проходит, очень сложно. На мой взгляд, лучше уж «ужесточать» настройки относительно более мягких значений по умолчанию, чем пытаться «угадать», насколько надо повысить параметр, чтобы он не падал. Мне нравится новый концепт сети, но согласен, что нужно поработать и улучшить документацию. И если использовать «type=simple», который тоже делает ping по ICMP, то этой проблемы можно избежать, если неважно мониторить метаданные пинга.

pe1chl

Guest

11.08.2023 16:07:00

Да, type=simple — это классический тип Netwatch: пинг отправляется каждые [interval] секунд, нет ответа — событие down. Мне бы хотелось простое расширение, которое позволило бы фиксировать «N пропущенных пингов» до объявления события down. То, что мы получили, оказалось сложнее, чем это, но его сложно приручить.

challado

Guest

19.08.2023 12:33:00

Я думаю, что «если значение не задано, Я НЕ БУДУ использовать эту метрику», но Mikrotik ставит там ЗНАЧЕНИЕ ПО УМОЛЧАНИЮ, и все метрики работают только с операцией И, а не ИЛИ. Проще говоря, это неэффективно и плохо продумано.

anav Guest	#7 0 19.08.2023 14:45:00 Это пинг NetWatch, чтобы заменить проверку через IP Routes? Другими словами, чтобы убедиться, что интернет действительно доступен через провайдера?

challado

Guest

21.08.2023 22:34:00

Anav, я не совсем понял твой вопрос, да и мой английский хромает. На самом деле, check-gateway=ping — хороший способ выявить проблемы с роутером, но… если проблема была ЗА роутером, он никогда не покажет пропадание соединения. У нас тут несколько таких проблем с двумя каналами для резервирования. Интернет пропадает, но гейтвей всё ещё активен, потому что проблема ПОСЛЕ гейтвея. В таком случае резервирование бессмысленно. Я использую netwatch, чтобы пинговать разные адреса (статические маршруты по link 1 или link 2) и понять, упал ли LINK1 или LINK2 (резерв) тоже. Но некоторые каналы — это STARLINK, и там пинг скачет по задержкам, но ПАКЕТЫ НЕ ПРОПАДАЮТ (связь есть, но работает плохо, а не ОФЛАЙН).

Amm0 Guest	#9 0 21.08.2023 22:47:00 Я отправил запрос на добавление функции для параметра /ip/route’s check-gateway=, чтобы он поддерживал «связь» с одной или несколькими записями netwatch (и любые допустимые вещи вроде http и icmp с jitter и другими статистиками). http://forum.mikrotik.com/t/feature-request-link-check-gateway-in-routes-to-a-netwatch-item-s/163771/1 Но на сегодня check-gateway=ping — это просто роутер следующего прыжка, и проверка другого IP не допускается (кроме использования рекурсивных маршрутов, с которыми вы знакомы).

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры