EIGRP behaviour change in IOS 15.1(x)

[Andrew.Gray]

Hi

I have a problem with spurious loss of EIGRP neighbour relationships following the introduction of some IOS 15.1(x) into our network. Here's a rough diagram of the topology in question.

Core sites - summarising out RFC 1918 address space to branch. Core routers are 7206s running 12.4(24)T3

Branch has a fractional Ethernet primary link (4Mbit/s) and 4 private ADSLs using CEF load-balancing (per packet) as a backup link (bandwidth 2Mbit/s to branch, 1Mbit/s to core)  These links are on separate routers connected at 100Mbit/s.

This topology has been in place for some years without issue.

We've recently started putting in 2900 series routers running IOS 15.1(x) instead of 2811s running 12.4(x) in the 2nd buildings - Routers X and W in the diagram.  Following that change we're seeing regular loss of EIGRP neighbours on the ADSL links, errors logged as folllows;

Jan 24 16:30:14.192 UTC: %DUAL-5-NBRCHANGE: EIGRP-IPv4 2: Neighbor 10.121.31.114 (ATM0/0/0.1) is down: retry limit exceeded
Jan 24 16:30:16.852 UTC: %DUAL-5-NBRCHANGE: EIGRP-IPv4 2: Neighbor 10.121.31.114 (ATM0/0/0.1) is up: new adjacency

EIGRP packet debugging indicates that router X is periodically attempting to send an EIGRP update to router B. Router B does not log receipt of this update, consequently does not acknowledge it, router X tries 16 times and tears down the neighbour relationship. It's brought back up a varying but small number of seconds later with the exchange of EIGRP hellos - which seem to be fine throughout.

I've been able to reproduce the problem as described by upgrading a working 2811 running 12.4(13a) to 15.1(3)T with no change in config. Downgrading it back to 12.4 again removes the problem.  In fact, when running 12.4 the normal state is for no EIGRP updates to be generated by router X. I can contrive to force an update by configuring static routes on routers W,Y or Z and the updates are exchanged and acknowledged normally between router X and router B.

If I shut down router X's LAN connections to router W and the adjacent switch, so router X becomes just a spoke on its ADSL links, the problem does not occur.

We only see the problem on ADSL links right now, I'm unable to confirm yet whether we'd see the same if it were another shaped Ethernet link connecting the 2nd building to the core.

The problem is also apparent when running IOS 15.0(1)M3 on router X.

I've gone through the Bug Report list on CCO and not found anything similar to this. The only documented significant difference in EIGRP defaults I can find between IOS 12.4 and 15.x is that no auto-summary is now default.That's not relevant here though because we explicitly turn it off in IOS 12.4.

So, I'm wondering if anyone here has seen anything like this, or has any thoughts about other, more subtle, config tweaks I could try to make EIGRP operate seamlessly with older IOSs on 15.x.

Thanks for reading, if you've got this far

Andy Gray

[hbruyere · Accepted solution]

Hello,

Personnally I am not aware of outstanding eigrp issues int 15.1, but if the 7200 peer does not see anything from the 2900 (for example not complaining about 'bad TLV' from the 2900 in 'debug eigrp packet terse'), then maybe we can suspect unforeseen changes in mtu settings on atm...

If not already done, you could manually configure the same ip mtu on both sides and see if the update is reaching the 7200.

If it does not help, further troubleshooting will be needed. So you may want to open a TAC case.

Thanks,

Herve

[Andrew.Gray]

Herve

Thanks very much for the reply. Fixing the IP MTU size at the 1500 bytes the core end PA-A3-OC3SMI on 12.4 supports fixes the problem.

Querying MTU sizes on the physical interfaces there's no obvious difference between IOS 12.x and 15.x, 4470 bytes in both cases, so there must be something slightly different about the way EIGRP is handling updates over ATM in IOS 15.x

It's a simple enough fix for us to administer though, which is nice.

Thanks again.

Andy Gray