cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2148
Views
15
Helpful
25
Replies

RIB-Failure even though AD looks right

jmcgrady1
Level 1
Level 1

I have an ISR 4430 advertising over a WAN via BGP to a 3925. The 3925 talks EIGRP to its local networks. The routes i'm advertising to the 3925 via BGP are listed with an AD of 20. The EIGRP routes seen by the 3925 have an AD of 170. Yet the EIGRP routes are being preferred and the report on rib-failure is as below. Any idea why the EIGRP routes would be preferred even though they have a higher distance?

 

show ip bgp rib-failure

  Network            Next Hop                      RIB-failure   RIB-NH Matches

0.0.0.0            10.38.240.2         Higher admin distance              n/a

10.5.44.0/27       10.38.240.2         Higher admin distance              n/a

10.24.1.2/32       10.38.240.2         Higher admin distance              n/a

10.35.0.0/16       10.38.240.2         Higher admin distance              n/a

25 Replies 25

Richard Burts
Hall of Fame
Hall of Fame

I agree that seeing what is in the config might be helpful (and might want to see more than just the bgp section). It would also be helpful if we could see the output of these commands

show ip route

show ip bgp neighbor

show ip bgp sum

 

HTH

 

Rick

HTH

Rick

As a test, i placed an inbound distribute-list on the eigrp config of C & D such that only subnets local to C & D would be received.  Then, when i checked the route table on C, those routes (from A) which previously reported as EIGRP (170) now appeared as iBGP (200) from D. And they were still overriding eBGP.

 

Next, on C, i did a 'clear ip bgp <AS of D>'. After that, the routing table correctly showed routes from A as eBGP (20) and the RIB-Failures disappeared. I dont see why clearing the neighbor would change the table so much.

Hi @jmcgrady1 

 

This is exactly what I said its a race condition in my previous post. To understand it further, think about the order of operation.

 

There are 3 different source of Routes. 

1. eBGP

2. iBGP

3. redistributed EIGRP route

 

In the first instance, when EIGRP route was selected due to highest redistributed weight and it being the best route in BGP then was also announced to EBGP neighbor unless there is some filtering. In such situations it is possible that upstream may not announce the eBGP route if it considers the route from D to be better. BGP only advertises best route to all peers but does not advertises  route back to peer if it receives the best route from it already. 

 

When your kill the redistribution through prefix-list you need to clear the BGP so that it can send the withdraw for that redistributed route to its ebgp peer.  Again the race condition, before you could withdraw the route, iBGP got installed. Only after you cleared the BGP which then withdrew the route you could see the correct eBGP. 

 

Like I mentioned in first post this is expected behavior and not really an anomaly. And the trick here is to modify the weights on the eBGP neighbors to be higher than the default 32768. This should be done on both eBGP routers and vice-versa on the other end of your topology.

 

Technically, you should only announce the local prefixes over eBGP and this should be done using AS-path access-list.

 

On both C&D, you should do this 

 

ip as-path acess-list 1 permit ^$
!
route-map AS-PATH-LOCAL
 match as-path 1 
!
router bgp <>
 neighbor x.x.x.x route-map AS-PATH-LOCAL out
!

That regular expression selects only site-local routes.

 

Please rate this post and others if your find them helpful.

 

Regards,

Sebastian

Thanks all for contributing to this discussion.   As a test, in my scenario, i removed EIGRP.  I then saw the local iBGP advertisement (AD 200) from C to D appearing in D's routing table and the same route advertised from B to D (eBGP 20) listed as rib-failure.  If i 'clear ip bgp <C AS>' on D, the rib failure clears and i see routes from B to D correctly listed.

I tried assigning weights in the BGP neighbor config on D for its neighbors B and C.  With B set to 35000 and C set to 1000 it didnt seem to help. I'm not sure how to make it such that B's advertisements are always preferred over C's

Can you paste 'show ip bgp x.x.x.x' showing both eBGP and iBGP route in that scenario you mentioned with the BGP preferring iBGP over eBGP. That should not be the case if you eBGP is received and as long as there are no pain points that should be always preferred. 

 

Sebastian

 

jmcgrady1
Level 1
Level 1

Below are some specifics from my environment. As described, A (AS 65065) & B (AS 65066) are at one site with C (AS 65042 10.42.240.1) & D (AS 65042 10.42.250.1, 10.42.240.2) at the other. Between B and D is a Telco (AS 65530 10.42.250.2).

Here is the routing table on D. Note the appearance of 0.0.0.0 via iBGP from C. This overrides 0.0.0.0 via eBGP from B.

You can see some successful routes from B, eg; 10.36.0.0

 

(on D) Gateway of last resort is 10.42.240.2 to network 0.0.0.0

