BGP RIB FAILURE

[ghulam.ghaznawi1]

Hi all, 

I have the following test topology for transit AS configuration. 

I cannot ping loopback IP addresses of ISP test 1 and test 2 from any of my internal routers as well as test 1 cannot reach to test 2. 

pr1_bl#sho ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
1.1.1.1/32 1.1.1.1 Higher admin distance Yes
2.2.2.2/32 2.2.2.2 Higher admin distance Yes
pr1_bl#

pr2_bl#sho ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
1.1.1.1/32 1.1.1.1 Higher admin distance Yes
2.2.2.2/32 2.2.2.2 Higher admin distance Yes
pr2_bl#

pr1_bl#sho ip route | section 2.2.2.2
O E2 2.2.2.2 [110/50] via 10.1.1.2, 00:19:07, Serial3/1
B 2.2.2.3 [200/0] via 2.2.2.2, 00:18:33
B 2.2.2.4 [200/0] via 2.2.2.2, 00:18:33
10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
pr1_bl#

pr2_bl#sho ip route | section 1.1.1.1
O E2 1.1.1.1 [110/50] via 10.1.1.1, 00:20:29, Serial3/1
B 1.1.1.2 [200/0] via 1.1.1.1, 00:02:37
B 1.1.1.3 [200/0] via 1.1.1.1, 00:02:37
2.0.0.0/32 is subnetted, 3 subnets
pr2_bl#

I am using OSPF as IGP and the OSPF and BGP configuration of both pr1_bl and and similar configuration is used on pr2_bl is as below. 

pr1_bl(config-router)#do sho run | sec router bgp
router bgp 500
no synchronization
bgp log-neighbor-changes
bgp suppress-inactive
network 150.1.0.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 description test 1 peer
neighbor 1.1.1.1 password cisco
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 remove-private-as
neighbor 20.20.20.20 remote-as 500
neighbor 20.20.20.20 description pr2_bl peer
neighbor 20.20.20.20 update-source Loopback0
neighbor 30.30.30.30 remote-as 500
neighbor 30.30.30.30 description pr3_bl peer
neighbor 30.30.30.30 update-source Loopback0
neighbor 40.40.40.40 remote-as 500
neighbor 40.40.40.40 description pr4_bl peer
neighbor 40.40.40.40 update-source Loopback0
no auto-summary
pr1_bl(config-router)#

pr1_bl#sho run | section router ospf
router ospf 1
router-id 10.10.10.10
log-adjacency-changes
redistribute static metric 50 subnets route-map OSPF_REDISTRIBUTION
passive-interface Serial3/0
passive-interface Serial3/3
network 10.1.1.1 0.0.0.0 area 0
network 10.1.1.5 0.0.0.0 area 0
network 10.10.10.10 0.0.0.0 area 0
network 17.9.1.0 0.0.0.255 area 0
pr1_bl#

pr1_bl#sho route-map OSPF_REDISTRIBUTION
route-map OSPF_REDISTRIBUTION, permit, sequence 10
Match clauses:
ip address (access-lists): OSPF_NEXT_HOPS
Set clauses:
Policy routing matches: 0 packets, 0 bytes
pr1_bl#sho ip acce
pr1_bl#sho ip access-lists OSPF_NEXT_HOPS
Standard IP access list OSPF_NEXT_HOPS
10 permit 1.1.1.1 (8 matches)
pr1_bl#

Test_1#traceroute 2.2.2.2  ! comment test 2 IP address is 2.2.2.2

Type escape sequence to abort.
Tracing the route to 2.2.2.2

1 17.9.1.2 12 msec
17.9.1.6 8 msec
17.9.1.2 8 msec
2 10.1.1.2 8 msec 16 msec 16 msec
3 *
Test_1#

Can anyone please help how to resolve this BGP RIB failure issue? 

Kind regards, 

Ghulam

[Jon Marshall]

Try doing the traceroute from Test_1 using 1.1.1.1 as the source IP address.

Jon

[Richard Burts · Accepted solution]

We do not have enough information to give a full explanation of this issue. But based on what we know so far, this is what we can say:

- first review of fundamental concpt - a RIB failure occurs when IOS attempts to insert a BGP learned route into the routing table and finds a route with a better admin distance in the routing table.

- this message shows that it attempted to insert 1.1.1.1 and fund a better route

