Привет. Это короткая заметка про то, какие именно IP мы видим в любимом tracert/traceroute, и как это зависит от лейбла на коробках в аппаратных вашего ISP и его апстримов.

Думаю, все знают, что у маршрутизатора, как правило, множество IP-адресов (ну или хотя бы точно больше, чем 1). В условиях такого многообразия перед маршрутизатором ставится нелегкий выбор: какой именно из его IP-адресов необходимо выбрать в качестве источника сообщения ICMP TTL Exceeded, которое и является основой для вывода трассировки?

Если вы никогда ранее не задумывались над данным вопросом, то вот некоторые варианты, которые могут прийти в голову в первую очередь:

1. IP-адрес интерфейса, который являлся входящим для оригинального пакета.
2. IP-адрес интерфейса, который должен был бы являться исходящим для оригинального пакета.
3. IP-адрес интерфейса, который будет являться исходящим для ICMP-сообщения.
4. IP-адрес лупбэка.

Если вы все же задумывались об этом ранее, то не спешите давать однозначный ответ :)

Для ответа на вопрос из названия публикации я собрал вот такую лабу в GNS3:



Некоторые пояснения к топологии:

1. Трассировка будет производиться от PC1 к PC2.
2. На каждом маршрутизаторе есть лупбэк вида X.X.X.X
3. На всех роутерах и всех интерфейсах запущен OSPF Area 0.
4. OSPF Interface Cost распределены таким образом, что трафик от любого роутера до 60.0.0.0/24 (сеть PC2) пойдет «вертикально», т.е. через цепочку оставшихся роутеров. И наоборот, трафик до 10.0.0.0/24 (сеть PC1) от любого роутера кроме Cisco1 пойдет через SW1 (что соответствует сети 123.0.0.0/24). Таким образом мы добиваемся ситуации, при которой входящий интерфейс оригинального пакета и исходящий интерфейс ICMP-сообщения не совпадают.

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

Ответ: Для OSPF это действительно не самая типичная ситуация, он использовался исключительно для упрощения конфигурации. В реальности за асимметрию путей вашего трафика в основном ответственен BGP.

Запускаем трассировку

Как вы можете видеть, Cisco и Juniper ответили с IP входящего интерфейса, тогда как Debian Linux и Mikrotik (имеющий тот же Linux в корнях своей операционки) ответили с IP интерфейса, который являлся исходящим для ICMP-пакета (123.0.0.X).

Record Route для сравнения:

Заключение

Поведение Linux и Mikrotik объясняется пунктом из RFC 1812. Этот пункт указывает, что source-адресом ICMP-сообщения должен являться адрес интерфейса, через который должен быть передан данный ICMP-пакет.

В это же время такие гиганты индустрии, как Cisco и Juniper, позволяют себе игнорировать указание RFC, очевидно полагаясь при этом на свой не дюжий опыт. И действительно, наблюдать в трассировке IP-адреса интерфейсов, через которые должен пройти оригинальный пакет, как по мне, видится более правильным решением, чем обнаруживать в той же трассировке IP из подсетей, строго говоря не имеющих к реальному пути пакета никакого прямого отношения.