High RTO with low SSRT values on EIGRP

[spfister336]

We are running several remote sites connecting back to a central site using EIGRP as the routing protocol over AT&T's ASE on demand switched ethernet service. It's been mostly fine, but occasionally for 25 or 30 minutes we get a lot of flapping that seems to go away on its own. During this time, 'show ip eigrp neigh' shows lines like:

31 10.210.77.2 Vl277 13 00:00:40 1 5000 1 806
26 10.210.43.2 Vl243 13 00:00:40 1 100 0 124
20 10.210.15.2 Vl215 11 00:00:40 1 100 0 413
9 10.210.81.2 Vl281 13 00:00:40 2 1702 0 100
4 10.210.17.2 Vl217 14 00:00:40 1 5000 1 1072
29 10.210.66.2 Vl266 13 00:00:46 1 5000 1 462
25 10.210.71.2 Vl271 13 00:00:46 1 5000 1 2129
24 10.210.22.2 Vl322 14 00:00:46 17 771 1 1493

The SRTT values seem relatively OK, but the RTOs go into the thousands. Is it possible that this is packet loss, or multicast rate limiting on AT&T's part?

[MHM Cisco World]

You correct' some issue make eigrp hello message and or update message drop.

Is eigrp run on tunnel?

[spfister336]

No, it's not

[MHM Cisco World]

which case you see both or one side flapping ?

• Adjacency comes up on both routers and keeps flapping (unicast issues)
• Adjacency comes up on one router and keeps flapping (multicast issues)

[spfister336]

On the central site:

Apr 11 19:33:52.819: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.210.66.2 (Vlan266) is down: Interface PEER-TERMINATION received
Apr 11 19:33:56.044: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.210.66.2 (Vlan266) is up: new adjacency

on remote side:

Apr 11 19:36:17.502: %PIM-5-NBRCHG: neighbor 10.210.66.1 DOWN on interface Vlan266 non DR
Apr 11 19:36:30.967: %PIM-5-NBRCHG: neighbor 10.210.66.1 UP on interface Vlan266

[MHM Cisco World]

Solved: Error log %PIM-5-NBRCHG: neighbor 0.0.0.0 - Cisco Community

the issue I think that the HSRP with multicast and that make neighbour UP/DOWM

[spfister336]

We aren't really using HSRP anywhere. I was thinking about using static eigrp neighbor statements. We seem to have frequent problems with multicast over ATT

[spfister336]

All remote sites just need access to the central site. Traffic between remote sites directly to each other isn't really needed or wanted.

[MHM Cisco World]

ping 224.0.0.10 check the reply 
if you lost some ping then sure the multicast is issue here, 
the neighbour command can solve you issue the hello/update not use any multicast it will use unicast only with this command 

[spfister336]

ping 224.0.0.10 gives:

ping 244.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 244.0.0.10, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

[MHM Cisco World]

check again please I need 224.0.0.10 not 244.0.0.10

use ping with repeat 100 not 5. I need to see the 100% drop 

[David Ruess]

Looks like you pinged 244.0.0.10 and not 224.0.0.10.

The multicast EIGRP address as @MHM Cisco Worldsaid is 224.0.0.10. What does that ping return?

-David

[spfister336]

Sorry about that... I knew EIGRP was 224.0.0.10, but yesterday was kind of stressful. Pinging the correct address gives a reply from each of the neighbors. The issue isn't occurring now (sometimes takes 5 or 6 weeks before recurrence).

Each of the remote sites was recently placed on a separate VLAN with just it and the central site in it. In a case like this, wouldn't static neighbor statements make sense? Our service provider has a rate limit on BUM traffic. The default limit is 2Mbps, but they have a feature to raise that slightly (30Mbps I think?). I would like to not have to worry about the limit if I could.

[MHM Cisco World]

ip bandwidth-percent eigrp — interface, EIGRP <<- this command will make EIGRP have specific BW even if the interface it utilize this prevent the EIGRP flapping if as you mention the ping is OK. 
thanks 
MHM

[spfister336]

None of our switches seem to have this command. Our central site runs on a pair of 9500s. Remote sites are using either a 4500X pair, a 9300, or 3850.