Страница 1 из 1

Между двумя микротиками не проходит ping, но работает traceroute

Добавлено: 27 мар 2020, 10:58
Santechnick
Ситуация: два микротика соединены через сеть провайдера. На обоих один из интерфейсов с серым провайдерским IP смотрит в сеть провайдера, прописана статическая маршрутизация для этой сети. Все работало полтора года. На микрот1 настроен netwatch, который пингом каждые 10 секунд проверяет доступность микрот2. Вдруг netwatch на микрот1 заявляет, что микрот2 недоступен. Из терминала ping IP_mikrot2 выдет 100% потерь при любом размере пакета и любом TTL. В обратную сторону (с микрто2 на микрот1) все работает. traceroute также выдает доступность хостов по ICMP в обоих направлениях. Фильтров на ICMP нет на обоих микротах и никогда не было, конфигурация не менялась полтора года.
При этом, пинг с компа, который находится в локальной сети за микрот1 и работает через маскарадинг на микрот1, до микрота2 доходит нормально.
Подкиньте идеи, куда смотреть, кроме перезагрузки микрот1 - в ближайшую неделю сделать это не могу.

Re: Между двумя микротиками не проходит ping, но работает traceroute

Добавлено: 27 мар 2020, 11:15
Chupaka
Ну, я бы посмотрел через Tools -> Torch на интерфейсы с обеих сторон: улетают ли пакеты пинга куда надо и прилетают ли в цель. Ещё можно в Firewall -> Connections найти и удалить этот ping, если он там есть. Или хотя бы приостановить netwatch на пару минут, чтобы connection пропал по таймауту

Re: Между двумя микротиками не проходит ping, но работает traceroute

Добавлено: 30 мар 2020, 11:55
Santechnick
Спасибо! Полтергейст продолжился: стоило глянуть в торч, с обеих сторон увидел все пакеты. И тут же заработал пинг и нетвоч, как ничего и не было. Спишу это на глюк микрот1, других идей нет.

Re: Между двумя микротиками не проходит ping, но работает traceroute

Добавлено: 30 мар 2020, 14:16
Chupaka
Ну, вполне вероятно, что это не глюк, а поведение из-за специфической ситуации. Вы FastTrack используете (есть в файрволе такие правила)? Применение Sniffer или Torch на интерфейсе временно выключает FastTrack, это могло как-то сбросить "залипшее" соединение. А залипнуть оно могло из-за какого-нибудь кратковременного изменения роутинга (флапнулся интерфейс или что-нибудь похожее).