Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

In this Discussion

MPLS cloud and TTL expiration case

Раздел: MPLS
Здравствуйте, Коллеги!

Прошу помочь разобраться в следующей задаче на MPLS. Имеется следующая топология (см.рис.1). На R1-R5 используется OSPF. Между R1 R2 R5 установлено iBGP соседство. R2 - рефлектор, для соседства используются lo0 интерфейсы. Между R5 и R6 eBGP. Интерфейс R5 смотрящий в сторону R6 не включен в OSPF. Между R2 R3 R4 и R5 - LDP соседства. Сеть между R5 и R6 объявлена в BGP на R6. Loopback0 роутера R2 также включен в BGP.

Запускаю trace на lo0 R2 10.2.2.2 с R6. Не могу понять, почему при TTL=2 получаю ICMP-ответ о ttl expiration, а при TTL=3 уже нет. TTL = 4 также ответ есть.
Т.е. если запускать трейс имеем следующий вывод:

R6#trace 10.2.2.2
Type escape sequence to abort.
Tracing the route to 10.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.56.5 48 msec 92 msec 68 msec
2 10.0.45.4 [MPLS: Label 17 Exp 0] 92 msec 80 msec 52 msec
3 * * *
4 10.0.23.2 76 msec 72 msec 76 msec
R6#

Согласно моей, вероятнее всего неправильной логике, P-роутер, на котором истекает MPLS TTL значение должен отправить ICMP ответ в первоначальном направлении пакета (вдоль по LSP) до противоположного PE, используя тот же стек меток, что и в принятом пакете. Противоположный PE отправит назад ответ, используя свой RIB, LFIB. Проверил Wireshark-ом. Действительно, при TTL=2 так и происходит. Краткий рисунок прилагаю.
Однако, при установке TTL=3, P-роутер R3 получает пакет с TTL=1 от источника, и, НЕ НАПРАВЛЯЕТ никаких icmp сообщений. Рисунок прилагаю.
Если объявить интерфейс между R5 и R6 в OSPF все начинает работать нормально.

Подскажите пожалуйста, с чем может быть связано такое поведение.

Большое спасибо!
Тэги темы:

Комментарии

  • Всем спасибо, разобрался в чем проблема. Причина связана с тем, что в формируемом ICMP сообщении, несмотря на то, что оно направляется в первоначальном направлении LSP, адрес источника - адрес P-роутера, адрес назначения - адрес R6 (неизвестный в OSPF). Если TTL заканчивается не на PHP узле, то формируемое ICMP сообщение успешно добирается до противоположного PE. Если же TTL заканчивается на PHP, то для данного сообщения метка не формируется. Соответственно данный узел оперирует чистым IP пакетом, который пытается отправить в противоположном направлении (на исходящий PE к R6), но т.к. маршрута нет, пакет просто отбрасывается.
    Помимо варианта с добавлением интерфейса между R5 и R6 в OSPF помогает отключение механизма PHP включением меток explicit-null на R2.
Войдите или Зарегистрируйтесь чтобы комментировать.