Назад | Перейти на главную страницу

Пинг работает примерно через 30 секунд

Сегодня я работаю над этим вопросом, и мне бы очень понравились ваши идеи.

Есть сеть с примерно такой

LAN 1 - КАНАЛ WAN --- LAN 2

LAN 1 состоит из двух сегментов.

Когда я делаю пинг из LAN 1 сегмента 1, он работает как шарм.

Когда я делаю пинг из LAN 1 сегмента 2, у меня нет пинга, но примерно через 30 секунд непрерывного пинга (ping -t) он начинает работать идеально. После некоторого времени бездействия с целевым хостом проблема возникает снова.

Отслеживание пакетов маршрута останавливается на последнем маршрутизаторе перед целью. Это первый маршрутизатор в LAN 2 после канала WAN.

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

заранее спасибо

Есть ли в вашем WAN-канале прозрачный мост? Я видел эту проблему, когда прозрачный мост не может передавать ARP. Проверьте режим "обучения", если это так. В моем случае я устанавливал прозрачный мост pfsense, соединяющий серверы с остальной частью офисной локальной сети с помощью pfsense, и мне пришлось переключить режим обучения с внешнего на серверную сторону (или наоборот - туманная память).

Иногда это может произойти, если эхо-запрос проходит через устройство сетевой безопасности. В некоторых случаях проверка связи по имени DNS запускает фильтр URL-адресов на устройстве UTM. Получение положительного или отрицательного ответа может занять несколько секунд, что приводит к задержке в ICMP. После получения положительного ответа последующие эхо-запросы разрешены до истечения таймера. Эта логика зависит от того, как настроена политика безопасности.

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

Шаги по устранению неполадок:

  1. Ping LAN 2 с самого шлюза. Посмотрите, можете ли вы проверить связь с устройством, используя контекст сегмента 2.
  2. Захватите трафик как от pinger, так и от pingee, затем сравните дампы. Посмотрите, сколько времени есть задержка между отправкой пингера и получением. Если это всего лишь миллисекунды, то с обратным ходом что-то не так. Если это 30 секунд, значит какое-то промежуточное устройство задерживает трафик.

ДЕРЕВО?

Если возможно, проверьте Остовное дерево, если устройство в вашей сети выполняет связующее дерево, это может привести к тому, что порт (ы) будут переведены в состояние блокировки. Ваш коммутатор или маршрутизатор должен выполнить все шаги: блокирование, прослушивание, состояние обучения, прежде чем он будет перенаправлять трафик. Это действительно около 30 секунд.

Отключение Spanning-tree или настройка Portfast на необходимых портах может решить проблему.