iBGP Internal Routes Preferred Over eBGP and EIGRP

[philclemens1835]

Comparable to this thread:

https://community.cisco.com/t5/routing/why-ibgp-route-is-preferred-over-ebgp/m-p/4099742#M335535

Except, I have a generic lab with a triangle of two 9006 PE's and a single 903 CE.  The two PE's are iBGP.  PE1 to CE is EIGRP, and PE2 to CE is eBGP.  Both PE's only learn of the others' routing network to CE through iBGP, even though in both cases the administrative distance would dictate that it learn the route from the CE.

I have found a single short document explaining this, but it's not very detailed:

https://learningnetwork.cisco.com/s/question/0D53i00000Kt0gS/ibgp-vs-ebgp-route-preference

There's not a lot of references I've found on this.  I'm working with a customer with whom we are peering with both BGP and EIGRP in multiple locations, and the routing behavior where iBGP routes on both sides are being preferred over eBGP and EIGRP routes is making things interesting.

Kind of looking for one of those awesome Xander or Aleksandar Support Community documents, or a Cisco Live presentation that digs into this.

Thanks.

[Martin L]

so basically you asking why PE1 is not learning routes via EIGRP from CE, right?

[philclemens1835]

Whether it's EIGRP or eBGP to the CE, I only learn the network from iBGP.

Stepping back and looking at it, this is definitely the desired behavior in most SP worlds.

But, what is that mechanism, and what are the specific factors in determining this?

When/how is iBGP better, even though its AD is greater than everything else?

I'm fine with a reference to a document.  I just haven't found one yet.

[smilstea · Accepted solution]

I had made a lab at one point to train people on this behavior, so it sounds to me like you have the route coming into iBGP from two points, EIGRP and eBGP, on two distinct PEs that then advertise the same route to each other via iBGP. Another way to set this up is both entry points being eBGP, so my topology was like this xrv1 (CE) --- xrv2 (PE) --- xrv3 (PE) --- xrv4 (CE).

So lets turn to BGP route preference.

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

1. weight, locally significant

2. LP, likely not configured and only for iBGP anyways but is one way to prefer iBGP over eBGP

3. Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP, this should apply to you, but in my topology it doesn't apply so lets continue

4. shortest AS path, going to be the same

5. lowest origin type, should be the same

6. lowest MED, should not be configured

7. eBGP preferred over iBGP, so that means something before this check is different and causing iBGP to be preferred.

Here is an example from the lab I wrote:

In this lab CSR4 and XRv8 are both advertising 8.8.8.8/32 to the ISP routers over eBGP. The issue is that xrv11 has a best path from xrv9 (iBGP) instead of the eBGP link!
The reason for this is that local preference is set on xrv9.

You can also use the 'best-path-compare' keyword at the end and it will tell you why the route is preferred from iBGP.

RP/0/0/CPU0:xrv11#show bgp vrf customer_A 8.8.8.8/32
Fri Sep 20 12:21:02.557 UTC
BGP routing table entry for 8.8.8.8/32, Route Distinguisher: 100:100
Versions:
Process bRIB/RIB SendTblVer
Speaker 30 30
Last Modified: Sep 20 12:05:40.926 for 00:15:21
Paths: (2 available, best #2)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
1
8.11.0.2 from 8.11.0.2 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Extended community: RT:200:200
Path #2: Received by speaker 0
Not advertised to any peer
1
9.9.9.9 (metric 3) from 9.9.9.9 (9.9.9.9)
Received Label 24005
Origin IGP, metric 0, localpref 150, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 0, version 30
Extended community: RT:100:100
Source AFI: VPNv4 Unicast, Source VRF: customer_A, Source Route Distinguisher: 100:100
RP/0/0/CPU0:xrv11#show bgp vrf customer_A
Fri Sep 20 12:35:04.770 UTC
BGP VRF customer_A, state: Active
BGP Route Distinguisher: 100:100
VRF ID: 0x60000002
BGP router identifier 11.11.11.11, local AS number 65000
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000011 RD version: 60
BGP main routing table version 60
BGP NSR Initial initsync version 13 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0

Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf customer_A)
*>i4.9.0.0/30 9.9.9.9 0 100 0 ?
*>i4.9.1.1/32 9.9.9.9 0 100 0 ?
*> 4.11.0.0/30 0.0.0.0 0 32768 ?
*> 4.11.1.1/32 0.0.0.0 0 32768 ?
* 8.8.8.8/32 8.11.0.2 0 0 1 i
*>i 9.9.9.9 0 150 0 1 i
*> 8.11.0.0/30 0.0.0.0 0 32768 ?

Processed 6 prefixes, 7 paths
RP/0/0/CPU0:xrv11#

Sam

[philclemens1835]

Thanks Sam.  The redistributed network is the case, and so thanks for that breakdown.  We do use local preference in cases where we have multiple eBGP connections with the same customers.

In this case, it was actually the customer who was learning their redistributed routes across their own iBGP, when they believed they should be picking them up from on eBGP, but the same rules apply.

This is also another reason to continue driving to convert any EIGRP/OSPF customer connections to BGP.