Scribd
Upload
1K views4 pages

BGP Rib Failure

BGP RIB-Failure is a situation where some routes from the bgp process cannot be installed in the main routing table. A route with a better administrative distance is already installed in the routing table; the route in question is a directly connected network (special case with the lower administrative distance); a memory problem on the receiving bgp speaker prevents the route from getting installed in the RIB;.

Uploaded by

Abbas Khan
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
1K views4 pages

BGP Rib Failure

BGP RIB-Failure is a situation where some routes from the bgp process cannot be installed in the main routing table. A route with a better administrative distance is already installed in the routing table; the route in question is a directly connected network (special case with the lower administrative distance); a memory problem on the receiving bgp speaker prevents the route from getting installed in the RIB;.

Uploaded by

Abbas Khan
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

BGP RIB-Failure

BGP RIB-Failure is a situation where some routes from the BGP process cannot be
installed in the main routing table due to different reasons::

• A route with a better administrative distance is already installed in the routing


table (i.e. a static route/route from an IGP with a better administrative distance);
• The route in question is a directly connected network (special case of the previous
point with the lower administrative distance);
• The route is for a host IP address configured on the receiving BGP speaker;
• Installing the route in the routing table will cause the configured route-limit for a
particular VRF to be exceeded (when using VRF);
• A memory problem on the BGP speaker prevents the route from getting installed
in the RIB;

In such cases, the failed routes are marked with an r> in the list of BGP routes:

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#

We can check all RIB-Failure routes on our BGP router with 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#

If we have a look at the show ip bgp information for each of these network, we will see
the individual RIB-Failure code but not much else:

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#

If we have a look at the routing table as far as each of these networks is concerned, we
can find out th reason for the RIB-Failure:

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#

Each of the three routes is present in the routing table, but one of them is R1’s own IP
address on Loopback0, the other one is learnt via EIGRP and is thus with a better admin
distance, and the the third one is a directly connected network via Fa0/0. Even though the
routes are set to RIB-Failure status, they are actually being advertised to R1’s eBGP
peer, which differs a bit from what is mentioned in Cisco’s BGP FAQ document. The lab
topology is shown below for illustration.
Sample lab for BGP RIB-Failure

In our test scenario R0 is announcing the three relevant networks into the iBGP process
to R1, but R1 has better routes already present for all of them - either from EIGRP
(.30.0/24), or a directly connected one (.1.0./30), or is it a route to its own IP address
(.0.1/32). R1 itself has an eBGP peering session with R2. Let’s have a look at what R2 is
receiving over this eBGP session and whether the RIB-Failure routes are being advertised
and accepted over it:

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#

As we can see, all the RIB-Failure routes are being advertised and accepted normally
over the eBGP peering regardless of their RIB-Failure state. They are not flagged as RIB-
Failure routes on R2 and they are installed in the routing table at 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#

You might also like