BGP RIB Failure

BGP RIB-Failure е ситуация, при която маршрути от BGP базата данни не могат да бъдат инсталирани в главната рутинг таблица, по различни причини:

  • Маршрутът вече е инсталиран в маршрутната таблица с по-нисък administrative distance (напр. статичен маршрут или научен от вътрешен протокол);
  • Маршрутът е директно свързана мрежа (частен случай на по-ниският administrative distance);
  • Маршрутът е до IP адрес на получаващия рутер;
  • Инсталирането на този маршрут в рутинг таблицата ще надвиши лимита за маршрути, зададен на конкретен VRF (при наличие на VRF-и);
  • Проблем с паметта на рутера не позволява маршрутът да бъде инсталиран в таблицата;

В такива случаи, въпросните маршрути са маркирани с r>; в списъка на BGP маршрути, например:

R1#sh ip bgp
BGP table version is 9, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
r>i192.168.0.1/32   192.168.1.1              0    100      0 i
r>i192.168.1.0/30   192.168.1.1              0    100      0 i
*>i192.168.10.0     192.168.1.1              0    100      0 i
r>i192.168.30.0     192.168.1.1              0    100      0 i
R1#

Можем да прегледаме всички маршрути, които са в RIB-Failure статус с show ip bgp rib-failure :

R1#sh ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
192.168.0.1/32 192.168.1.1 Own IP address n/a
192.168.1.0/30 192.168.1.1 Higher admin distance n/a
192.168.30.0 192.168.1.1 Higher admin distance n/a
R1#

Ако прегледаме всяка една от тези три мрежи по отделно с show ip bgp няма да забележим нищо кой-знае колко повече:

R1#sh ip bgp 192.168.0.1/32
BGP routing table entry for 192.168.0.1/32, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(4) - next-hop mismatch)
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#sh ip bgp 192.168.1.0/30
BGP routing table entry for 192.168.1.0/30, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#sh ip bgp 192.168.30.0
BGP routing table entry for 192.168.30.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

Причините можем да установим ако прегледаме маршрутната таблица за всяка от тези мрежи:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

D    192.168.30.0/24 [90/156160] via 192.168.1.9, 01:40:21, FastEthernet2/0
B    192.168.10.0/24 [200/0] via 192.168.1.1, 01:46:46
C    192.168.255.0/24 is directly connected, FastEthernet1/0
192.168.0.0/32 is subnetted, 1 subnets
C       192.168.0.1 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 3 subnets
C       192.168.1.8 is directly connected, FastEthernet2/0
C       192.168.1.0 is directly connected, FastEthernet0/0
C       192.168.1.4 is directly connected, FastEthernet0/1
R1#

Виждаме, че за всеки от трите маршрута има данни в рутинг таблицата, като единият от тях е собственият IP адрес на R1, другият е научен по EIGRP, а третият е директно свързана мрежа през fa0/0. Въпреки, че тези BGP маршрути не са инсталирани в рутинг таблицата, те продължават да бъдат анонсирани към BGP peer-а на R1, за разлика от споменатото в BGP FAQ документа от Cisco. За илюстрация на ситуацията тестовата топология е изложена по-долу.

Sample topology for BGP RIB Failure

Sample lab for BGP RIB-Failure

В случая, R0 анонсира въпросните няколко мрежи в iBGP процеса към R1, за които R1 има по-добър маршрут от EIGRP (.30.0/24), директно свързани са (.1.0./30), или е собственият му IP адрес (.0.1/32). R1 от своя страна има eBGP сесия към R2. Нека прегледаме какво R2 получава по тази eBGP сесия и дали RIB-Failure маршрутите се анонсират към него:

R2#sh ip bgp
BGP table version is 5, local router ID is 192.168.20.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.1/32   192.168.1.5                            0 100 i
*> 192.168.1.0/30   192.168.1.5                            0 100 i
*> 192.168.10.0     192.168.1.5                            0 100 i
*> 192.168.30.0     192.168.1.5                            0 100 i
R2#

