[wtyd]

Есть cisco 6500, в ней создан vrf, для обмена маршрутами между vrf и не-vrf используется ibgp. Почему-то между ними передаются не все маршруты. Пробовали рефлектор включать, даже с обеих сторон рефлектор включали - не помогло.

 

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

 

Проблема главным образом актуальна из-за того, что в одном из маршрутизаторов, который в vrf, появился ebgp, маршруты от которого в не-vrf не проходят. Пробовали с этого маршрутизатора (на котором ebgp) поднять мультихоп бгп с не-врф, тогда маршрут появляется, но это какой-то изврат и при этом другой префикс начинает примерно раз в 15 секунд флапать (приходит анонс этого префикса, потом приходит withdrawn).

 

Для vrf что, bgp какой-то особенный ? Почему так может происходить ? Что можно попробовать сделать ? :-)

 

P.S. Почему между vrf сделан ibgp и зачем там вообще vrf, не спрашивайте :-). Всё в пределах одной автономки. Так исторически сложилось. vrf там не нужен, но переделать нет возможности.

[g3fox]

А маршрут к "next-hop" для тех маршрутов, коотрые не заносятся в GRT, у вас есть?

что показывает

sh ip bgp rib-fail

?

 

 

multihop нужен только для ebgp.

[wtyd]

А маршрут к "next-hop" для тех маршрутов, коотрые не заносятся в GRT, у вас есть?

что показывает

sh ip bgp rib-fail

?

 

 

multihop нужен только для ebgp.

 

Маршрут к некстхопу тех префиксов, которые не пролазят сквозь меж-vrf'ное bgp, есть, он известен через ospf.

"sh ip bgp rib-fail" показывает несколько префиксов, но среди них нет проблемных префиксов.

 

Про ibgp мультихоп я так выразился :-), просто нейборы не-connected, обычно у нас неборы connected либо между loopback'ами bgp настраивается.

[Smoke]

По дефолту канеш не появится, так как next-hop для префикса остается в VRF. Используйте import под vrf для leaking

[wtyd]

По дефолту канеш не появится, так как next-hop для префикса остается в VRF. Используйте import под vrf для leaking

 

... а пример команды можно ? Просто что такое leaking пока не понятно.

 

У нас на bgp между глобал и врф с обеих сторон указано next-hop self, наверное для этого ... хотя с другой стороны ibgp должно передавать next-hop неизменным.

Edited March 23, 2016 by wtyd

[VolanD666]

По дефолту канеш не появится, так как next-hop для префикса остается в VRF. Используйте import под vrf для leaking

Т.е. на одной железке vrf и global? Разве можно между ними лик делать?

[g3fox]

Я изначально и хотел написать про ликинг, но есть у меня подозрение, что между GRT и VRF нельзя ликинг.

Вообще, гуглится, но не вникал какие есть ограничения при этом.

Тыц

Edited March 23, 2016 by g3fox

[Smoke]

Как-то так

 

SIS-CISCO7606>ena
SIS-CISCO7606#sh ip vrf
 Name                             Default RD            Interfaces
 management                       65000:2               Vl15

SIS-CISCO7606#sh ip bgp vpnv4 vrf management 172.31.5.0
BGP routing table entry for 65000:2:172.31.5.0/24, version 2
Paths: (1 available, best #1, table management)
 Advertised to update-groups:
    5          3
 Refresh Epoch 1
 Local
   0.0.0.0 (via vrf management) from 0.0.0.0 (172.31.255.1)
     Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
     Extended Community: RT:65000:1
     mpls labels in/out IPv4 VRF Aggr:19/nolabel(management)
     rx pathid: 0, tx pathid: 0x0
SIS-CISCO7606#show ip route 172.31.5.0
Routing entry for 172.31.0.0/21
 Known via "static", distance 1, metric 0
 Redistributing via ospf 1
 Advertised by ospf 1 subnets route-map Static-2-OSPF
 Routing Descriptor Blocks:
 * 172.31.2.1
     Route metric is 0, traffic share count is 1
SIS-CISCO7606#sh run | sec vrf management
ip vrf management
rd 65000:2
route-target export 65000:1
route-target import 65000:2
route-target import 65000:5
route-target import 65003:3
route-target import 65000:4
route-target import 65000:6
route-target import 65000:7


SIS-CISCO7606(config)#ip prefix-list TEST2NAG permit 172.31.5.0/24
SIS-CISCO7606(config)#route-map TEST2NAG pe 10
SIS-CISCO7606(config-route-map)#match ip address prefix-list TEST2NAG
SIS-CISCO7606(config-route-map)#ip vrf management
SIS-CISCO7606(config-vrf)#export ipv4 unicast map TEST2NAG
SIS-CISCO7606(config-vrf)#end
SIS-CISCO7606#show ip route 172.31.5.0
Routing entry for 172.31.5.0/24
 Known via "bgp 198354", distance 20, metric 0 (connected, via interface), type external
 Routing Descriptor Blocks:
 * directly connected, via Vlan15
     Route metric is 0, traffic share count is 1
     AS Hops 0
     MPLS label: none
end

[wtyd]

А маршрут к "next-hop" для тех маршрутов, коотрые не заносятся в GRT, у вас есть?

что показывает

sh ip bgp rib-fail

?

 

 

multihop нужен только для ebgp.

 

А маршруты на некст-хопы должны быть в бгп или они могут быть известны через другие протоколы ? В бгп их нет если что.

[g3fox]

Могут быть известны и через другие протоколы. В т.ч. это может быть дефолт статикой.

[wtyd]

Могут быть известны и через другие протоколы. В т.ч. это может быть дефолт статикой.

 

Ну тогда у нас вообще нет идей, почему эти префиксы по бгп не проходят. Врф говорит, что они адвертайзятся, а GRT говорит, что их не получает даже в received-routes. Никаких фильтраций на этих нейборах нет. Нсли некст-хоп достижим любым способом, то анонс в бгп должен пройти же ... а он не проходит и непонятно почему.

[zi_rus]

не читал, но осуждаю :)

 

