[mightyscv]

Коллеги, хотел бы послушать мнение общественности.

 

Есть сеть на Juniper MX. На PE по BGP от клиентов присылаются маршруты в глобальной таблице(inet.0). Эти маршруты через механизм rib-group копируются в vrf(vrf.inet.0).

Дальше идея в том, чтобы распространить маршруты по L3VPN по всей автономной системе - то есть анонсировать их IBGP соседям как inet.0 и как vrf.inet.0.

Это прекрасно работает на всех PE, кроме тех которые работают BGP-рефлекторами.

 

Причём на самом рефлекторе маршрут корректно копируется, и другим пирам, которые нативно живут в vrf.inet.0, он этот скопированный маршрут анонсирует.

 

Немного вывода для визуализации проблемы:

принимаем маршрут от клиента. Сессия с клиентом живёт в inet.0, и маршрут корректно копируется в vrf.inet.0

RR> show route receive-protocol bgp 1.1.128.141

inet.0: 515317 destinations, 1561064 routes (515308 active, 0 holddown, 13 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 5.5.158.0/24          1.1.128.141                         65031 65031 65031 I

vrf.inet.0: 24676 destinations, 53099 routes (24676 active, 0 holddown, 0 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 5.5.158.0/24          1.1.128.141                         65031 65031 65031 I

 

анонсируется IBGP соседу(рефлектор-клиенту) только как inet.0:

RR> show route advertising-protocol bgp 1.1.110.41 5.5.158.0/24

inet.0: 515297 destinations, 1560955 routes (515288 active, 0 holddown, 13 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 5.5.158.0/24          1.1.128.141              200        65031 65031 65031 I

 

соседу, живущему только в vrf.inet.0 анонсируется без проблем:

RR> show route advertising-protocol bgp 1.1.128.160 5.5.158.0/24

vrf.inet.0: 24677 destinations, 52985 routes (24677 active, 0 holddown, 0 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 5.5.158.0/24          Self                                    65031 65031 65031 I

 

абсолютно идентичная конструкция на обычном(не рефлекторе) PE - маршрут анонсируется в сторону рефлектора в обоих таблицах. На рефлекторе такой маршрут дальше по сети тоже реанонсируется корректно:

PE> show route advertising-protocol bgp 1.1.110.58 2.2.58.0/23

inet.0: 515245 destinations, 1053356 routes (515245 active, 0 holddown, 0 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 2.2.58.0/23          1.1.128.162              160        65061 I

vrf.inet.0: 24614 destinations, 71184 routes (24614 active, 0 holddown, 0 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 2.2.58.0/23          Self                         160        65061 I

 

Под всем этим нормальные OSPF и MPLS с просигнализированными RSVP LSP. С этой стороны я проблем не ожидаю.

Я печенью чую, что это как-то связано с BGP next-hop, и это вообще не вендоро-зависимая проблема. Все проблемы в BGP связаны с проблемными next-hop. Но что мешает рефлектору корректно менять next-hop - не пойму никак.

В целом это, наверное, вообще плохой дизайн - заставлять рефлекторы работать ещё и как PE, но у меня нет в бюджете отдельных выделенных железок под это дело, а софтовые реализации BGP(BIRD, quagga) не умели согласовывать всякие l2vpn signalling и прочие inet-vpn multicast AFI когда я их тестировал.

 

Пните меня в правильном направлении - в каком RFC написано, что нельзя рефлектору работать как PE для L3VPN в случае с route leaking? Почему он конкретно в таком сценарии не может сменить next-hop на self? В других то ситуациях он отлично это делает - маршруты, нативно полученные через vrf.inet.0 распространяются по IBGP с next-hop self.

Кейс в JTAC у меня уже открыт - там занимаются воспроизведением проблемы. Но индусы первой линии соображают меньше среднестатистического сетевого инженера к сожалению, и пока кейс дойдёт до advanced TAC - пройдёт куча времени. Может тут быстрее меня образумят?

[fomka31ru]

Проблема скорее всего в том, что при рибанье маршрутов, мплс метка остается другого роутера, новая метка не подставляется. Поэтому трафик и не доходит.

пишите полиси, для всех экстренал маршрутов делать nhs - это первое. А дальше для префиксов, которые адвертаете из одной таблицы в другую.

[mightyscv]

fomka31ru

Причём тут MPLS метка? От внешнего пира мы получаем обычный inet unicast. К тому же я обращал внимание, что это только рефлекторы так себя ведут - те PE, что не рефлекторы всё корректно анонсируют. Причём в обратную сторону это тоже работает - если из vrf.inet.0 маршрут копировать то он корректно по inet.0 распространяется с nhs.

Трафик не ходит потому что нет маршрута. Это проблема control plane, а не data plane.

 

Вот прописать для полученных маршрутов nhs - это мысль. Надо попробовать, хотя бы посмотреть на эффект. Если он сам не понимает что это нужно сделать - заставить его вручную.

[fomka31ru]

"Причём тут MPLS метка?"

 

Поверьте и с метками проблема тоже может быть :)

[mightyscv]

fomka31ru

Я могу согласиться в том смысле, что да, возможно он при копировании маршрута не может назначить MPLS метку, и поэтому не анонсирует ничего соседям. Более того, такая мысль у меня уже была, и я даже её рассматриваю как одну из наиболее вероятных.

Но это последствие, а не причина. В чём причина такого поведения? Почему обычные PE могут её назначить, а рефлектор нет?

Я причину же хочу понять этого поведения.

[fomka31ru]

в задачи рефлектора входит лишь передача маршрута другим соседям. Представьте ситуацию, что у вас есть выделенный RR и если он будет подставлять себя в качестве NH то как минимум неоптимальный роутинг, как максимум деградация сервисов. То, что RR не ставит себя в качестве NH это нормально! Он это и не должен делать. А дальше вы уже сами определяете функции при которых нужно делать NH на RR, потому как RR может жить не на отдельной железке, а на каком-нить P роутере.

 

ЗЫ: На практике правило следующее -

[edit]
+  policy-options {
+      policy-statement nhs {
+          term 1 {
+              from {
+                  protocol bgp;
+                  route-type external;
+              }
+              then {
+                  next-hop self;
+              }
+          }
+      }
+  }

далее определяете то, что вам нужно и пишите еще один терм

Edited November 7, 2014 by fomka31ru

[mightyscv]

JTAC после эскалации, после пояснительного письма и одного secure meeting на 40 минут осилили воспроизвести проблему у себя в лабе. У них же заодно проверили и явный nhs в политике экспорта - не помогает.

 

fomka31ru

Вы мне зачем-то рассказали то, что я итак знаю.

А теперь я вам покажу кое что, чего вы(и я тоже) не знаете.

 

Итак, "RR не ставит себя в качестве NH это нормально! Он это и не должен делать" ? Однако же для маршрутов, полученных через inet-uncast от внешнего пира, живущего внутри VRF он это делает.

 

RR> show route receive-protocol bgp 1.1.128.129 table vrf.inet.0

vrf.inet.0: 24794 destinations, 57332 routes (24793 active, 1 holddown, 0 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 6.6.192.0/18           1.1.128.129      26                 65238 I

 

Я не буду приводить детальный вывод маршрута, но поверьте - для него Primary Routing Table vrf.inet.0.

 

Такой маршрут успешно анонсируется соседям с nhs, причём в обеих таблицах.

 

RR> show route advertising-protocol bgp 1.1.110.55 6.6.192.0/18 exact

inet.0: 515445 destinations, 1589461 routes (515445 active, 0 holddown, 6 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 6.6.192.0/18           Self                 26      160        65238 I

vrf.inet.0: 24799 destinations, 57344 routes (24799 active, 0 holddown, 0 hidden)
 Prefix                  Nexthop              MED     Lclpref    AS path
* 6.6.192.0/18           Self                 26      160        65238 I

 

То есть RR может менять NH на nhs, причём сам, без явного указания. Но работает это только при ликинге из vrf.inet.0 в inet.0, но не наоборот.

 

Собственно к этому и сводится вопрос - что там такого в логике BGP RR хитрого, что при ликинге из inet.0 это не работает? Как только мы убираем конфиг рефлектора(одна строка - cluster) - всё начинает анонсироваться как положено.

 

Текущие решения:

- делать IBGP full mesh. Я начинаю ёрзать в кресле от одной мысли про n(n - 1) / 2

- выносить RR на отдельные железки. Как я уже говорил ранее, софтовые решения не подходят из-за отсутствия поддержки многих AFI. Выделять отдельные железки под это - нет в бюджете и жаба душит.

Глупость какая-то. Функционал PE и RR в одной железке не совместить.

Я всё таки думаю, что это не проблема Juniper как таковая, а какая-то хитрая тонкость в самой логике BGP, но у меня нет железок других вендоров чтобы это проверить.

[Smoke]

Жесть - ващето больше похоже на баг чем на фичу, так как ликинг маршрутов дело сугубо внутри вендрное и под RFC не попадает. Но получать с рефлектора некст-хопом сам рефлектор неприятно. Так а што JTAC в итоге сказал?

[mightyscv]

Smoke

JTAC ушёл думать. Жду второй эскалации :)

То что ликинг сугубо вендорный - принимается к сведению. Я про это как-то не подумал.

Но получать с рефлектора некст-хопом сам рефлектор неприятно

Это не проблема в данном случае, ведь маршруты внешние.

Я как бы ожидаю в данной ситуации такой логики.

 

Получили маршрут по IBGP? Реанонсим не меняя атрибутов.

Получили по EBGP? Реанонсим по стандартным правилам(делаем что хотим).

 

На практике же логика получается такая.

 

Я не рефлектор и получил ликнутый маршрут из inet.0? Реанонсим с nhs.

Я рефлектор и получил ликнутый маршрут из inet.0? EBGP пирам реанонсим с nhs, а в сторону IBGP пиров молчим.

 

Мне эта логика непонятна.

[fomka31ru]

А теперь я вам покажу кое что, чего вы(и я тоже) не знаете.

С чего вы взяли, что я этого не знаю?

 

И для особо умных, я еще вверху, предложил вам использовать стандартную практику написания NHS, но куда же вам, все должно быть по дефолту и так как вы хотите

Edited November 13, 2014 by fomka31ru

[dmvy]

а разве для l3vpn не другая таблица используется?

пример, как работает у нас:

dmvy@border> show route 192.168.110.0/24 

bgp.l3vpn.0: 58 destinations, 59 routes (58 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

351:102:192.168.110.0/24                
                  *[bGP/170] 4w2d 19:55:16, localpref 100, from 10.10.11.36
                     AS path: I
                     to 2.54.2.86 via ae0.729, Push 117, Push 1092(top)
                   > to 2.54.2.46 via ae1.728, Push 117, Push 463(top)


dmvy@border> show route 10.176.205.0/24          

bgp.l3vpn.0: 58 destinations, 59 routes (58 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

351:101:10.176.205.0/24                
                  *[bGP/170] 1d 20:48:42, localpref 100, from 10.10.11.27
                     AS path: I
                     to 2.54.2.86 via ae0.729, Push 116, Push 1087(top)
                   > to 2.54.2.46 via ae1.728, Push 116, Push 458(top)

 

У нас RR juniper mx, а все остальные клиенты Extreme Summit. Благо route leaking не делаем. Даже в BGP capability только

family inet-vpn {

unicast;

}

[mightyscv]

dmvy

Таблица bgp.l3vpn.0 существует исключительно для хранения полученных по BGP маршрутов типа inet-vpn от соседей. Дальше у маршрута смотрится target community, и по нему маршрут запихивается в нужный VRF.

Так как мои маршруты локально ликнуты, то они в bgp.l3vpn.0 попадать не должны.

Я так понимаю, вы показали пример как у вас RR работает? Вывод то логичный совершенно - он маршруты от клиентов принял, запихал в bgp.l3vpn.0, и реанонсировал. VRF на RR у вас нет, поэтому маршрут только в bgp.l3vpn.0 и живёт. Это всё у меня тоже чудесно работает, но проблема то не в этом.

 

Как я и предсказывал в JTAC пошла вторая эскалация. Обычно к этому моменту начинают попадаться грамотные люди. По крайней мере их разговорный английский уже можно понимать :)

[_am_]

Несколько раз встречался с подобной проблемой. Правда в моём случае это были direct маршруты (про pe-ce ebgp + rr + rib-group не помню, вроде работало). От JTAC удалось добиться только открытия публичного PR726593, который всё ещё в статусе "open". Попробуй сослаться на этот PR, проблемы схожи.

 

На всякий случай - а в vrf-export проликаные маршруты точно матчатся и на них навешивается корректная rt-ext-community ?

[mightyscv]

PR726593

Спасибо, это ровно оно.

 

Собственно, ещё до указания этого PR подтвердились опасения - эта проблема является особенностью поведения Junos. Логика такая, что RR пересылает только те VRF маршруты, которые он видит в bgp.l3vpn.0, а так как ликнутые маршруты туда не попадают то он их и не анонсирует.

Juniper не считают это багом, но согласны, что логика кривая. Собираются делать enhancement request, то есть проблема будет решена, но учитывая приоритеты и цикл разработки - думаю годика так через два в лучшем случае.

 

Из решений кроме тех, что я уже перечислял, предложили ещё через LT сделать сессию самому с собой и в ней передать маршруты. Минусов у этого способа несколько:

- LT вносят дополнительную задержку;

- LT будут частью data plane, поэтому будут отъедать серьёзный кусок трафика от PIC, что придётся учитывать при планировании включений. В худшем сценарии(трафик 10G и более) - один PIC практически полностью выпадает;

- конфигурация будет сложной, так что поддерживать её будет дорого. Большое поле для возможных ошибок.

 

Вопрос можно считать закрытым.

[Stak]

Немного не по теме, но близко - а у других вендоров (ну скажем , циско или хуавей) есть возможность сделать ликинг между global и vrf (исключая статик роуты и туннели)?

[s.lobanov]

Stak

Cisco IOS XR

http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-3/routing/configuration/guide/b_routing_cg43xcrs/b_routing_cg43xcrs_chapter_010.html#concept_9961DC067F854EEDA4AA461A9EBE2DBD

[Stak]

Stak

Cisco IOS XR

http://www.cisco.com...4AA461A9EBE2DBD

 

Спасибо. Действительно, можно. А в IOS такой же фичи нет случайно?

 

BGP VRF Dynamic Route Leaking

 

 

The Border Gateway Protocol (BGP) dynamic route leaking feature provides the ability to import routes between the default-vrf (Global VRF) and any other non-default VRF, to provide connectivity between a global and a VPN host. The import process installs the Internet route in a VRF table or a VRF route in the Internet table, providing connectivity.

 

The dynamic route leaking is enabled by:

• Importing from default-VRF to non-default-VRF, using the import from default-vrf route-policy route-policy-name [advertise-as-vpn] command in VRF address-family configuration mode. If the advertise-as-vpn option is configured, the paths imported from the default-VRF to the non-default-VRF are advertised to the PEs as well as to the CEs. If the advertise-as-vpn option is not configured, the paths imported from the default-VRF to the non-default-VRF are not advertised to the PE. However, the paths are still advertised to the CEs.
• <a name="concept_9961DC067F854EEDA4AA461A9EBE2DBD__li_A1047F81EB8649399346DA9A51F10503">Importing from non-default-VRF to default VRF, using the export to default-vrf route-policy route-policy-name command in VRF address-family configuration mode.

A route-policy is mandatory to filter the imported routes. This reduces the risk of unintended import of routes between the Internet table and the VRF tables and the corresponding security issues.

 

There is no hard limit on the number of prefixes that can be imported. The import creates a new prefix in the destination VRF, which increases the total number of prefixes and paths. However, each VRF importing global routes adds workload equivalent to a neighbor receiving the global table. This is true even if the user filters out all but a few prefixes. Hence, importing five to ten VRFs is ideal.

 

 

[alks]

Stak

Cisco IOS XR

http://www.cisco.com...4AA461A9EBE2DBD

 

Спасибо. Действительно, можно. А в IOS такой же фичи нет случайно?

 

 

есть в виде костыля

https://supportforums.cisco.com/discussion/11193411/route-leaking-vrf-global-same-router-vlan-interface

http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/47807-routeleaking.html#global

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/12-4t/mp-l3-vpns-12-4t-book/mp-vpn-vrf-select-rt.html

[s.lobanov]

Stak

Cisco IOS XR

http://www.cisco.com...4AA461A9EBE2DBD

 

Спасибо. Действительно, можно. А в IOS такой же фичи нет случайно?

 

 

есть в виде костыля

https://supportforums.cisco.com/discussion/11193411/route-leaking-vrf-global-same-router-vlan-interface

http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/47807-routeleaking.html#global

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/12-4t/mp-l3-vpns-12-4t-book/mp-vpn-vrf-select-rt.html

всё читать не стал, но по-диагонали, там обычный статический маршрут vrf-global, а не динамический импорт-экспорт. ни и стандартный импорт-экспорт между врфами

[alks]

всё читать не стал, но по-диагонали, там обычный статический маршрут vrf-global, а не динамический импорт-экспорт. ни и стандартный импорт-экспорт между врфами

 

именно так, статика, вы знаете способ передавать динамически между grt - vrf?

[rdntw]

Не то?

https://www.juniper.net/documentation/en_US/junos14.2/topics/example/vpns-layer-3-route-resolution-route-reflector.html