micho Posted November 19, 2015 имеем такую сеть: 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? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
rz3dwy Posted November 19, 2015 Ответы на пинги и трейсы обрабатываются CPU. Может, P1 загружен чем-то сильно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
micho Posted November 19, 2015 Может, P1 загружен чем-то сильно. нет, не загружен. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
micho Posted November 19, 2015 наверное следует уточнить сеть вот такая U1-PE1-P11-P21-P22-P12-PE2-U2 загруженный канал между P21 и P22. PE1, PE2, P11, P12 находятся в одной автономке, P21 и P22 в другой, на них организована interAS VPN. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Smoke Posted November 19, 2015 Дык трейс в MPLS почитайте как работает Благодаря тому что IP пакет упаковывается в MPLS, промежуточный LSR не знает кто отправитель trace probe. Поэтому IP c дестнейшеном источника трейса (TTL exceed) идет до egress PE по IGP Lable LSP, там видит что Destination Address (Ingress PE)в обратной стороне и возвращает пакет обратно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
micho Posted November 19, 2015 Smoke спасибо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ikiliikkuja Posted November 19, 2015 Дык трейс в 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, где метка снимается, не уходит назад - не понимаю Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
orlik Posted November 19, 2015 Потомучто некотоые могут не делать прореркт по ip, а по метке сразу маршрутизируют в интерфейс ... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
rdntw Posted November 19, 2015 тут нужны fomka31ru и visir :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Smoke Posted November 19, 2015 Дык трейс в 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. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dmvy Posted November 20, 2015 разве P-роутеры уменьшают ip ttl? на них идет коммутация по mpls метке, а отправляющая сторона шлет пакет не на следующий хост, а на конечный LSR. И L3-lookup с уменьшением TTL делает уже конечный PE. Или у вас по другому работает/настроено? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
orlik Posted November 20, 2015 разве P-роутеры уменьшают ip ttl? нет , да это и не важно , они уменьшают mpls ttl и когда он доходит до 0 , то генерят icmp ttl expired и отправляют дальше путешествовать по сети .... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
micho Posted November 20, 2015 dmvy ip ttl копируется в mpls ttl, а потом обратно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
MonaxGT Posted November 20, 2015 dmvy ip ttl копируется в mpls ttl, а потом обратно. Не всегда Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted November 20, 2015 ну началось Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
micho Posted November 20, 2015 dmvy ip ttl копируется в mpls ttl, а потом обратно. Не всегда Вы что только последний пост прочитали? У меня ж написано что ттл пропагейшн ВКЛЮЧЕНО. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...