Why is EIGRP ahead of BGP in my routing table?

[esa_fresa]

You can see the bgp topology table that I have two routes for 10.32.0.0/16. The one for EIGRP is put into the routing table even though BGP has the lower administrative distance. Can someone help me understand why this is the case? And how would I change this behavior for just this specific route?

R2#sh ip bgp top *
For address family: IPv4 Unicast

BGP table version is 13, local router ID is 192.168.2.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
 *   10.32.0.0/16     1.1.1.1              28416             0 65001 ?
 *>                   192.168.2.2          28416         32768 ?
 *>  192.168.1.0      1.1.1.1                  0             0 65001 ?
 *>  192.168.2.0      0.0.0.0                  0         32768 ?
R2#
R2#
R2#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, GigabitEthernet0/0
L        1.1.1.2/32 is directly connected, GigabitEthernet0/0
      10.0.0.0/16 is subnetted, 1 subnets
D        10.32.0.0 [90/28416] via 192.168.2.2, 00:01:54, GigabitEthernet0/1
B     192.168.1.0/24 [20/0] via 1.1.1.1, 00:23:27
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, GigabitEthernet0/1
L        192.168.2.1/32 is directly connected, GigabitEthernet0/1
R2#
R2#

[Jon Marshall · Accepted solution]

Are you redistributing EIGRP into BGP ? 

If so it looks the EIGRP route has been redistributed and is chosen because it has a higher BGP weight.

Jon

[esa_fresa]

We are indeed. I see, so BGP has the higher AD so it will use its topology table to populate the route into the RIB, but BGP is looking at the weight to determine which route is added, not the AD. Right?

Jon, can you point me in the right direction to change the weight for a specific route?

[Jon Marshall · Accepted solution]

If this is EBGP then it has the lower AD.

Normally this would mean the BGP learned route is used but if for some reason you lose that route eg. the link goes down then the EIGRP route is then redistributed into BGP and even when the link comes back up because of the weight it keeps the EIGRP redistributed route. 

If you just want to change for this route only then use a route map to match that route from your BGP neighbor and increase the weight to be > 32768. 

Don’t forget to have a second permit statement in your route map to allow all the other routes from your neighbor. 

Jon

[esa_fresa]

Awesome, thank you Jon. Just to confirm, a configuration to prefer BGP over EIGRP would look something like this?

access-list 99 permit 10.32.0.0 0.0.255.255

route-map Route-Weight-Change permit 10
  match ip address 99
  set weight 50000
route-map Route-Weight-Change permit 20

router bgp 65002
  neighbor 1.1.1.1 route-map Route-Weight-Change in

[Jon Marshall]

I usually use prefix lists but there is no reason why an acl should not work as far as I know. 

The route map configuration is spot on. 

Let me know if you have any problems. 

Jon