BGP rib failure:Best steps to eliminate it

[news2010a]

Hi, can you clarify best steps to find the source and eliminate this RIB failure in red below. Full show run from both r1 and r5 routers are attached.
First step is that I go to the next hop (150.4.5.5) indicated at the rib failure. Then I compared BGP and EIGRP statements there. Is the reason for the rib failure because I have 155.4.0.0 and 155.4.0.0/24 advertised under eigrp and bgp?

Rack4R1#show ip bgp
BGP table version is 92, local router ID is 150.4.1.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
*>i28.119.16.0/24   54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
*>i28.119.17.0/24   54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
*>i54.4.1.0/24      150.4.6.6                0    100      0 i
*>i112.0.0.0        54.4.1.254               0    100      0 54 50 60 i
* i                 204.12.4.254             0    100      0 54 50 60 i
*>i113.0.0.0        54.4.1.254               0    100      0 54 50 60 i
* i                 204.12.4.254             0    100      0 54 50 60 i
*>i114.0.0.0        54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
*>i115.0.0.0        54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
*>i116.0.0.0        54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
*>i117.0.0.0        54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
   Network          Next Hop            Metric LocPrf Weight Path
*>i118.0.0.0        54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
*>i119.0.0.0        54.4.1.254               0    100      0 54 i
* i                 204.12.4.254             0    100      0 54 i
*>i150.4.0.0        150.4.6.6                0    100      0 i
* i                 150.4.4.4                0    100      0 ?
r>i155.4.0.0/24     150.4.5.5                0    100      0 i
*>i155.4.0.0        150.4.6.6          2172416    100      0 i
* i                 150.4.4.4                0    100      0 ?
*>i204.12.4.0       150.4.4.4                0    100      0 i
Rack4R1#show run | s eigrp
router eigrp 100
network 150.4.1.1 0.0.0.0
network 155.4.0.0 0.0.0.255
network 155.4.146.0 0.0.0.255
no auto-summary
Rack4R1#show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor IBGP_PEERS peer-group
neighbor IBGP_PEERS remote-as 100
neighbor IBGP_PEERS update-source Loopback0
neighbor IBGP_PEERS route-reflector-client
neighbor 150.4.3.3 peer-group IBGP_PEERS
neighbor 150.4.4.4 peer-group IBGP_PEERS
neighbor 150.4.5.5 peer-group IBGP_PEERS
neighbor 150.4.6.6 peer-group IBGP_PEERS
no auto-summary
Rack4R1#
RSRack4AS>5
[Resuming connection 5 to R5 ... ]

Rack4R5#show run | s eigrp
no ip split-horizon eigrp 100
router eigrp 100
network 150.4.5.0 0.0.0.255
network 155.4.0.0
no auto-summary
Rack4R5#show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 155.4.0.0 mask 255.255.255.0
neighbor 150.4.1.1 remote-as 100
neighbor 150.4.1.1 update-source Loopback0
no auto-summary
Rack4R5#

[Jon Marshall · Accepted solution]

news2010a wrote:
Hi, can you clarify best steps to find the source and eliminate this RIB failure in red below. Full show run from both r1 and r5 routers are attached.
First step is that I go to the next hop (150.4.5.5) indicated at the rib failure. Then I compared BGP and EIGRP statements there. Is the reason for the rib failure because I have 155.4.0.0 and 155.4.0.0/24 advertised under eigrp and bgp? 
 Rack4R5#

Marlon

Basically yes, because IBGP AD is 200 and EIGRP AD is 90 (Internal) and 170 (External). So the BGP route cannot be inserted into the routing table because the EIGRP route is preferred and in the route table.

If you run "sh ip bgp rib-failure" on the router it should give you an idea why it was not installed in the routing table.

Edit - note that just because it failed to install in the routing table, this will not stop the BGP process from advertising this route to other BGP peers. If you don't want this happening use the "bgp suppress-inactive" command.

Jon

[news2010a]

Just trying to reproduce this on a very small scenario:
I connected two routers, R1 and R2. I advertised the loopback network via iBGP and via EIGRP on both routers. As you can see in red, EIGRP as expected installed that on the routing table.

