Перейти к содержимому
Калькуляторы

mpls дурят меня или нет

gimmee, а Вы? :)

 

Нет.

 

На хуавеях no-propagate-ttl есть как на глобале так и на instance

 

Это не так. Есть разные модельки и очень разный софт.

 

кроме того вы на предпоследнем хопе loop-detect выставляли ?

 

Что имеется ввиду? LDP loop-detection?

ну прочитайте вы 3443, ну причем тут китайцы то ?

 

RFC это одно, а реализация это другое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я высказал в этом сомнения, т.к. у других вендоров опция no-propagate-ttl включается глобально. В итоге так и оказалось.

Да что вы говорите.

Китайцев я никогда не настраивал и настраивать

Ну откуда тогда такая уверенность как оно на самом деле.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Я понял ваш посыл :) Опять же повторю, rfc 3443 описывает то что вы пытаетесь в своем предыдущем послании высказать. Однако в вашем тексте есть некоторая неуверенность, что толкает на мысль о вашей неосведомленности касательно этого документа, да и забудьте о китайцах на них свет клином не сошелся. ;)

 

 

во-первых, в rfc не описано в явном виде поведение на PHP роутере в случае наличия стека меток, а в l3vpn имеет место более одной метки.

во-вторых, реализация тех или иных фич у разных вендоров может не соответствовать rfc. На сомнения в частности меня натолкнула фраза из juniper'овского "MPLS Applications Guide"(ссылку не дам, у меня в pdf) касающаяся описания операции pop:

 

In the case of multiple labels in a packet (label stacking), removal of the top label yields another MPLS packet. The new top label might derive CoS and TTL from a previous top label. The popped TTL value from the previous top label is not written back to the new top label.

 

А вот и cisco'вскую доку бегло нагуглил http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4 :

 

If the operation is pop, the TTL of the incoming label –1 is copied to the newly exposed label unless that value is greater than the TTL of the newly exposed label, in which case the copy does not happen.

 

Налицо неполное соответствие rfc.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я высказал в этом сомнения, т.к. у других вендоров опция no-propagate-ttl включается глобально. В итоге так и оказалось.

Да что вы говорите.

 

Прошу прощения, я после коммента юзера _user_ в 13:18 - "На хуавеях no-propagate-ttl есть как на глобале так и на instance" такой вывод сделал. В итоге, я оказался прав частично - данная фича поддерживается на хуавеях в зависимости от модели. Может тогда уж скажете, на каких именно моделях не поддерживается глобально no-propagate-ttl ? Или будете утверждать, что на всех ?:)

 

 

Китайцев я никогда не настраивал и настраивать

Ну откуда тогда такая уверенность как оно на самом деле.

 

На основе опыта с другими вендорами. И, имхо, с точки зрения разработки ПО проще и логичнее сделать обсуждаемую фичу глобально нежели только per-vrf.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну это конечно очень странно, но так =)

 

NE40E/80E/5000E, софт не знаю точно. Софт что-то типа v3r2, v3r3. Старый достаточно. Для NE40E/80E уже допилили вроде в новых версиях (или патчах).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну вот, тут все умы телекома России, какой день разобраться не могут. А вы про спецов мегафона...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вот и cisco'вскую доку бегло нагуглил http://www.ciscopres...680824&seqNum=4 :

If the operation is pop, the TTL of the incoming label –1 is copied to the newly exposed label unless that value is greater than the TTL of the newly exposed label, in which case the copy does not happen.

Налицо неполное соответствие rfc.

Нет вы прочитайте внимательно, полный текст выглядит иначе: "In Cisco IOS, however, a safeguard guards against possible routing loops by not copying the MPLS TTL to the IP TTL if the MPLS TTL is greater than the IP TTL of the received labeled packet. If the MPLS TTL would be copied to the IP header, the smaller IP TLL value would be overwritten by a newer but higher value. If the IP packet would be injected into the MPLS cloud again—such as the result of a routing loop—the packet could live forever because the TTL would never reach 0"

То есть в cisco есть дополнительная фича.

 

Нарушений в поведении с ttl касательно rfc в описанном топике нет. То что вы пытаетесь "отыскать" "багу" у китайцев похвально, но это не то место :) Для наглядности вам на чтение

http://www.juniper.net/techpubs/software/erx/junose72/swconfig-bgp-mpls/html/mpls-config5.html

 

RFC это одно, а реализация это другое.

Да нет ошибок в реализации :)