1.1.1.1/32 1.1.1.1 Higher admin distance Yes

- these messages show that IOS learned 1.1.1.1 via BP but found a route with better admin distance

pr2_bl#sho ip route | section 1.1.1.1
O E2 1.1.1.1 [110/50] via 10.1.1.1, 00:20:29, Serial3/1
B 1.1.1.2 [200/0] via 1.1.1.1, 00:02:37
B 1.1.1.3 [200/0] via 1.1.1.1, 00:02:37

- these messages show that you are redistributing 1.1.1.1 into OSPF

pr1_bl#sho ip acce
pr1_bl#sho ip access-lists OSPF_NEXT_HOPS
Standard IP access list OSPF_NEXT_HOPS
10 permit 1.1.1.1 (8 matches)

I am not clear why you are redistributing 1.1.1.1 into OSPF, and I am not clear why you are learning 1.1.1.1 as a BGP route with admin distance 200. But the combination of those things is why you are getting the RIB failure.

HTH

Rick  

[ghulam.ghaznawi1]

Hi Richard, 

Thank you very much for your advice and useful information.

The reason I am redistributing 1.1.1.1 and 2.2.2.2 on pr1 and pr2 into OSPF is to let other internal routers (pr3 and pr4) know about these ISP loopback IP addresses, I am not exactly sure if this is optimal way to do so. 

And as you pointed to BGP admin distance of 200. I also don't know why it's showing 200 as if I am not mistaken, it should be 20 for ebgp.  Very good point, thank you. I'd not thought about it before. Let me check if I can find the reason behind it. 

Kind regards, 

Ghulam 

[ghulam.ghaznawi1]

I think the reason the BGP admin distance is showing 200 on pr1 is because it learns the routes for Test_2 from pr2 via IBGP, am I correct? 

Kind regards, 

Ghulam 

[Richard Burts]

Ghulam 

Yes the admin distance of 200 would indicate that it was an IBGP prefix. It is possible to change the admin distance used by EBGP and so it is possible that an EBGP prefix could have admin distance of 200 but there is no evidence in the BGP config that you posted that you are doing that. So it is a safe assumption that this reflects an IBGP advertisement.

HTH

Rick

[ghulam.ghaznawi1]

Hi Jon and Richard, 

Okay, I was incorrectly redistributing routes on Test_1 and Test_2 that is why pr1 and pr2 was showing BGP routes with admin distance 200 in the routing table. I removed the redistribution and simply used the network commands on Test_1 and Test_2 to advertise routes and it works fine. 

If the bgp rib failure is not a problem then my problem is solved. Thanks so much. 

As Richard mentioned, I need to learn more about the bgp rib failure concepts though :)

Kind regards, 

Ghulam 

Kind regards, 

Ghulam 

[Richard Burts]

Ghulam 

I am glad that you have discovered that you were doing redistribution but did not need that redistribution. So now the network is operating more as you had intended it to operate. I agree with Jon that a Rib failure is not necessarily a problem. It is simply an indication that BGP has attempted to insert an entry into the routing table and has found an entry for that prefix with a better admin distance. Whether that is a problem or not depends on finding what entry this is and what other entry has a better admin distance and whether that other entry is expected or not. In your case the Rib failure led you to discover redistribution that did not need to be done. So the Rib failure was related to a problem. But in other cases it may turn out that the other entry with a better admin distance was a correct behavior and the Rib failure is not a problem.

HTH

Rick 

[ghulam.ghaznawi1]

Hi Rick, 

Okay, thank you very much for your help. 

Kind regards, 

Ghulam 

[ghulam.ghaznawi1]

Hi Jon, 

Thank you very much for the advice. 

If I ping from Test_1 using loopback IP 1.1.1.1 as the source IP address it works and Test_1 can reach to Test_2.

However, the same will not work for internal routers, and I think this make sense as the Test_1 and Test_2 do not know how to reach back to the internal routers. And I am also concerned about the rib failure with higher admin distance issue. 

Test_1#ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/40/52 ms
Test_1#

Kind regards, 

Ghulam 

[Jon Marshall · Accepted solution]

BGP RIB failures are not necessarily a problem, it is simply that you have received the same route with a lower AD from another routing protocol (in this case OSPF) and so the BGP route (which must be an IBGP route) cannot be installed in the IP routing table.

However it is not clear why you are doing some of the things you are, see Rick's post for details.

Jon