Както се вижда, всички RIB-Failure маршрути се анонсират и се приемат нормално по eBGP сесията независимо от RIB-Failure статуса им. Те не са в RIB-Failure състояние на R2 и са инсталирани в маршрутната таблица:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.30.0/24 [20/0] via 192.168.1.5, 02:27:02
B    192.168.10.0/24 [20/0] via 192.168.1.5, 02:27:02
C    192.168.20.0/24 is directly connected, Loopback0
192.168.0.0/32 is subnetted, 1 subnets
B       192.168.0.1 [20/0] via 192.168.1.5, 02:27:02
192.168.1.0/30 is subnetted, 2 subnets
B       192.168.1.0 [20/0] via 192.168.1.5, 02:27:02
C       192.168.1.4 is directly connected, FastEthernet0/0
R2#

VRF Lite – VRF без MPLS

MPLS VRF-ите са едно колкото популярно, толкова и рекламирано решение за provider vpn-и и сегрегация на трафик в трета мрежа, което предлага и разчита на няколко неща, за да се продава 😉 :

  • Сегментиране на трафик между устройства на различни клиенти през трета мрежа, обикновено доставчик на услуга;
  • Възможност за запазване на маршрутната информация на клиента, чрез прозрачно пренасяне на маршрутната информация между неговите устройства от различните страни на мрежата на доставчика;
  • Възможност за доставчика да носи няколко маршрутни таблици, сегментирани една от друга, и евентуално включващи припокриващи се адресни пространства, вkл. RFC1918 адреси;

Решението за такава ситуация, базирано на MPLS VPN-и с различни VRF-и (Virtual Routing and Forwarding) разрешава всички от гореизброените проблеми на базата на няколко неща:

  • Настройка на маршрутно отношение между клиентският (Customer Edge – CE) рутер, и граничен рутер на доставчика (Provider Edge – PE), използвайки рутинг протокола на клиента;
  • Анонсиране от клиента на всички вътрешни мрежи по това рутинг отношение, както към вътрешен рутинг съсед в клиентската мрежа;
  • Наличие на поне една VRF инстанция за всеки клиент;
  • Маркиране от страна на PE устройството на клиентските маршрути със специфичен Route Distinguisher (RD) етикет, по този начин формирайки т.нар. VPNv4 адрес;
  • Редистрибуция от PE устройтвото на клиентските маршрути от клиентският рутинг протокол към MP-iBGP протокол, вървящ между PE устройствата в различните краища на мрежата на доставчика;
  • Наличие на стабилен вътрешен IGP рутинг протокол, осигуряващ свързаност на MPLS мрежата и косвено на MP-BGP;
  • Наличие на стабилна и мащабируема MPLS конфигурация в опорната мрежа на доставчика;

Всичко това е чудесно, ако сте доставчик, имащ готов MPLS Core. Ако обаче се опитвате да разработите специфично решение за собствени нужди, решение базирано на MPLS VPN ви изправя пред няколко предизвикателства, повечето от които са свързани с осигуряване на скъпи ресурси:

  • Настройка на 3 рутинг протокола на всяко PE-устройство (протокол на клиента, MP-BGP, и отделен вътрешен рутинг протокол);
  • Осигуряване  на достатъчно мощни и надеждни PE-рутери, способни да поддържат надеждно и мащабируемо 3те рутинг протокола, както и определен брой VRF-и;
  • Осигуряване на достатъчно мощни и надеждни core рутери, поддържащи MPLS Core на мрежата;

VRF Lite представлява VRF без изискване за опорна MPLS свързаност, и без необходимост от 3 рутинг протокола на PE устройствата. По този начин можем да постигнем пренос на няколко паралалелни рутинг таблици през опорна мрежа, без да имаме MPLS.

При използването на VRF с MPLS разделеността на комуникацията между рутинг таблиците се постига чрез използването на отделен рутинг протокол между PE устройствата, който носи различните маршрутни таблици, тагнати със съответният етикет. За да има разделяне на комуникацията и сегрегация на отделните рутинг таблици при използването на VRF Lite, т.е. без MPLS, трябва да има разделена комуникация между рутинг отношенията, носещи различните маршрутни таблици.

За илюстрация на двата варианта VRF, можем да използваме две топологии на тестови мрежи.

(more…)