Давайте смотреть у вас это в grt читаем: "By default, the TTL propagation function is enabled for public network packets but is disabled for VPN packets"

Соответственно он понятие не имеет о том что вы скрываете хопы на mpls. Так как у вас настройки по дефолту то киска выдает label с "implicit NULL" что приводит к указанной ситуации.

Однако действительно в старых версиях поправить в лоб не получиться

Huawei Versatile Routing Platform Software

VRP ® software, Version 5.50 (NE40E&80E V300R003C02B697)

Copyright © 2000-2009 Huawei Technologies Co., Ltd.

Quidway NetEngine 80E uptime is 618 days, 12 hours, 53 minutes

 

команды нет: undo ttl propagate global

В более новых да есть.

Решение в любом случае есть : сделайте explicit NULL, да это совсем не то, но доп. лукапа в LFIB не будет(PE) и проблема с ttl решаться будет у PE.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Нет вы прочитайте внимательно, полный текст выглядит иначе: "In Cisco IOS, however, a safeguard guards against possible routing loops by not copying the MPLS TTL to the IP TTL if the MPLS TTL is greater than the IP TTL of the received labeled packet. If the MPLS TTL would be copied to the IP header, the smaller IP TLL value would be overwritten by a newer but higher value. If the IP packet would be injected into the MPLS cloud again—such as the result of a routing loop—the packet could live forever because the TTL would never reach 0"

То есть в cisco есть дополнительная фича.

 

Я вам вообще-то говорил про обработку ttl в случае с l3vpn, именно поэтому привёл цитату из раздела "TTL Behavior in the Case of Label-to-Label", а вы мне почему-то указываете на раздел "TTL Behavior in the Case of IP-to-Label or Label-to-IP".

 

Ну да ладно, всё, сдаюсь, спор заканчиваю, т.к. он уже в далёкий оффтопик вышел.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Нет вы прочитайте внимательно, полный текст выглядит иначе: "In Cisco IOS, however, a safeguard guards against possible routing loops by not copying the MPLS TTL to the IP TTL if the MPLS TTL is greater than the IP TTL of the received labeled packet. If the MPLS TTL would be copied to the IP header, the smaller IP TLL value would be overwritten by a newer but higher value. If the IP packet would be injected into the MPLS cloud again—such as the result of a routing loop—the packet could live forever because the TTL would never reach 0"

То есть в cisco есть дополнительная фича.

 

Я вам вообще-то говорил про обработку ttl в случае с l3vpn, именно поэтому привёл цитату из раздела "TTL Behavior in the Case of Label-to-Label", а вы мне почему-то указываете на раздел "TTL Behavior in the Case of IP-to-Label or Label-to-IP".

 

Ну да ладно, всё, сдаюсь, спор заканчиваю, т.к. он уже в далёкий оффтопик вышел.

Вы правильно указали в случае l3vpn, только судя по топику у них все в grt было, а в этом случае смотреть надо другое ;)

Да закругляться надо было еще после поста visir-а, но это так весело искать "баги" :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да закругляться надо было еще после поста visir-а, но это так весело искать "баги" :)

 

а их не надо искать - берешь железку, начинаешь с ней работать и баги начинают выползать сами ))

кстати, не в тему, может кто поможет с таким вопросом по mpls

 

схема такая

7606 с картой Es+ -- 7606 (без карты ES+)

поднимаем туннель между ними. на той 7606-Es+ xconnect начинается с SVI, на другой с саб-интерфейса

если линк между 7606 упал и поднялся то туннель не поднимается пока не shut/no shut SVI

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

команды нет: undo ttl propagate global

Это и есть баг. Ошибка в реализации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сделайте explicit NULL

Так и хуавей не только на P может стоять. И лукап таки будет дополнительный. Не тянет на "решение".

 

Вы, кстати, не хотите рассказать общественности по поводу loop-detect? Интересно все же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

команды нет: undo ttl propagate global

Это и есть баг. Ошибка в реализации.

ну приехали :) Что не киска то "баг" :). Мир какой то однобокий в эпоху, малтивендорности ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так и хуавей не только на P может стоять. И лукап таки будет дополнительный. Не тянет на "решение".

 

Вы, кстати, не хотите рассказать общественности по поводу loop-detect? Интересно все же.

Нет не будет лукапа, потому что правило такое ;) Не ко мне, жисть такая в mpls.

На не P роутере, это замечательно решается апгрейдом, сам так делал ибо "хуавей" =)

Вы хотите поговорить о loop-detect на P в реализации Хуавей ? Со мной не стоит, лучше с китайцами им виднее.

