Ответы ICMP - входной или выходной интерфейс (например, из traceroute)
Когда трассировка инициируется и получает ICMP-ответ от узлов, интерфейс которых
- должен быть ответ в соответствии с RFC 1812.
- они фактически отвечают от входа (где они получают пакет) или выхода (где пакет был бы отправлен - то есть к следующему узлу, если ttl был выше)
Личные комментарии и исследования:
- Согласно опубликованным слайдам NANOG, RFC 1812 утверждает, что это должен быть выходной интерфейс. Я прочитал раздел ICMP в RFC 1812 и не смог найти, где в нем говорится (я подозреваю, что мое понимание терминологии неверно).
- Я прочитал ответ различных маршрутизаторов (Junos, Cisco) с разных интерфейсов, но большинство из них ответили на входную форму ответа (как указано в слайде NANOG 10).
У меня нет виртуальной лаборатории Cisco, и я не думаю, что у меня достаточно оперативной памяти для настройки нескольких виртуальных маршрутизаторов в VirtualBox.
1 ответ
Привет, я опоздал, но если вам все еще интересно...
Цитата из слайда R Steenbergen NANOG верна. Поведение определено в Разделе 4.3.2.4 RFC1812, в котором говорится:
IP-адрес источника в сообщении ICMP, отправляемом маршрутизатором, ДОЛЖЕН быть одним из IP-адресов, связанных с физическим интерфейсом, по которому передается сообщение ICMP.
В зависимости от реализации Traceroute ответом на трассировку может быть недоступность получателя ICMP (т. Е. Трассировка, реализованная в Unix) или превышение времени ICMP (трассировка, инициированная Windows). Я считаю, что это освещено в презентации Стинбергена. Поскольку ни в одном из этих разделов не содержится каких-либо положений для указания исходного адреса ответа ICMP, мы предполагаем, что раздел 4.3.2.4 относится к этим конкретным типам ответов.
Представьте себе этот сценарий и предположите следующее:
- Предположим, что все ссылки между кругами (маршрутизаторами) являются равными по стоимости связями уровня 3 (в частности, что связь между R1 и R2 не является LAG/EtherChannel/ и т. Д.)
- Маршрутизация в пределах примерной сети такова, что пакеты отправляются от Отправителя 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,