gimmee Опубликовано 18 августа, 2011 · Жалоба gimmee, а Вы? :) Нет. На хуавеях no-propagate-ttl есть как на глобале так и на instance Это не так. Есть разные модельки и очень разный софт. кроме того вы на предпоследнем хопе loop-detect выставляли ? Что имеется ввиду? LDP loop-detection? ну прочитайте вы 3443, ну причем тут китайцы то ? RFC это одно, а реализация это другое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 18 августа, 2011 · Жалоба Я высказал в этом сомнения, т.к. у других вендоров опция no-propagate-ttl включается глобально. В итоге так и оказалось. Да что вы говорите. Китайцев я никогда не настраивал и настраивать Ну откуда тогда такая уверенность как оно на самом деле. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 18 августа, 2011 · Жалоба Я понял ваш посыл :) Опять же повторю, 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 18 августа, 2011 · Жалоба Я высказал в этом сомнения, т.к. у других вендоров опция no-propagate-ttl включается глобально. В итоге так и оказалось. Да что вы говорите. Прошу прощения, я после коммента юзера _user_ в 13:18 - "На хуавеях no-propagate-ttl есть как на глобале так и на instance" такой вывод сделал. В итоге, я оказался прав частично - данная фича поддерживается на хуавеях в зависимости от модели. Может тогда уж скажете, на каких именно моделях не поддерживается глобально no-propagate-ttl ? Или будете утверждать, что на всех ?:) Китайцев я никогда не настраивал и настраивать Ну откуда тогда такая уверенность как оно на самом деле. На основе опыта с другими вендорами. И, имхо, с точки зрения разработки ПО проще и логичнее сделать обсуждаемую фичу глобально нежели только per-vrf. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 18 августа, 2011 · Жалоба Ну это конечно очень странно, но так =) NE40E/80E/5000E, софт не знаю точно. Софт что-то типа v3r2, v3r3. Старый достаточно. Для NE40E/80E уже допилили вроде в новых версиях (или патчах). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilia_2s Опубликовано 18 августа, 2011 · Жалоба Ну вот, тут все умы телекома России, какой день разобраться не могут. А вы про спецов мегафона... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 19 августа, 2011 · Жалоба А вот и 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 19 августа, 2011 · Жалоба Нет вы прочитайте внимательно, полный текст выглядит иначе: "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". Ну да ладно, всё, сдаюсь, спор заканчиваю, т.к. он уже в далёкий оффтопик вышел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 19 августа, 2011 · Жалоба Нет вы прочитайте внимательно, полный текст выглядит иначе: "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-а, но это так весело искать "баги" :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 19 августа, 2011 · Жалоба Да закругляться надо было еще после поста visir-а, но это так весело искать "баги" :) а их не надо искать - берешь железку, начинаешь с ней работать и баги начинают выползать сами )) кстати, не в тему, может кто поможет с таким вопросом по mpls схема такая 7606 с картой Es+ -- 7606 (без карты ES+) поднимаем туннель между ними. на той 7606-Es+ xconnect начинается с SVI, на другой с саб-интерфейса если линк между 7606 упал и поднялся то туннель не поднимается пока не shut/no shut SVI Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 19 августа, 2011 · Жалоба команды нет: undo ttl propagate global Это и есть баг. Ошибка в реализации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 19 августа, 2011 · Жалоба сделайте explicit NULL Так и хуавей не только на P может стоять. И лукап таки будет дополнительный. Не тянет на "решение". Вы, кстати, не хотите рассказать общественности по поводу loop-detect? Интересно все же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 19 августа, 2011 · Жалоба команды нет: undo ttl propagate global Это и есть баг. Ошибка в реализации. ну приехали :) Что не киска то "баг" :). Мир какой то однобокий в эпоху, малтивендорности ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 19 августа, 2011 · Жалоба Так и хуавей не только на P может стоять. И лукап таки будет дополнительный. Не тянет на "решение". Вы, кстати, не хотите рассказать общественности по поводу loop-detect? Интересно все же. Нет не будет лукапа, потому что правило такое ;) Не ко мне, жисть такая в mpls. На не P роутере, это замечательно решается апгрейдом, сам так делал ибо "хуавей" =) Вы хотите поговорить о loop-detect на P в реализации Хуавей ? Со мной не стоит, лучше с китайцами им виднее. Для grt это как "мертвому припарка", а вот для vpn, будете удивлены. Но топик читался со середины ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 19 августа, 2011 · Жалоба команды нет: undo ttl propagate global Это и есть баг. Ошибка в реализации. ну приехали :) Что не киска то "баг" :). Мир какой то однобокий в эпоху, малтивендорности ;) Ну вещи-то надо своими именами называть. Киска не при чем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 19 августа, 2011 · Жалоба Нет не будет лукапа, потому что правило такое ;) Ну понятно, что эта процедура оптимизирована, но операций в любом случае больше будет выполняться Вы хотите поговорить о loop-detect на P в реализации Хуавей ? Со мной не стоит, лучше с китайцами им виднее. Для grt это как "мертвому припарка", а вот для vpn, будете удивлены. Но топик читался со середины ;) Да просто хочу понять о чем речь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 19 августа, 2011 · Жалоба команды нет: undo ttl propagate global Это и есть баг. Ошибка в реализации. ну приехали :) Что не киска то "баг" :). Мир какой то однобокий в эпоху, малтивендорности ;) Ну вещи-то надо своими именами называть. Киска не при чем. Отсутствие функционала в оборудование вендора отличного от cisco, есть не "бага". Ну если вы в душе недолюбливаете "великий путь", то они кстати по проблеме разобьются, но либо патч либо апгрейд соорудят. А так да не по "фэншую", но документацию читать стоит ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 19 августа, 2011 · Жалоба Ну понятно, что эта процедура оптимизирована, но операций в любом случае больше будет выполняться Нет. Ну то есть в хардваре да. Но вы этого даже не заметите. Пакет от P роутера идет с явным "0", по которому на PE делается простой "pop" с последующим lookup в FIB. Да просто хочу понять о чем речь. Скажем так, мой негожий совет по loop-detect в вашем случае, признаю не прочитал полностью топик. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 19 августа, 2011 · Жалоба Отсутствие функционала в оборудование вендора отличного от cisco, есть не "бага". Когда функционал приводит к фокусам - то да. К слову, этот функционал был в более старых версиях, а потом исчез. то они кстати по проблеме разобьются, но либо патч либо апгрейд соорудят. Да, такое есть и это им в плюс. А так да не по "фэншую", но документацию читать стоит ;) Автор полагает, что знаком с документацией получше некоторых. Тогда может и решение предложит? Или помимо отсылок к абстрактной документации сказать нечего? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 19 августа, 2011 · Жалоба Автор полагает, что знаком с документацией получше некоторых. Тогда может и решение предложит? Или помимо отсылок к абстрактной документации сказать нечего? А разве решения не было ? :) Доку не абстрактная, а именно Manual Version T2-081958-20050523-C-1.22 Product Version VRP5.10 BOM 31190358 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 19 августа, 2011 · Жалоба А разве решения не было ? :) А разве было? Огласите для ясности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 21 августа, 2011 · Жалоба А разве решения не было ? :) А разве было? Огласите для ясности. Какие решения я увидел: 1. Не использовать no-propagate-ttl вообще на всей сети 2. explicit-null, но это пригодно не для всех PE (в случае с J, опять же, пригодно ;) - дополнительного лукапа не будет, так как эту метку снимает сам PIC, PFE ее даже не увидит) 3. Апгрейд софта (+ возможно допинывание китайцев на нужную фичу в нужной ветке, что вроде как проблемой не является) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gimmee Опубликовано 25 августа, 2011 · Жалоба А разве решения не было ? :) А разве было? Огласите для ясности. Какие решения я увидел: 1. Не использовать no-propagate-ttl вообще на всей сети 2. explicit-null, но это пригодно не для всех PE (в случае с J, опять же, пригодно ;) - дополнительного лукапа не будет, так как эту метку снимает сам PIC, PFE ее даже не увидит) 3. Апгрейд софта (+ возможно допинывание китайцев на нужную фичу в нужной ветке, что вроде как проблемой не является) Хотелось услышать это все в одном месте от юзера ) 1. Этот вариант не подходит, т.к. было много жалоб на звезды в трейсе - возвращться к этому никто не хочет. 2+3. Да, вариант. Нужно только МегаФон убедить ) Я думаю, что там никто не хочет менять конфигурации на всей сети ради explicit null, а предпочитает иметь рычаг для давления на Хуавей ;) p.s. Насколько я знаю, китайцы работают над проблемой и вот-вот допилят ее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 25 августа, 2011 (изменено) · Жалоба Насколько я знаю, китайцы работают над проблемой и вот-вот допилят ее. Помнится, когда тестил это железо, они допилили status vector TLV в Компелловском L2VPN - при этом они умудрились сломать самый обычный IPv4 в BGP :))) Изменено 26 августа, 2011 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 26 августа, 2011 · Жалоба Ах, да, про "loop-detection" забыл. К чему в итоге с ним пришли - оказалось, что речь шла про LDP? Если так, то это конечно ВЕРХ ДОУНИЗМА и юзер подлежит почетному и торжественному занесению в список доунов :D. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...