Question:Any idea why I did not get the RIB failure in this case? Very curious.

As you can see, the EIGRP

R1#sho run int lo 0
Building configuration...

Current configuration : 67 bytes
!
interface Loopback0
ip address 192.168.1.1 255.255.255.255
end

R1#show ip bgp
BGP table version is 4, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 155.0.1.0/24     0.0.0.0                  0         32768 i                     <== I got no RIB failure even though routes are advertised in both EIGRP and BGP.
* i                 155.0.1.2                0    100      0 i
* i192.168.1.0      155.0.1.2                0    100      0 i
*>                  0.0.0.0                  0         32768 i

R1#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
       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

     155.0.0.0/24 is subnetted, 1 subnets
C       155.0.1.0 is directly connected, FastEthernet1/0
     192.168.1.0/32 is subnetted, 2 subnets
C       192.168.1.1 is directly connected, Loopback0
D       192.168.1.2 [90/156160] via 155.0.1.2, 00:07:55, FastEthernet1/0
R1#

R2#show run | b eigrp
router eigrp 100
network 155.0.1.0 0.0.0.255
network 192.168.1.2 0.0.0.0
no auto-summary
no eigrp log-neighbor-changes
!
router bgp 100
bgp log-neighbor-changes
network 155.0.1.0 mask 255.255.255.0
network 192.168.1.0
neighbor 155.0.1.1 remote-as 100
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!

R2#show ip bgp
BGP table version is 3, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i155.0.1.0/24     155.0.1.1                0    100      0 i
*>                  0.0.0.0                  0         32768 i
* i192.168.1.0      155.0.1.1                0    100      0 i
*>                  0.0.0.0                  0         32768 i
R2#

[AJAZ NAWAZ]

anyone know what the expected behaviour when aggregating bgp prefixes please ...?

i.e. the originating more specific route is learned via OSPF

I am router running ospf and bgp

I am receiving /23 prefix via OSPF

I add the same /23 using network command under BGP

I add the aggregate-address summ-only cmd to change the /23 to /20

I don't think r> should appear for the summary prefix. One one of my gateways it does, and on another it doesn't. Its odd. Suspect bug or misconfig. Perhaps prefix-list problem...?

[Jon Marshall]

Marlon

Can you post full configs for R1 & R2 ?

Jon

[Edison Ortiz]

You are originating both routes into BGP on both routers. Notice, you have multiple routes in the BGP table and the best route's next hop is 0.0.0.0 (locally originated).

You will get a RIB failure on R2 if R1 is the only router doing the advertising.

[marikakis]

Just a note on the original scenario: I think that both routers have 155.4.0.0/24 as a directly connected subnet under their serial interfaces, so one router is sending to the other via BGP a common subnet. This is not something that can be manipulated e.g. by playing with ADs (connected are too powerful and need more violent measures to go away, but in most cases the problem, if one exists, is somewhere else).

In this last case you have 2 loopbacks with /32 masks. You advertise the same /24 using the "network 192.168.1.0" command on both routers. Because you omit the mask and auto-summary is enabled for BGP, route is advertised via iBGP by both routers (no need for exact match anymore, just a subset of the /24 suffices). The routing table output you posted from R1 shows /32's, not a /24 for 192.168.1.0.(Note also that the routing table of R1 shows that the subnet 155.0.1.0/24 is known via connected, and at least part of it has to be known by some other means other than BGP, since it is used in the BGP neighbor statements). If you advertised only a single /32 from each router (the one it has under it's own loopback) via EIGRP and BGP, we would have a better chance to see Edison's suggestion in action.

[news2010a]

I attempted to do what Edison suggested; I advertised the routes on BGP only from R1. I still don't see the RIB failure.

Maria, thanks for the observation regarding the loopback /32 bit mask. Very good catch. Now I keep that consistent and advertise it as /32 under EIGRP and BGP. I also made sure BGP is no auto-summary.

If you have time to review this, please let me know why I can't produce a RIB failure.

R1#show run
Building configuration...