Для grt это как "мертвому припарка", а вот для vpn, будете удивлены. Но топик читался со середины ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

команды нет: undo ttl propagate global

Это и есть баг. Ошибка в реализации.

ну приехали :) Что не киска то "баг" :). Мир какой то однобокий в эпоху, малтивендорности ;)

Ну вещи-то надо своими именами называть. Киска не при чем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет не будет лукапа, потому что правило такое ;)

Ну понятно, что эта процедура оптимизирована, но операций в любом случае больше будет выполняться

Вы хотите поговорить о loop-detect на P в реализации Хуавей ? Со мной не стоит, лучше с китайцами им виднее.

Для grt это как "мертвому припарка", а вот для vpn, будете удивлены. Но топик читался со середины ;)

Да просто хочу понять о чем речь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

команды нет: undo ttl propagate global

Это и есть баг. Ошибка в реализации.

ну приехали :) Что не киска то "баг" :). Мир какой то однобокий в эпоху, малтивендорности ;)

Ну вещи-то надо своими именами называть. Киска не при чем.

Отсутствие функционала в оборудование вендора отличного от cisco, есть не "бага".

Ну если вы в душе недолюбливаете "великий путь", то они кстати по проблеме разобьются, но либо патч либо апгрейд соорудят.

А так да не по "фэншую", но документацию читать стоит ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну понятно, что эта процедура оптимизирована, но операций в любом случае больше будет выполняться

Нет. Ну то есть в хардваре да. Но вы этого даже не заметите.

Пакет от P роутера идет с явным "0", по которому на PE делается простой "pop" с последующим lookup в FIB.

 

Да просто хочу понять о чем речь.

Скажем так, мой негожий совет по loop-detect в вашем случае, признаю не прочитал полностью топик. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отсутствие функционала в оборудование вендора отличного от cisco, есть не "бага".

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

то они кстати по проблеме разобьются, но либо патч либо апгрейд соорудят.

Да, такое есть и это им в плюс.

А так да не по "фэншую", но документацию читать стоит ;)

Автор полагает, что знаком с документацией получше некоторых. Тогда может и решение предложит? Или помимо отсылок к абстрактной документации сказать нечего?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Автор полагает, что знаком с документацией получше некоторых. Тогда может и решение предложит? Или помимо отсылок к абстрактной документации сказать нечего?

А разве решения не было ? :)

Доку не абстрактная, а именно

Manual Version T2-081958-20050523-C-1.22

Product Version VRP5.10

BOM 31190358

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А разве решения не было ? :)

А разве было? Огласите для ясности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А разве решения не было ? :)

А разве было? Огласите для ясности.

Какие решения я увидел:

1. Не использовать no-propagate-ttl вообще на всей сети

2. explicit-null, но это пригодно не для всех PE (в случае с J, опять же, пригодно ;) - дополнительного лукапа не будет, так как эту метку снимает сам PIC, PFE ее даже не увидит)

3. Апгрейд софта (+ возможно допинывание китайцев на нужную фичу в нужной ветке, что вроде как проблемой не является)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А разве решения не было ? :)

А разве было? Огласите для ясности.

Какие решения я увидел:

1. Не использовать no-propagate-ttl вообще на всей сети

2. explicit-null, но это пригодно не для всех PE (в случае с J, опять же, пригодно ;) - дополнительного лукапа не будет, так как эту метку снимает сам PIC, PFE ее даже не увидит)

3. Апгрейд софта (+ возможно допинывание китайцев на нужную фичу в нужной ветке, что вроде как проблемой не является)

 

Хотелось услышать это все в одном месте от юзера )

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

2+3. Да, вариант. Нужно только МегаФон убедить )

 

Я думаю, что там никто не хочет менять конфигурации на всей сети ради explicit null, а предпочитает иметь рычаг для давления на Хуавей ;)

 

p.s. Насколько я знаю, китайцы работают над проблемой и вот-вот допилят ее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Насколько я знаю, китайцы работают над проблемой и вот-вот допилят ее.

Помнится, когда тестил это железо, они допилили status vector TLV в Компелловском L2VPN - при этом они умудрились сломать самый обычный IPv4 в BGP :)))

Изменено пользователем visir

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ах, да, про "loop-detection" забыл. К чему в итоге с ним пришли - оказалось, что речь шла про LDP?

Если так, то это конечно ВЕРХ ДОУНИЗМА и юзер подлежит почетному и торжественному занесению в список доунов :D.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.