вообще у bgp полно loop prevention механизмов, я почти уверен что срабатывает один из них. например когда рефлектор отражает маршрут он в него прописывает originator-id и собственный cluster-id, если у него router-id сопадет в глобале и врф, он вообще ничего не должен принимать. но это так

нужен конфиг и пример роута который не проходит иначе это гадание

 

recieved-routes если я не ошибаюсь это роуты до искусственных фильтров (route-map, prefix-list), есл роут дропнулся по as path его там не будет - уверен на 80% :)

[wtyd]

не читал, но осуждаю :)

 

вообще у bgp полно loop prevention механизмов, я почти уверен что срабатывает один из них. например когда рефлектор отражает маршрут он в него прописывает originator-id и собственный cluster-id, если у него router-id сопадет в глобале и врф, он вообще ничего не должен принимать. но это так

нужен конфиг и пример роута который не проходит иначе это гадание

 

recieved-routes если я не ошибаюсь это роуты до искусственных фильтров (route-map, prefix-list), есл роут дропнулся по as path его там не будет - уверен на 80% :)

 

router id разные, конфиг показать пока не могу ... слишком много исправлять :-(

 

в выводе sh ip bgp nei <ip> есть вот такое:

 NEXT_HOP is always this router
                                Sent       Rcvd
 Prefix activity:               ----       ----
   Prefixes Current:             297         11 (Consumes 572 bytes)
   Prefixes Total:               594         45
   Implicit Withdraw:            297         33
   Explicit Withdraw:              0          1
   Used as bestpath:             n/a         11
   Used as multipath:            n/a          0

                                  Outbound    Inbound
 Local Policy Denied Prefixes:    --------    -------
   CLUSTER_LIST loop:                  n/a         12  <--- вот это вот смущает
   Bestpath from this peer:             26        n/a
   Suppressed due to dampening:          8        n/a
   Bestpath from iBGP peer:              2        n/a
   Total:                               36         12
 Number of NLRIs in the update sent: max 288, min 0

 

еслия правильно понял, то 12 префиксов были заденаены, аналогичное в vrf тоже есть денаи, их 4. Как узнать какие и почему ?

Edited March 23, 2016 by wtyd

[zi_rus]

ну это как раз про что я и говорю по route-reflector cluster-id

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

[wtyd]

ну это как раз про что я и говорю по route-reflector cluster-id

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

 

в конфиге bgp router-id заданы явно и они разные для GRT и для vrf. Соседние ойпи адреса, отличаются на единицу. Так было давно сделано.

 

... т.е. я имею ввиду "bgp router-id", а где "route-reflector cluster-id" посмотреть ? Он наверное и не конфигурится. ...

Edited March 23, 2016 by wtyd

[zi_rus]

конфигурится, по дефолту берется из router-id

 

R1(config-router)#bgp cluster-id ?
 <1-4294967294>  Route-Reflector Cluster-id as 32 bit quantity
 A.B.C.D         Route-Reflector Cluster-id in IP address format

 

UPD действительно посмотрел, в отдельном врф можно router-id настроить, а вот rr cluster-id я там не вижу

[wtyd]

конфигурится, по дефолту берется из router-id

 

R1(config-router)#bgp cluster-id ?
 <1-4294967294>  Route-Reflector Cluster-id as 32 bit quantity
 A.B.C.D         Route-Reflector Cluster-id in IP address format

 

UPD действительно посмотрел, в отдельном врф можно router-id настроить, а вот rr cluster-id я там не вижу

 

А увидеть этот Route-Reflector Cluster-id хотя бы как-то можно ? Настроить нельзя, но хотя бы узнать, какой он в grt и какой в vrf как ?

 

Я, кажется, знаю, в чём там дело :-). Сегодня попробуем переделать схему bgp. Там шеститонник на две части разделён с помощью vrf и в обеих его частях настроен рефлектор, надо сделать один рефлектор и тогда всё должно зафунциклировать.

[wtyd]