B* 0.0.0.0/0 [200/0] via 10.42.240.2, 21:07:07
10.0.0.0/8 is variably subnetted, 45 subnets, 10 masks
B 10.5.44.0/27 [200/0] via 10.42.240.2, 21:07:07
B 10.24.250.0/29 [20/0] via 10.42.250.2, 2d06h
B 10.36.0.0/16 [20/0] via 10.42.250.2, 1d10h
B 10.38.0.0/16 [200/0] via 10.42.240.2, 21:07:07

 

(on D) sh ip bgp summ
BGP router identifier 10.42.240.1, local AS number 65042
BGP table version is 21596, main routing table version 21596
60 network entries using 8640 bytes of memory
77 path entries using 6160 bytes of memory
23/17 BGP path/bestpath attribute entries using 3680 bytes of memory
12 BGP AS-PATH entries using 288 bytes of memory
3 BGP community entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 18840 total bytes of memory
Dampening enabled. 0 history paths, 0 dampened paths
4 received paths for inbound soft reconfiguration
BGP activity 2445/2385 prefixes, 9016/8939 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.42.240.2 4 65042 1415 1444 21596 0 0 21:14:03 22
10.42.250.2 4 65530 6746 7148 21596 0 0 2d06h 47

 

Curiously, since removing EIGRP from this equation, i'm not seeing RIB failures. However i cant see why D is receiving an advertisement for 0.0.0.0 via eBGP, yet choosing the iBGP advertisement to place into its routing table

 

sh ip bgp nei 10.42.250.2 received-routes
BGP table version is 21596, local router ID is 10.42.240.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
* 0.0.0.0 10.42.250.2 0 65530 65066 i
*> 10.24.250.0/29 10.42.250.2 0 65530 i
* 10.36.0.0/16 10.42.250.2 0 65530 i
* 10.38.0.0/16 10.42.250.2 0 65530 65024 i

 

sh ip bgp nei 10.42.240.2 received-routes
BGP table version is 21597, local router ID is 10.42.240.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*>i 0.0.0.0 10.42.240.2 0 100 0 65065 i
*>i 10.5.44.0/27 10.42.240.2 0 100 0 65065 65048 i
* i 10.36.0.0/16 10.42.240.2 0 100 0 65065 65036 i
*>i 10.38.0.0/16 10.42.240.2 0 100 0 65065 65024 i

 

 

 

 

 

The reason D is choosing the IBGP default is because there is another AS (65530) between B and D which adds another AS to the AS path and that seems to be the deciding factor here. 

 

When you applied the configuration to modify the weights did you do a soft reset ? 

 

Jon

I'll arrange to do a soft reset. I haven't done that yet.

(on D) sh run | sec bgp

router bgp 65042
 bgp log-neighbor-changes
 bgp dampening
 network 10.35.0.0
 network 10.42.0.0 mask 255.255.0.0
 network 10.43.0.0 mask 255.255.0.0
 neighbor 10.42.240.2 remote-as 65042
 neighbor 10.42.240.2 update-source Loopback1
 neighbor 10.42.240.2 next-hop-self
 neighbor 10.42.240.2 soft-reconfiguration inbound
 neighbor 10.42.250.2 remote-as 65530
 neighbor 10.42.250.2 soft-reconfiguration inbound
 neighbor 10.42.250.2 weight 35000

 

sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 21617
Paths: (2 available, best #1, table default)
Flag: 0x820
  Not advertised to any peer
  Refresh Epoch 1
  65065, (received & used)
    10.42.240.2 (metric 10880) from 10.42.240.2 (10.42.240.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65530 65066, (received & used)
    10.42.250.2 from 10.42.250.2 (10.42.250.2)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

 

sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "bgp 65042", distance 200, metric 0, candidate default path
  Tag 65065, type internal
  Last update from 10.42.240.2 00:06:30 ago
  Routing Descriptor Blocks:
  * 10.42.240.2, from 10.42.240.2, 00:06:30 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65065
      MPLS label: none

 

 

Hello

Can you post the following:

RTR D
sh ip bgp 0.0.0.0

sh run | sec router bgp


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hello

Even you say you've applied the weight metric we don't see them applied to the rib , maybe you do need to soft clear the bgp sessions as it is at present looks like shortest as-path is taking precedence has @Jon Marshall  stated

 

BGP routing table entry for 0.0.0.0/0, version 21617
Paths: (2 available, best #1, table default)
Flag: 0x820
Not advertised to any peer
Refresh Epoch 1
65065, (received & used)
10.42.240.2 (metric 10880) from 10.42.240.2 (10.42.240.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1

65530 65066, (received & used)
10.42.250.2 from 10.42.250.2 (10.42.250.2)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

On D i've now applied a soft reset for both peers. This corrected the routing table. Its now listing routes as per what i would expect

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: