RIB Failure

[maher]

Hi there,

I'm experience a weired thing on my PE1 vpnv4 route:

PE1#sh ip bgp vpnv4 all

BGP table version is 45, local router ID is 200.6.0.7

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

Route Distinguisher: 2020:1 (default for vrf customer)

*> 10.10.10.1/32 0.0.0.0 0 32768 ?

*>i10.10.10.2/32 200.6.0.10 0 100 0 ?

*> 200.6.0.8/32 200.6.0.106 11 32768 ?

r>i200.6.0.11/32 200.6.0.10 11 100 0 ?

*> 200.6.0.104/30 0.0.0.0 0 32768 ?

r>i200.6.0.112/30 200.6.0.10 0 100 0 ?

*> 172.16.1.0/30 200.6.0.106 74 32768 ?

* i 200.6.0.10 74 100 0 ?

*> 192.168.1.1/32 200.6.0.106 11 32768 ?

r>i192.168.2.1/32 200.6.0.10 11 100 0 ?

Since the r indicator does not show in the next PE(in PE2).CE to CE are able to ping and traceroute.

What is actually happen in "sh ip bgp vpnv4 vrf customer" which indicates the "r"?

Thanks in advance.

maher

[mmolina2]

This link will probably answer your question:

http://www.cisco.com/warp/public/459/bgpfaq_5816.shtml#twenty-three

[maher]

Hi there,

Thanks for the link. However, I'm quite suprised that on the PE1, when I use sh ip route vrf customer :

PE1#sh ip route vrf customer

Routing Table: customer

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, 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

172.16.0.0/30 is subnetted, 1 subnets

O 172.16.1.0 [110/74] via 200.6.0.106, 00:34:46, FastEthernet1/0

10.0.0.0/32 is subnetted, 2 subnets

B 10.10.10.2 [200/0] via 200.6.0.10, 03:50:18

C 10.10.10.1 is directly connected, Loopback10

192.168.1.0/32 is subnetted, 1 subnets

O 192.168.1.1 [110/11] via 200.6.0.106, 00:34:46, FastEthernet1/0

192.168.2.0/32 is subnetted, 1 subnets

O 192.168.2.1 [110/51] via 200.6.0.10, 00:34:28

200.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O 200.6.0.11/32 [110/51] via 200.6.0.10, 00:34:29

O 200.6.0.8/32 [110/11] via 200.6.0.106, 00:34:48, FastEthernet1/0

O 200.6.0.112/30 [110/50] via 200.6.0.10, 00:34:29

C 200.6.0.104/30 is directly connected, FastEthernet1/0

Route from customer using OSPF already propagated..but RIB failed .... wonder why it could happen...perhaps because of this 3 reasons:

1.Route with better administrative distance already present in IGP, for example, if a static route already exists in IP Routing table. - no static under the customer routing table

2.Memory failure. - check already, not an issue

3.The number of routes in VPN routing/forwarding (VRF) exceeds the route−limit

configured under the VRF instance. - perhaps maybe because of route-limit? What is route-limit under VRF?

thanks in advance.

maher

[adityakaul]

The router is learning both the prefixes 200.6.0.11/32 and 200.6.0.112/30 thro OSPF also which has better protocol pref.

r>i200.6.0.11/32 200.6.0.10 11 100 0 ?

r>i200.6.0.112/30 200.6.0.10 0 100 0 ?

O 200.6.0.11/32 [110/51] via 200.6.0.10, 00:34:29

O 200.6.0.112/30 [110/50] via 200.6.0.10, 00:34:29

[maher]

Hi there,

Thanks for highlight.BTW, can we consider as a routing loops?Should it withdraw the prefixes 200.6.0.11/32 and 200.6.0.112/30 from the routing table vrf ?

thanks in advance.

maher

[syedjunaid]

RIB failure, occurs when the route is learned from both the IGP as well as the EGP and the route learnt from IGP has better administrative distance, or if a static route (same as the route learnt from the EGP) is in the routing table. or if there is a memory failure (Check if your system RAM is working fine or whether you have optimum memory).Another reason for the RIB failure is when the Number of routes in the VRF exceeds the route-limit that may have been configures for that instance - Check if there is a route-limit for the customer VRF.

The reason why this occurs is well explained in the below

Each protocol depends on CEF to continue forwarding packets during switchover while the routing protocols rebuild the Routing Information Base (RIB) tables. Once the routing protocols have converged, CEF updates the FIB table and removes stale route entries. CEF then updates the line cards with the new FIB information

Check out the information in the article for cisco caveats under heading

CSCeb26389

in the URL

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/prod_release_note09186a00801b3611.html

Check for for more information on tuning your IGP (OSPF in this case) under the heading - Additional Enhancements to SPF Computation Using Configured Tunnel Metrics

in URL below

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7fa.html

Check for your redistributed connected and static routes

for more information visit the BGP FAQ

Avoid any duplicate routes in your routing table and you will not have any problems with the RIB

[maher]

Hi there,

Thanks for the infomation given.I really appreciated.I have double check with the routes.So far no duplicate routes.However, you did mension about cisco IOS caveats, just replace and upgrade version and there is no more RIB failure.

Thanks for the info again.

regards,

maher