Странное поведение задержки в трейсе через MPLS L3 VPN

[micho]

имеем такую сеть:

 

U1-PE1-P1-P2-P3-PE2-U2

 

U1, U2 - маршрутизаторы клиента

PE1, PE2 - PE маршрутизаторы

P1, P2, P3 - P маршрутизаторы

канал между P2 и P3 загружен на 100%.

TTL propagation ВКЛЮЧЕНО.

Почему при трейсе с U1 на U2 задержка появляется не между P2 и P3, а между PE1 и P1?

[rz3dwy]

Ответы на пинги и трейсы обрабатываются CPU. Может, P1 загружен чем-то сильно.

[micho]

Может, P1 загружен чем-то сильно.

нет, не загружен.

[micho]

наверное следует уточнить

 

сеть вот такая

U1-PE1-P11-P21-P22-P12-PE2-U2

загруженный канал между P21 и P22. PE1, PE2, P11, P12 находятся в одной автономке, P21 и P22 в другой, на них организована interAS VPN.

[Smoke]

Дык трейс в MPLS почитайте как работает

Благодаря тому что IP пакет упаковывается в MPLS, промежуточный LSR не знает кто отправитель trace probe. Поэтому IP c дестнейшеном источника трейса (TTL exceed) идет до egress PE по IGP Lable LSP, там видит что Destination Address (Ingress PE)в обратной стороне и возвращает пакет обратно.

[micho]

Smoke

спасибо.

[ikiliikkuja]

Дык трейс в MPLS почитайте как работает

Благодаря тому что IP пакет упаковывается в MPLS, промежуточный LSR не знает кто отправитель trace probe. Поэтому IP c дестнейшеном источника трейса (TTL exceed) идет до egress PE по IGP Lable LSP, там видит что Destination Address (Ingress PE)в обратной стороне и возвращает пакет обратно.

А можно я к теме присоседюсь? Я заметил, что TTL-exceeded (от P-роутеров) на последнем PE попадают в сугубо L3 интерфейс (обычный статический туннель) и соответственно, от конечного "CE" уже форвардятся обратно. Почему до PE доходит понимаю, почему на PE, где метка снимается, не уходит назад - не понимаю

[orlik]

Потомучто некотоые могут не делать прореркт по ip, а по метке сразу маршрутизируют в интерфейс ...

[rdntw]

тут нужны fomka31ru и visir :)

[Smoke]

Дык трейс в MPLS почитайте как работает

Благодаря тому что IP пакет упаковывается в MPLS, промежуточный LSR не знает кто отправитель trace probe. Поэтому IP c дестнейшеном источника трейса (TTL exceed) идет до egress PE по IGP Lable LSP, там видит что Destination Address (Ingress PE)в обратной стороне и возвращает пакет обратно.

А можно я к теме присоседюсь? Я заметил, что TTL-exceeded (от P-роутеров) на последнем PE попадают в сугубо L3 интерфейс (обычный статический туннель) и соответственно, от конечного "CE" уже форвардятся обратно. Почему до PE доходит понимаю, почему на PE, где метка снимается, не уходит назад - не понимаю

 

TTL Workflow to Customer route

 

- На первом хопе Ingress PE отрабатывает так же как IP TTL.

- На всех следующих согласно правилу TTL Expire LSR

- На Egress PE происходит обработка идет по нижней метке и пакет TTL отправляется на CE.

- CE видит что пакет направлен в противоположную сторону и отправляет его обратно на PE.

 

TTL Workflow to Attached Interface or Aggregate route

 

- На первом хопе Ingress PE отрабатывает так же как IP TTL.

- На всех следующих согласно правилу TTL Expire LSR

- На Egress PE происходит дополнительный lookup PE видит Destination IP и отправляет его обратно без пересылки на CE.

[dmvy]

разве P-роутеры уменьшают ip ttl? на них идет коммутация по mpls метке, а отправляющая сторона шлет пакет не на следующий хост, а на конечный LSR. И L3-lookup с уменьшением TTL делает уже конечный PE. Или у вас по другому работает/настроено?

[orlik]

разве P-роутеры уменьшают ip ttl?

 

нет , да это и не важно , они уменьшают mpls ttl и когда он доходит до 0 , то генерят icmp ttl expired и отправляют дальше путешествовать по сети ....

[micho]

dmvy

ip ttl копируется в mpls ttl, а потом обратно.

[MonaxGT]

dmvy

ip ttl копируется в mpls ttl, а потом обратно.

Не всегда

[zi_rus]

ну началось

[micho]

dmvy

ip ttl копируется в mpls ttl, а потом обратно.

Не всегда

Вы что только последний пост прочитали? У меня ж написано что ттл пропагейшн ВКЛЮЧЕНО.