RIB-Failure even though AD looks right

[jmcgrady1]

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

[paul driver]

Hello
The rIb failure is basically telling you that although the ebgp routes are valid in the rib but it sees a better alternative to that route (better metric/AD etc..)
Are you performing or do you a (dual) redistribution points, Do you have  have any backdoor routes applied in the bgp process?
Have you tried clearing the bgp sessions?

sh run | sec router

[jmcgrady1]

I have two sites, each with two routers. A and B at site 1 and C and D at site 2. EIGRP redistributes routes within each site.  A connects to C via WAN and eBGP is used between them. B connect to D in the same way.  iBGP is also setup between the two routers within each site.

So A advertises to C via eBGP. C readvertises to D via EIGRP. And D is choosing these EIGRP routes over the ones it is seeing from B.  I dont understand why its doing this as the eBGP routes from B to D are distance 20 whilst those from C to D are 170.

[Sebastian Fernandez]

Hi @jmcgrady1 

This in TAC is known as the race condition. Let me explain, according to your topology explanation D receives an EBGP route from B as well as a redistributed route from C via EIGRP. 

Now because you are redistributing EIGRP to BGP on router D, the route is injected as locally originated route in BGP (after redistribution) and thus BGP sees it with default weight of 32768.  On the other hand, the EBGP route received from B has weigh of 0 so BGP on D chooses best route based on the highest weight (the first parameter of BGP best route calculation).

This is called race condition because the behavior is governed by which side receives the route first. To mitigate this you should consider apply weight higher than 32768 for routes received from EBGP neighbor. 

If you find this post interesting. Please mark it as Helpful to support others to learn from the forum. 

Regards,

Sebastian

[paul driver]

Hello @Sebastian Fernandez 

I guess this may depend on the metrics being used in the redistribution but even if this is a race condition shouldn't we see this event churn between bgp and eigrp?

With the OP topology explanation , my understanding here is that  C -D should receive the same route twice and both via bgp (ebgp and ibgp) unless that is some path manipulation is being applied but unfortunately as no output has been posted from the commands previously suggested I would say its hard to provide a definitive answer to the OP issue.

[Jon Marshall]

Hi Paul 

It's not clear exactly what the IBGP is doing but it is clear from the OP's description that C learns EBGP routes from A redistrinbutes into EIGRP and then advertises to D which presumably is then redistributing back into BGP. 

Not entirely sure what the IBGP is doing here to be honest. 

Jon

[paul driver]

Hello Jon

What i am trying to say is shouldn't we be seeing a recursive change occurring?.
My understanding is that each site has 2 wan rtrs EBGP peered and internally IBGP peered to each other and also these rtrs are EIGRP peered I am assuming for the internal lan.

Now when an ebgp route comes in it will be advertised not only to its ibgp peer but also redistributed into eigrp which will be seen at least twice by either rtr,  Once via redistribution and the other via its eigrp peering.

So at present is the ebgp route will preferred first because it an bgp external route, however the rtr should also see a ibgp entry for this route should it not even with dual redistribution being appended?

Only when there is a lost to bgp (say the rtr ebgp peering)  will the igp eigrp redistributed route be preferred however this should now be recursive with the ibgp route being advertised from the rtrs related ibgp peer - "sebs race condition" However it still doesn't explain the rib failure.

[Jon Marshall]

Hi Paul 

I think we may be talking about different things here but to my mind the IBGP routes don't come into it at all as far as I can see. 

Assuming EIGRP is redistributed into BGP then it is a race condition exactly as Seb has said eg. 

C receives an EBGP route from A and redistributes into EIGRP so D now has the same route from two different sources  - 

EBGP route from B and EIGRP external route from C and it entirely depends on which route D received first ie. if it received the EIGRP route first then it will redistribute into BGP and because of the lower weight will be preferred. 

Also worth noting even if the right route was installed if the BGP peering went down when it came back up it would never fall back to the BGP routes because of the same problem. 

That is the way I am seeing it but could be misunderstanding. 

Jon

[paul driver]

Hello Jon

OP wrote:

 EIGRP redistributes routes within each site.  
A connects to C via WAN and eBGP is used between them. B connect to D in the same way.  iBGP is also setup between the two routers within each site.

