Как трассировка всегда может достичь последнего маршрутизатора перед пунктом назначения, независимо от того, где вы проводите тест в сети?

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение к вашей ситуации
Рекомендации

Вопрос или проблема

У нас есть периодическая проблема в сети, которая возникает между маршрутизаторами A и B. Маршрутизатор A находится ближе всего к шлюзу.

Когда возникает проблема, A не может пинговать B и наоборот. Если я получаю доступ к маршрутизатору B через out of band management, трассировка обратно по сети к шлюзу дает странные результаты.

Прыжки выглядят следующим образом от маршрутизатора B: RouterB -> RouterA -> R1 -> R2 -> R3 и т.д.

Трассировка до R3 возвращает:
RA -> Ответ.
R1 -> Ответ.
R2 -> Ответ.
Тайм-аут

Трассировка до R2 возвращает:
RA -> Ответ.
R1 -> Ответ.
Тайм-аут

До R1 возвращает:
RA -> Ответ.
Тайм-аут

Это не имеет для меня смысла. Как R2 может отвечать, когда трассировка идет на R3, но не отвечать, когда он является конечной точкой трассировки?

Эта проблема приходит и уходит без каких-либо изменений конфигурации в сети.

Как я понимаю ваш вопрос, всегда отсутствует последний ICMP echo reply, в то время как промежуточные сообщения ICMP time exceeded работают.

Возвратные сообщения Traceroute различаются. Похоже, есть прыжок, который отбрасывает возвращаемые echo replies, в то время как другие ICMP сообщения пересылаются. Я бы провел трассировку пакетов на упомянутых маршрутизаторах, на обоих интерфейсах, и, конечно, проверил бы логи.

Как R2 может отвечать, когда трассировка идет на R3, но не отвечать, когда он является конечной точкой трассировки?

В первом случае он на самом деле не отвечает на пакет. Он отправляет индикацию ошибки относительно невозможности дальнейшей доставки пакета. Разница в том, что R2 не был пунктом назначения зонда, и первоначальное содержимое пакета не имело значения; они не стали причиной реакции.

На самом деле нет никакого конкретного запроса или ответа трассировки – инструмент traceroute работает исключительно, собирая такие ошибочные ответы.

В то время как в последнем случае пакет был доставлен успешно, и R2, будучи фактическим получателем, теперь должен обработать его на более высоком уровне протокола. Например, если это ICMP Echo Request – “пинг” – маршрутизатор сейчас должен специально ответить на этот пинг. Если это был UDP-зонд, маршрутизатор должен ответить “Port unreachable.” Он может быть настроен не отвечать на пинги, а также может иметь заблокированные UDP-порты через брандмауэр.

Ответ или решение

Для решения поставленной задачи важно внимательно разобраться в работе протокола traceroute и в специфике проблемы, возникающей на вашем сетевом оборудовании.

Теория

Traceroute — это сетевой инструмент, используемый для отслеживания маршрута пакетов данных от источника к назначению. Основной принцип работы traceroute основывается на изменении значения поля Time-to-Live (TTL) в заголовке присланного IP-пакета.

Вот как это работает:

Изменение TTL: Traceroute посылает серию пакетов к целевому узлу, начиная с минимальными значениями TTL, например, 1, 2, 3 и так далее.
ICMP Time Exceeded: Каждый маршрутизатор на пути уменьшает TTL на единицу. Когда TTL достигает 0, маршрутизатор отбрасывает пакет и посылает обратно ICMP-сообщение "Time Exceeded" к отправителю.
Определение маршрута: Хост определяет IP-адреса маршрутизаторов, основываясь на этих ICMP-сообщениях, пока не достигнет конечного назначения.

Traceroute продолжает увеличивать TTL, пока не достигнет целевой машины. Когда пакет попадает в целевую точку, она отвечает ICMP Echo Reply (в случае использования ICMP) или "Port Unreachable" в случае использования UDP.

Пример

В вашей проблеме traceroute возвращает неожиданные результаты, когда вы пытаетесь отследить маршрут между разными узлами, такими как R1, R2, и R3, начиная с Router B и возвращаясь к Router A. Общая схема такая же:

Router B → Router A → R1 → R2 → R3

Однако вы сталкиваетесь с тем, что имеются ICMP ответы с устройств, когда R2 и R3 не должны давать ответ по указанной причине.

Применение к вашей ситуации

Для анализа проблемы важно понимать, что происходит следующее:

Проблемы с ICMP: Пакет ICMP может не доходить или не уходить назад из-за фильтрации ICMP ответов на одном из маршрутизаторов, что объясняет, почему вы не получаете ответы от R2 и R3. Иногда маршрутизаторы или сетевые устройства программируются игнорировать или фильтровать определенные виды ICMP. Таким образом, они могут отвечать сообщениями "TTL Expired", но игнорировать или блокировать ICMP Echo Request и другие ICMP ответы.
Проблемы на уровне конфигурации или сети: Могут быть временные проблемы с маршрутизацией, настройками межсетевого экрана, которые приводят к тому, что одни ICMP сообщения проходят, а другие нет. Возможно, в сети есть политика, которая блокирует конкретное направление трафика или имеется другое ограничение на передачу данных, влияющее на работы маршрутов.