cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
982
Views
0
Helpful
3
Replies

SXH vs SXI EIGRP router id selection and originating router?

Hey all,

We stumbled upon two EIGRP problems today after updating our core 6500s from SXH to SXI:

1- It seems the EIGRP router id auto selection logic has changed: we have a couple of loopback interfaces configured on our cores, lo0 being our main one (10.0.0.1 on primary core, 10.0.0.2 on secondary core), and lo1 having the highest IP of all loopbacks at 10.0.0.254. On SXH, EIGRP used to select lo0's IP for router-id.  Now on SXI, it selects 10.0.0.254.  Reading back the docs, I do see that it says it selects the highest IP of loopback interfaces, but why the behavior change? Anyone else noticed that?

2- EIGRP in SXI now seems to add an originating router field to internal route updates (instead of only external routes).

Under SXI:

CORE1#show ip eigrp topo 10.0.0.2/32

EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.0.254) for 10.0.0.2/32

  State is Passive, Query origin flag is 1, 3 Successor(s), FD is 130816

  Descriptor Blocks:

x.x.x.x (Vlanx), from x.x.x.x, Send flag is 0x0

      Composite metric is (130816/128256), route is Internal

      Vector metric:

        Minimum bandwidth is 1000000 Kbit

        Total delay is 5010 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1

        Originating router is 10.0.0.2

Under SXH:

OTHERSITECORE1#show ip eigrp topo 10.0.1.2/32

IP-EIGRP (AS 1): Topology entry for 10.0.1.2/32

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 130816

  Routing Descriptor Blocks:

  x.x.x.x (Vlanx), from x.x.x.x, Send flag is 0x0

      Composite metric is (130816/128256), Route is Internal

      Vector metric:

        Minimum bandwidth is 1000000 Kbit

        Total delay is 5010 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1

Also, recent doc seems to refer to modifications to EIGRP in recent IOS with that respect:

The 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.

In EIGRP named IPv4, named IPv6, and Cisco Service Advertisement Framework (SAF) configurations, the router-id is also included for identifying internal routes and loop detection

And indeed, SXI now supports named EIGRP instances:

core1(config)#router eigrp ?

  <1-65535>  Autonomous System

  WORD       EIGRP Virtual-Instance Name

whereas SXH didn't:

1(config)#router eigrp ?

  <1-65535>  Autonomous system number

The combination of those two changes bit us today as it lead to the two cores selecting the same router id, sending them in local advertisements and dropping eigrp updates as they now saw internal route updates with originating router id's coming from themselves...

Anyone else notice these? We've looked at the release notes but didn't find anything related to those...

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Hello Jean,

1) I am not aware of a behavior change in EIGRP Router ID selection. Perhaps what you are seeing is simply a result of adding the loopback with the higher IP address after the EIGRP has been started.

2) Yes, I can confirm that newer IOSes add the originator EIGRP RID also to internal routes, not just to external as before. Donald Slice has confirmed this recently in another thread:

https://supportforums.cisco.com/message/3445313#3445313

Best regards,

Peter

Yeah, looking further, it seems that it probably was that we added the other loopback afterwards (although years ago). We have rebooted those cores a few times since, which means that we would have had router-id collisions for a while, however we wouldn't have noticed until now because the originating router behavior hadn't changed until we upgraded to SXI.

Hi Jean,

Yes, that is a perfectly valid explanation. I can confirm myself being quite taken aback at the lab when deliberately creating EIGRP RID conflicts and observing that internal routes that once were accepted smoothly suddenly become rejected. Only later I've discovered that the EIGRP RID is added to internal routes as well. Originally, the EIGRP RID was attached only to external (i.e. redistributed) networks as a means to prevent routing loops with redistributed networks.

Best regards,

Peter

Review Cisco Networking products for a $25 gift card