Маленький, но гордый параметр, о котором стоит немного поговорить и посмотреть, как и при каких обстоятельствах мы можем его изменять.

Для начала нам необходимо выяснить, каким образом MikroTik выбирает себе IP адрес источника перед тем, как отправить пакет.

1. Если явно указан адрес источника. Вы можете указать src или local адрес в различных параметрах. Например при настройке GRE или IPIP туннеля, параметр local адрес отвечает именно за поле src в заголовке пакета. Если вы запускаете программу Ping, вы можете указать IP адрес источника.
2. Перекладывание на плечи ядру RouterOS выбор адрес источника src, если маршрутизатор генерирует какой-то трафик и при этом явным образом не указан адрес источника Пункт 1, то MikroTik начинает процедуру выбора IP адреса, и она зависит от таблицы маршрутизации.

И так для понимания приведём простой пример.

/ip route> print where !ospf !routing-mark # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S 0.0.0.0/0 10.188.48.1 1 1 ADC 10.188.48.0/22 10.188.48.99 ether1 0 2 ADC 10.199.1.1/32 10.199.1.2 l2tp-srv-01 0 3 ADC 10.255.200.1/32 10.255.200.2 ipip-trm 0 4 ADC 172.20.17.0/24 172.20.17.1 Bridge-Local 0

Перед вами таблица маршрутизации моего домашнего маршрутизатора, я убрал из вывода протокол OSPF и именованные таблицы маршрутизации, чтобы не было простынки 400 маршрутов.

Когда вы назначаете IP адрес на интерфейс, RouterOS автоматически создаёт connected маршрут, до сети, которая высчитывается из адреса и маски, которую вы указали при назначении IP адреса, а также устанавливается параметр pref-src, который соответствует непосредственно назначенному IP адресу

Если у вас несколько IP адресов из одной подсети, то параметр pref-src будет назначен, самой первой записи IP адресу, обратите внимание ни самому низкому IP адресу, а к тому IP адресу, который был первый назначен на интерфейс.

Теперь попробуем запустить ping до адреса 10.255.200.1

> /ping 10.255.200.1 SEQ HOST SIZE TTL TIME STATUS 0 10.255.200.1 56 64 4ms 1 10.255.200.1 56 64 4ms sent=2 received=2 packet-loss=0% min-rtt=4ms avg-rtt=4ms max-rtt=4ms

Как видите ping прошёл, теперь взглянем на нашу таблицу маршрутизации и найдём наилучший маршрут для IP адреса 10.255.200.1

3 ADC 10.255.200.1/32 10.255.200.2 ipip-trm 0

Так как при запуске ping мы явно не указали с какого IP адреса отправлять пакет, то ядро RouterOS выбрало наилучший маршрут для IP адреса назначения, и в данном маршруте указан параметр pref-src, именно такой IP адрес был использован при генерации пакетов.

Попробуем явно указать IP адрес, маршрут до которого на хосте 10.255.200.1 отсутствует.

> /ping 10.255.200.1 src-address=10.188.48.99 SEQ HOST SIZE TTL TIME STATUS 0 10.255.200.1 timeout 1 10.255.200.1 timeout 2 10.255.200.1 timeout sent=3 received=0 packet-loss=100%

Как видите, к нам не возвращается пакет, так как на хосте 10.255.200.1 маршрут до адреса 10.188.48.99 не соответствует интерфейсу до нашего маршрутизатора. По простому он улетает куда-то не туда.

А теперь попробуем сделать ping до хоста 8.8.8.8

> /ping 8.8.8.8 SEQ HOST SIZE TTL TIME STATUS 0 8.8.8.8 56 46 6ms 1 8.8.8.8 56 46 6ms sent=2 received=2 packet-loss=0% min-rtt=6ms avg-rtt=6ms max-rtt=6ms

Взглянем на таблицу маршрутизации и определим наилучший маршрут для адреса 8.8.8.8

0 A S 0.0.0.0/0 10.188.48.1 1

Pref-source не указан, так какой IP адрес будет выбран тогда?

А здесь кроется маленький нюанс о котором многие забывают, а может и не знают.

Любое сетевое устройство когда выбирает из таблицы маршрутизации маршрут, всегда делает столько итераций поиска, сколько понадобится пока не найдёт интерфейс выхода. Именно для уменьшения нагрузки на процесс выбора маршрута необходимы параметры scope, но об этом в другой раз.

Итак, маршрут найден

0 A S 0.0.0.0/0 10.188.48.1 1

MikroTik смотрит на поле pref-src если указано значение, то в пакете будет установлен адрес источника, но в нашем случае параметра нет.

Так как адрес шлюза не соответствует интерфейсу, то маршрутизатор повторяет процесс поиска маршрута, но уже не для адреса 8.8.8.8, а для адреса 10.188.48.1

И результат поиска будет

1 ADC 10.188.48.0/22 10.188.48.99 ether1 0

И в данном случае pref-src указан, адрес источника если на данный момент не установлен, будет указан как 10.188.48.99.

Так как маршрутизатор всегда опускается по цепочке до маршрута, который указывает на интерфейс, а такой маршрут connected заполняется автоматически на основании IP адреса назначенного на интерфейс, MikroTik всегда назначает какой-нибудь IP адрес на интерфейсе.

Например, если бы в нашем случае у нас было два IP адреса из одной сети, мы бы могли указать на дефолтом маршруте значение pref-src тот ip адрес, с которого необходимо отправлять трафик в интернет.

Обратите внимание, значение pref-src должен быть IP адрес, назначенный на любой интерфейс и включен, в противном случае такой маршрут становиться не действительным.

Если вы используете OSPF и у вас есть loopback адрес, и в свою очередь вы данные loopback адреса редистрибьютите в сеть OSPF, то вы можете сделать следующий lifehack

> /routing filter add chain=ospf-in set-pref-src=172.31.255.1

Естественно адрес 172.31.255.1 заменить на адрес loopback того маршрутизатора, на котором будет выполняться данная команда.

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

Привет. Это короткая заметка про то, какие именно 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 из подсетей, строго говоря не имеющих к реальному пути пакета никакого прямого отношения.