BGP Routing When EIGRP Paths are Available

[MattMH]

Hello,

I have a question about BGP routing as we begin to introduce BGP in prep for Meraki SDWAN. Currently, all routing is using EIGRP right now. Everything I am trying to test is in a lab and I can't get it to work how I would like it to.

I have 2 data centers. Between the data centers is a direct link running BGP between 2 core switches. The switches are peered using BGP AS 65501.

The primary data center, call it CORP, has a BGP peer with a distribution switch using BGP AS 65502 (I have tried eBGP as well, no luck). The distribution switch has multiple WAN links and there are various paths to the secondary data center. The distribution switch is also peered with a router using EIGRP over a WAN link. The distribution switch is also connected to access switches.

The secondary data center is also peered with another EIGRP router over a WAN link as well. So I have multiple paths to either data center, including the direct link between the core switches.

Everything works generally well as I am redist EIGRP into BGP and BGP into EIGRP.

Here is where I have troubles. When the link between the distribution switch and corp core switch is up, things are good. The user subnets off of the dist switch route over the BGP peer to the core switch. I see this in the routing table.
*> 10.126.95.0/24 192.168.204.1 0 0 65501 i

If I shutdown that link between CORP and DIST, again as expected the routing takes place over the WAN via secondary data center back to the CORP switch and this shows up in my bgp route table

*> 10.126.95.0/24 192.168.203.2 25626368 32768 ?

However, if I bring the link back up between the CORP and DIST switch, it never fails back to BGP. It will forever prefer EIGRP until EIGRP does down and I see the 2 routes.
* 10.126.95.0/24 192.168.204.1 0 0 65501 i
*> 192.168.203.2 25626368 32768 ?

I have tried setting various metrics and weights, but nothing ever fails back to BGP in this scenario. Anything I can do to dynamically fail back to iBGP (or BGP in general) vs EIGRP?

[paul driver · Accepted solution]

Hello

---

@MattMH wrote:

however, if I bring the link back up between the CORP and DIST switch, it never fails back to BGP. It will forever prefer EIGRP until EIGRP does down and I see the 2 routes

---

Sounds like a possible race condition is occurring between bgp/eigrp.

As when the bgp session is torn down the eigrp path is preferred however when the bgp session reestablishes the redistributed eigrp routes in bgp  will have a default weight of 32768 assigned to them, but the external bgp route for the same prefix has no weight value as such the bgp best path section process will choose the redistributed prefix with the weight over an external admin bgp router with a cost of 20.

Possible solution.
Router bgp x
neighbour <ebgp peer> weight 40000

[MHM Cisco World · Accepted solution]

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213285-understand-the-importance-of-bgp-weight.html

check this link it explain your issue with solution 

MHM

[MattMH]

@MHM Cisco World  @paul driver  ... read through the docs and this is exactly what I am dealing with. Question, the doc refers to eBGP and my current lab setup is EBGP between CORE and DIST. Should I keep that setup EBGP or is there any reason I should switch that back to IBGP between the 2?

[MHM Cisco World]

keep eBGP

MHM

[MattMH]

This document is what I needed. The only thing that was different for my scenario was that my WAN was EIGRP and my LAN was BGP, so I flipped how/where the weight is applied and works as I had hoped. Thanks!

[paul driver]

Hello

---

@MattMH wrote:

@MHM Cisco World  @paul driver  ... read through the docs and this is exactly what I am dealing with. Question, the doc refers to eBGP and my current lab setup is EBGP between CORE and DIST. Should I keep that setup EBGP or is there any reason I should switch that back to IBGP between the 2?

---

TBH, the redistribution point between bgp/eigrp will still install the igp route into bgp with the weight appended even if two bgp rtrs were ibgp peers, however the internal bgp rtr that weight will be lost.