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

Ответы ICMP - входящий или выходной интерфейс (например, из трассировки)

Когда трассировка инициируется и получает Ответ ICMP от узлов, интерфейс которых

  1. должен ли отвечать в соответствии с RFC 1812.
  2. они на самом деле отвечают от входить (где они получают пакет) или выход (где пакет был бы отправлен - то есть на следующий узел, если бы ttl был выше)

Личные комментарии и исследования:

  1. Согласно NANOG опубликовал слайдыRFC 1812 утверждает, что это должен быть выходной интерфейс. Я прочитал раздел ICMP в RFC 1812 и не смог найти, где это говорится (подозреваю, что я плохо понимаю терминологию).
  2. Я читал ответы различных маршрутизаторов (Junos, Cisco) с разных интерфейсов, но большинство ответов входило в форму (как указано на слайде 10 NANOG).

У меня нет виртуальной лаборатории Cisco, и я не думаю, что у меня достаточно оперативной памяти для настройки нескольких виртуальных маршрутизаторов в VirtualBox.

Привет, я опаздываю, но если тебе все еще интересно ...

Цитата из слайда R Steenbergen's NANOG верна. Поведение определяется в Раздел 4.3.2.4 RFC1812, в котором говорится:

IP-адрес источника в сообщении ICMP, отправленном маршрутизатором, ДОЛЖЕН быть одним из IP-адресов, связанных с физическим интерфейсом, по которому передается сообщение ICMP.

В зависимости от реализации Traceroute ответом на трассировку может быть ICMP Destination Unreachable (то есть трассировка, реализованная в Unix) или ICMP Time Exceeded (трассировка, инициированная Windows). Я считаю, что это освещено в презентации Стинбергена. Поскольку ни один из этих разделов не предусматривает указания адреса источника ответа ICMP, мы предполагаем, что раздел 4.3.2.4 применим для этих конкретных типов ответов.

Представьте себе этот сценарий и предположим следующее:

  1. Предположим, что все ссылки между кругами (маршрутизаторами) являются ссылками уровня 3 с равной стоимостью (в частности, что ссылка между R1 и R2 не является LAG / EtherChannel и т. Д.)
  2. Маршрутизация в примерной сети такова, что пакеты идут от отправителя S к получателю R по нижнему пути и возвращаются по верхнему пути в указанных направлениях.

Traceroute в современных реализациях будет выглядеть так:

traceroute to R 
 1  A 0.329 ms  A 0.425 ms A 0.471 ms
 2  C 0.349 ms  C 0.435 ms C 0.473 ms
 3  F 0.359 ms  G 0.445 ms F 0.481 ms
 4  R 0.369 ms  R 0.455 ms R 0.491 ms

И трассировка, если бы маршрутизаторы были закодированы в соответствии со спецификацией, выглядела бы так:

traceroute to R 
 1  B 0.329 ms  B 0.425 ms B 0.471 ms
 2  D 0.349 ms  E 0.435 ms D 0.481 ms
 3  H 0.369 ms  H 0.445 ms H 0.491 ms
 4  R 0.389 ms  R 0.455 ms R 0.496 ms

Таким образом, в более разговорном смысле современные реализации рассказывают нам, как мы достигли определенного хоста. В исходной спецификации говорилось, как мы покинули маршрутизатор, но не говорилось, как мы туда попали.

Обратите внимание, что мы можем подумать, что это вызовет сбой Ping, но в спецификации этот случай явно рассматривается:

IP-адрес источника в эхо-ответе ICMP ДОЛЖЕН быть таким же, как
адрес конкретного пункта назначения соответствующего эхо-запроса ICMP
сообщение.

Другими словами, для Ping адрес источника эхо-ответа ICMP не должен быть адресом, связанным с выходным интерфейсом, как указано в разделе 4.3.2.4, а должен вместо этого использовать адрес источника, полученный из адреса назначения исходного эхо-запроса ICMP. .