Current configuration : 911 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R1
!
!
ip subnet-zero
!
!
!
!
!
!
interface Loopback0
ip address 192.168.1.1 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
description R2
ip address 155.0.1.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
no ip address
shutdown
duplex auto
speed auto
!
!
!
router eigrp 100
network 155.0.1.0 0.0.0.255
network 192.168.1.1 0.0.0.0
no auto-summary
no eigrp log-neighbor-changes
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 155.0.1.0 mask 255.255.255.0
network 192.168.1.1 mask 255.255.255.255
neighbor 155.0.1.2 remote-as 100
no auto-summary
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!
end

R1#show ip bgp
BGP table version is 11, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 155.0.1.0/24     0.0.0.0                  0         32768 i
*> 192.168.1.1/32   0.0.0.0                  0         32768 i
R1#show ip route
(omitted)
       P - periodic downloaded static route

Gateway of last resort is not set

     155.0.0.0/24 is subnetted, 1 subnets
C       155.0.1.0 is directly connected, FastEthernet1/0
     192.168.1.0/32 is subnetted, 2 subnets
C       192.168.1.1 is directly connected, Loopback0
D       192.168.1.2 [90/156160] via 155.0.1.2, 00:15:13, FastEthernet1/0
R1#

R2#show run
Building configuration...

Current configuration : 831 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R2
!
!
ip subnet-zero
!
!
!
!
!
!
interface Loopback0
ip address 192.168.1.2 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
description R1
ip address 155.0.1.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
no ip address
shutdown
duplex auto
speed auto
!
!
!
router eigrp 100
network 155.0.1.0 0.0.0.255
network 192.168.1.2 0.0.0.0
no auto-summary
no eigrp log-neighbor-changes
!

!- I am advertising networks into BGP only on R1.
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 155.0.1.1 remote-as 100
no auto-summary
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!
end

R2#show ip bgp
BGP table version is 13, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i155.0.1.0/24     155.0.1.1                0    100      0 i
*>i192.168.1.1/32   155.0.1.1                0    100      0 i
R2#show ip route
(omitted)

Gateway of last resort is not set

     155.0.0.0/24 is subnetted, 1 subnets
C       155.0.1.0 is directly connected, FastEthernet1/0
     192.168.1.0/32 is subnetted, 2 subnets
D       192.168.1.1 [90/156160] via 155.0.1.1, 00:11:45, FastEthernet1/0
C       192.168.1.2 is directly connected, Loopback0
R2#

[marikakis]

The circumstances that rib failures occur are not very well documented, and to be honest I never had the pleasure of exploring them in a production network. A good link that explains them is this:

http://blog.ioshints.info/2007/12/what-is-bgp-rib-failure.html

As you can see, the exact behavior depends on the IOS version you are running, so may I ask if the routers you use now to reproduce the original scenario are the same ones as used initially and what IOS version they are running?

[news2010a]

No, the IOS version is different.

If we can't reproduce the problem that is totally fine. I am sure I will find several more rib failures to analyze in the months ahead.

[Richard Burts]

Marlon

Your question asking how you can eliminate the Rib failures implies that you regard them as a problem that should be "solved". Assuming that there is good reason to advertise the same prefixes by EIGRP and by BGP then the Rib failure is really more of an informational event (BGP is reporting that the route that it learned is not inserted into the routing table because an equivalent EIGRP route is present and is preferable) than it is a problem.

If you change the environment and the prefix is advertised by BGP or by EIGRP (but not by both) then the Rib failure goes away.

HTH

Rick

[marikakis]

Hi Rick,

I agree with you that this "failure" doesn't necessarily indicate a problem. I used in a previous post of mine in this thread the phrase "the problem, if one exists, is somewhere else", to say this, but maybe I was not very clear. However, I also had in mind a previous thread that Marlon had opened, in which the BGP route and the IGP route seemed to have some disagreement about the correct path through the network towards the destination. So, it doesn't matter which protocol installs the route, as long as it is a correct (or preferred) one that ultimately leads to the destination.

Kind Regards,

Maria