EIGRP has never been my favorite routing protocol, which means my knowledge of it is “enough to be dangerous” on purpose. Currently being in an environment that ran on EIGRP I am forced to learn this routing protocol and while playing with a lab in UNL and troubleshooting real production issues, I have learned things I like and dislike about this protocol. The real focus of this write is the issue I was struggling with for a few days where I had to walk away a few times just to recompose. The issue resolved around two ASR1000x’s connected to a core 6500 in VSS mode and the fact that they would not peer iBGP to each other. The eBGP relationship to the PE was working as expected but not iBGP. The lay of the ground is that EIGRP runs between the core 6500’s and the ASR1000x’s. For example purposes we will call each ASR WAN1 and WAN2 respectively. The 6500 VSS will be called Core01.
WAN1:
interface Loopback0
ip address 10.3.0.1 255.255.255.255
!
interface Loopback10
ip address 10.10.10.10 255.255.255.255
!
interface GigabitEthernet1
ip address 10.0.111.2 255.255.255.252
negotiation auto
!
!
router eigrp 11
default-metric 10000 100 255 1 1500
network 10.0.111.2 0.0.0.0
network 10.3.0.1 0.0.0.0
redistribute bgp 5799 metric 100000 100 255 1 1500 route-map BGP_INTO_EIGRP
passive-interface default
no passive-interface GigabitEthernet1
nsf
!
router bgp 5799
bgp router-id 10.3.0.1
bgp log-neighbor-changes
network 0.0.0.0 route-map PREPEND-OUT
aggregate-address 10.0.0.0 255.255.0.0 summary-only
neighbor 10.3.0.3 remote-as 5799
neighbor 10.3.0.3 update-source Loopback0
neighbor 10.3.0.3 next-hop-self
default-information originate
WAN2:
interface Loopback0
ip address 10.3.0.3 255.255.255.255
!
interface Loopback10
ip address 10.10.10.10 255.255.255.255
!
interface GigabitEthernet1
ip address 10.0.113.2 255.255.255.252
negotiation auto
!
!
router eigrp 11
default-metric 10000 100 255 1 1500
network 10.0.113.2 0.0.0.0
network 10.3.0.3 0.0.0.0
redistribute bgp 5799 metric 100000 100 255 1 1500 route-map BGP_INTO_EIGRP
passive-interface default
no passive-interface GigabitEthernet1
nsf
!
router bgp 5799
bgp router-id 10.3.0.3
bgp log-neighbor-changes
network 0.0.0.0 route-map PREPEND-OUT
aggregate-address 10.0.0.0 255.255.0.0 summary-only
neighbor 10.3.0.1 remote-as 5799
neighbor 10.3.0.1 update-source Loopback0
neighbor 10.3.0.1 next-hop-self
default-information originate
Now these devices were configured previously and certain configurations were done for certain reasons one can assume. So first things first, lets check Core01 to see what it knows via EIGRP since its not participating in BGP.
SW01#show ip route eigrp
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 overrideGateway of last resort is not set
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D 10.3.0.1/32 [90/409600] via 10.0.111.2, 00:46:42, Ethernet0/1
D 10.3.0.3/32 [90/409600] via 10.0.113.2, 00:47:31, Ethernet0/0
SW01#
Well it seems that Core01 knows about both loopbacks on each WAN router that will be used for iBGP peering. Ok on to WAN1 to see what it knows.
CSR01#show ip route eigrp
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 PfRGateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.0.100.1/32 [90/130816] via 10.0.111.1, 00:50:11, GigabitEthernet1
D 10.0.113.0/30 [90/281856] via 10.0.111.1, 00:50:11, GigabitEthernet1
CSR01#
WAN1 does not know about WAN2’s loopback address, even though it is advertised in WAN1’s EIGRP process. Does WAN2 know about WAN1’s loopback?
CSR03#show ip route eigrp
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 PfRGateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.0.100.1/32 [90/130816] via 10.0.113.1, 00:52:40, GigabitEthernet1
D 10.0.111.0/30 [90/281856] via 10.0.113.1, 00:52:40, GigabitEthernet1
CSR03#
And that would be a negative….Ok so obviously before we troubleshoot anything BGP related, I needed to figure out why the loopbacks were not getting re-advertised to both WAN1 and WAN2 from Core01. So after some not very helpful debugs, I started to look at ACLs and route-maps to make sure nothing was being filtered inbound or outbound. That turned out to be a non issue. Well some of you may have already figured out the issue with the configuration outputs I have already shared, but after reading article after article and forcing myself to learn about this routing protocol I stumbled upon “EIGRP router-id’s”. So what are the facts of router-id’s with EIGRP?
EIGRP automatically selects an IP address to use as the router ID when an EIGRP process is started. The highest local IP address is selected and loopback interfaces are preferred. The router ID is not changed unless the EIGRP process is removed with the no router eigrp command or if the router ID is manually configured with the eigrp router-id command.
Router ID is used to identify the originating router for external routes. If an external route is received with the local router ID, the route is discarded. The router ID can be configured with any IP address with two exceptions; 0.0.0.0 and 255.255.255.255 are not legal values and cannot be entered. A unique value should be configured for each router.
Well there it is, it will choose the highest IP address is selected and LOOPBACK interfaces are preferred, which means the loopback with the highest IP address wins. So looking closely at the configurations of WAN1 and WAN2, each have a loopback 10 with the same IP address. Now I can’t even figure out the purpose of these loopbacks but they are there and caused me this headache. My assumption was that one router was configured and the other was configured at a later date using the same template as the original. Regardless, the loopbacks are there on each and they are configured the same.
Well we found the issue! Great! Lets change the IP address on WAN2 Lo10 to 10.10.10.11 and we are good to go! Nope. Why would it be that easy? Further reading tells me that for the EIGRP process to pick a new router-id the process needs to be REMOVED, not cleared, but REMOVED! Well that causes an issue in production! Solution: Just hard code the router-id to 10.10.10.11 and the routes start working and so does the iBGP peering between the two WAN routers.
CSR03(config-if)#ip address 10.10.10.11 255.255.255.255
CSR03(config-if)#shut
CSR03(config-if)#no shut
!
CSR03#show eigrp protocols
EIGRP-IPv4 Protocol for AS(11)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
Soft SIA disabled
NSF-aware route hold timer is 240
EIGRP NSF enabled
NSF signal timer is 20s
NSF converge timer is 120s
Router-ID: 10.10.10.10
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Default redistribution metric is 10000 100 255 1 1500CSR03#
As you can see the router-id sticks even after re-configuring the Loopback 10 interface and shutting it down and bringing it up again. Setting the router-id manually fixes the issue and gets iBGP back up and running again.
CSR03(config)#router eigrp 11
CSR03(config-router)#eigrp router-id ?
A.B.C.D EIGRP Router-ID in IP address formatCSR03(config-router)#eigrp router-id 10.10.10.11
CSR03(config-router)#exit
CSR03(config)#exit
CSR03#show i
*Jun 7 22:52:30.768: %SYS-5-CONFIG_I: Configured from console by consoleigrp pro
CSR03#show eigrp protocols
EIGRP-IPv4 Protocol for AS(11)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
Soft SIA disabled
NSF-aware route hold timer is 240
EIGRP NSF enabled
NSF signal timer is 20s
NSF converge timer is 120s
Router-ID: 10.10.10.11
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Default redistribution metric is 10000 100 255 1 1500CSR03#
*Jun 7 22:52:38.261: %DUAL-5-NBRCHANGE: EIGRP-IPv4 11: Neighbor 10.0.113.1 (GigabitEthernet1) is down: route configuration changed
*Jun 7 22:52:40.637: %DUAL-5-NBRCHANGE: EIGRP-IPv4 11: Neighbor 10.0.113.1 (GigabitEthernet1) is up: new adjacency
*Jun 7 22:52:41.137: %BGP-5-ADJCHANGE: neighbor 10.3.0.1 Up
CSR03#show ip route eigrp
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 PfRGateway of last resort is not set
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D 10.0.100.1/32 [90/130816] via 10.0.113.1, 00:00:22, GigabitEthernet1
D 10.0.111.0/30 [90/281856] via 10.0.113.1, 00:00:22, GigabitEthernet1
D 10.3.0.1/32 [90/409856] via 10.0.113.1, 00:00:22, GigabitEthernet1
CSR03#show ip bgp sum
BGP router identifier 10.3.0.3, local AS number 5799
BGP table version is 58, main routing table version 58Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.3.0.1 4 5799 4 4 58 0 0 00:00:28 0
152.183.164.221 4 65000 0 0 1 0 0 never Idle
CSR03#
While this may have been a simple thing out of the gate, it could be very frustrating when you let things like routing protocols automatically do things, like use its default behavior to pick a router-id. I have decided that from this moment on I will manually define the router-id for EIGRP just like I do for BGP.