Unless i am missing something fundamental here ( which is highly likely) regards mutual redistribution and this topology having no prevention against route leaking I still see any ebgp routes have to be advertised to ibgp peers aswell as via their respective igp links.

[Jon Marshall]

Hi Paul 

I agree about the IBGP routes being exchanged but because EBGP = AD 20, EIGRP EXT = 170 and IBGP = 200 I just don't see how the IBGP routes come into it in terms of route selection. 

I am assuming EIGRP is redistributed into BGP though. 

Jon

[Sebastian Fernandez]

Hello @paul driver 

Irrespective of the metric been used. If EIGRP route is installed in the routing table first before BGP update received it gets redistributed to BGP and thus highest weight get preferred over the eBGP. The best route comparison in BGP takes AD into consideration only when a lot of prior attributes are same or ignored through special configuration. 

Further in some cases, if BGP have selected best path before receiving the route from its eBGP neighbor, then it may as well even announced to the upstream neighbor and if upstream decides to prefer it, then we may not even see an eBGP update. 

This is quiet common and expected behavior with dual eBGP and mutual IGP redistribution scenarios.

Please rate this post as helpful if you find it interesting.

Regards,

Sebastian

[paul driver]

Hello @Sebastian Fernandez

TBH the race condition is something i have not personally experienced and i guess with the correct redistribution policy you shouldn't either, however now its in a discussion I am taking the opportunity to query on it further if you dont mind.

My understanding as I have already stated was that i would have expected some route oscillation occurring with this condition but it doesn't seem the case you mention:

---

@Sebastian Fernandez wrote:

Irrespective of the metric been used. If EIGRP route is installed in the routing table first before BGP update received it gets redistributed to BGP and thus highest weight get preferred over the eBGP.

 This is what i dont understand seb, maybe you could elaborate please i would  have thought this would be the redistributed seed metric?

[Jon Marshall]

Paul 

Just in case Sebastian misses this I will add my bit if it helps. 

The two key things to understanding this are firstly for BGP a route learned via EBGP is given a weight of 0 whereas a route injected into the BGP table via redistribution is given a weight of 32768 and secondly that in this scenario EIGRP is being redistributed into BGP. 

So D will learn two routes for the same destination, one from B via EBGP and one from C via EIGRP. 

The race condition happens because if the EBGP route is learnt first it is installed in the IP routing table and because it has an AD of 20 that means the EIGRP learned route of 170 is not installed into the IP routing table and since only routes in the IP routing table can be redistributed the EIGRP route does not get redistributed into BGP. 

But if the EIGRP route is received first then it is installed in the routing table and therefore it is redistributed into BGP so now D has two routes in it's BGP table and the first attribute used in BGP route selection is weight so the EIGRP redistributed route wins which means the EBGP route learnt from B is not used. 

There is no oscillation, once the route has been chosen it is stable unless the link goes down that the route is using. 

Jon

[Sebastian Fernandez]

Hi @paul driver 

@Jon Marshall posted an impressive summary of what the issue was and as Jon pointed out route oscillations are not expected unless there is an event or a route-flap. Its totally based on which protocol makes it to the RIB first and hence termed as a race condition. This is quiet a commonly observed scenario with dual eBGP setups and to add it further, sometime when the original source of the route is multiple BGP hop away, the redistributed route is announced to eBGP peer and somewhere on the upstream chain of BGP neighbors, they may identify it as the best route (probably due to shorted AS-path) and will stop advertising the valid route.

I am happy I was able to collaborate with others on this issue and contributed to forum. 

-

Sebastian

****** Please rate this post if it was helpful ******

[paul driver]

Hello Jon

---

@Jon Marshall wrote:

BGP a route learned via EBGP is given a weight of 0 whereas a route injected into the BGP table via redistribution is given a weight of 32768 

From CCO
The value of the Weight path attribute of the EIGRP route redistributed into BGP is set to 32768 since it is locally originated in the Router from the BGP's point of view.

This is the key for me to understand -  I didn't take it into consideration  and now sebs comments about setting the default weight on received bgp routes is much clearer.

Very much appreciated to both of you.