Флапающий маршрут я нашёл, это из-за ospf было. На одном бордере в бгп была прописана network и она то анонсилать, то отзывалась. Маршрут на неё через ospf появлялся/исчезал. В общем, network убрал, с ним позже буду разбираться, а вот с бгп пока загадки :-). Поднял две брп сесси с бордера до grt и до vrf, всё заработало, но почему одной сессии не хватает, я уашпе вообще не понимаю :-). Почему-то с одной сессией rib failure, но все некст-хопики есть в ospf, почему так ? :-).

 

Ещё идеологический вопрос: как можно организовать iBGP ? В нашем случае сделано примерно так: на роутерах подняты лупбаки /32, маршруты о которых распространяются по ospf, т.е. все роутеры знают о всех лупбаках в сети. Есть "ядро/роут-рефлектор", с которым все роутеры сети имеют iBGP. Идеологически же так правильно (как вариант) ?

Edited March 24, 2016 by wtyd

[CityFox]

А у вас при анонсе маршрутов из vrf в global у них vrf extended community (те в которых route target) проходят?

Попробуйте все community сбрасывать.

Сталкивался с проблемой из-за того что в глобальную таблицу попадали маршруты с установленным vrf route target.

Edited March 24, 2016 by CityFox

[wtyd]

А у вас при анонсе маршрутов из vrf в global у них vrf extended community (те в которых route target) проходят?

Попробуйте все community сбрасывать.

Сталкивался с проблемой из-за того что в глобальную таблицу попадали маршруты с установленным vrf route target.

 

Мдя ... там в настройках вообще нет send community и соответственно вообще нет никаких комьюнити. Может афектить ?

[zi_rus]

А увидеть этот Route-Reflector Cluster-id хотя бы как-то можно ? Настроить нельзя, но хотя бы узнать, какой он в grt и какой в vrf как ?

 

#show ip bgp cluster-ids 
Global cluster-id: 10.68.81.1 (configured: 0.0.0.0)
BGP client-to-client reflection:         Configured    Used
 all (inter-cluster and intra-cluster): ENABLED
 intra-cluster:                         ENABLED       ENABLED

List of cluster-ids:
Cluster-id     #-neighbors C2C-rfl-CFG C2C-rfl-USE

[zi_rus]

Из интереса собрал топологию в gns

как я и предполагал

 

router bgp 1
bgp router-id 1.1.1.1
bgp log-neighbor-changes
redistribute connected
neighbor 11.11.11.11 remote-as 1
neighbor 11.11.11.11 update-source Loopback1
neighbor 11.11.11.11 route-reflector-client
neighbor 192.168.12.2 remote-as 1
neighbor 192.168.12.2 route-reflector-client
!
address-family ipv4 vrf a
 bgp router-id 11.11.11.11
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback11
 neighbor 1.1.1.1 activate
exit-address-family

 

R1#debug bgp vrf a ipv4 unicast updates 
 
R1#clear ip bgp 11.11.11.11
 
*Mar 24 11:39:35.539: BGP(0): (base) 11.11.11.11 send UPDATE (format) 1.1.1.1/32, next 1.1.1.1, metric 0, path Local
*Mar 24 11:39:35.539: BGP(0): (base) 11.11.11.11 send UPDATE (format) 2.2.2.2/32, next 192.168.12.2, metric 0, path Local
*Mar 24 11:39:35.551: BGP(0): 1.1.1.1 rcv UPDATE w/ attr: nexthop 192.168.12.2, origin ?, localpref 100, metric 0, originator 2.2.2.2, clusterlist 1.1.1.1, merged path , AS_PATH , community , extended community , SSA attribute 
[u][b]*Mar 24 11:39:35.555: BGP(0): 1.1.1.1 rcv UPDATE about 2.2.2.2/32 -- DENIED due to: reflected from the same cluster;[/b][/u]

[s.lobanov]

если вам нужен RR в vrf, то просто поставьте две виртуалки/контейнера с bird и сделайте на нём, который не будет знать, что он в vrf )

 

но очевидно, что это ошибка дизайна, впрочем, ТС это и так знает

[zi_rus]

я полагаю он не хочет rr в vrf. просто по-другому на интернал сессиях не проанонсить маршруты.

хотя если врф и грт представляют из себя одну общую плоскую сеть то наверное можно выделить rr который будет заниматься распространением маршрутов, а не делать р2р сессию на перемычке, тогда и проблем не будет

[wtyd]

я полагаю он не хочет rr в vrf. просто по-другому на интернал сессиях не проанонсить маршруты.

хотя если врф и грт представляют из себя одну общую плоскую сеть то наверное можно выделить rr который будет заниматься распространением маршрутов, а не делать р2р сессию на перемычке, тогда и проблем не будет

 

Да, я хотел бы иметь один rr на grt, а все остальные роутеры сделать клиентами его, в т.ч. и vrf. Когда я так пробую сделать, то маршруты по бгп расползаются, но некоторые из них rib-failure, включая тот проблемный префикс, потому что в ospf ещё какая-то заковырка есть. В общем, разбираемся, пока дыру с не прохождением префикса ликвидировали, потом займёмся остальным бгп.