Eigrp Behavior

[Patrick McHenry]

Hi,

Our remote 881s are running ospf with the DMVPN headends. Recently, I've been testing a couple 881s using eigrp. I've configured eigrp on the headends so I can test the 881s using eigrp. They seem to be fairly stable and are getting all the redistributed routes from ospf but, I've noticed when I show the eigrp neighbors the uptime will indicate that it is resetting every so often. Sometimes the routers that are using eigrp have a uptime of 12 hours and some will resett after a couple of hours.  So, I started logging.       

Router#sh ip eigrp neigh

EIGRP-IPv4 Neighbors for AS(99)

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   10.3.68.1               Tu1               12 00:53:46   63   378  0  1975

0   172.20.68.1             Tu0               12 00:53:47   51   306  0  2122

Router#sh log

Sep 20 06:42:14.903 EST-DST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 99: Neighbor 10.3.68.                                  1 (Tunnel1) is down: holding time expired

Sep 20 06:42:16.575 EST-DST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 99: Neighbor 172.20.6                                  8.1 (Tunnel0) is down: holding time expired

Sep 20 06:42:36.475 EST-DST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 99: Neighbor 172.20.6                                  8.1 (Tunnel0) is up: new adjacency

Sep 20 06:42:37.615 EST-DST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 99: Neighbor 10.3.68.1 (Tunnel1) is up: new adjacency

Any reason why I could be losing the adjacency and then getting it back right away?

Thanks, Pat.

[Vivek Ganapathi]

Hello Pat,

I would suggest to run debug eigrp packet & post the output here for further analysis. Also post the EIGRP Configs / Tunnel Configs.

Also, you may try by adjusting the MTU size on the tunnel interface to 1400 bytes in the mean time & advise on the fix.

Thanks

Vivek

[Patrick McHenry]

Vivek,

The tunnels are configured for 1400 MTU. I will log the debug eigrp packets over the weekend and post any results.

Thanks, Pat.

[deshtikypshaq]

Did you try to identify hold time for both neighbors? May be need just increase hold time?

[Patrick McHenry]

Do you think a hello of 5 and hold of 15 is long enough? I know when I do a show ip eigrp neigh the hold time goes to  13 secs under the hold column at times. So. it could be going higher when I am not looking at it. Should I configure this at the headends to be higher as well? Thanks, Pat.

marchess#sh ip eigrp neigh

EIGRP-IPv4 Neighbors for AS(99)

H   Address                 Interface       Hold Uptime   SRTT    RTO  Q   Seq

                                                          (sec)              (ms)       Cnt Num

1   10.3.68.1                   Tu1                12 2d18h      51        306    0   2473

0   172.20.68.1               Tu0                13 2d18h      25        200    0   2677

[dslice]

Do you think a hello of 5 and hold of 15 is long enough? I know when I do a show ip eigrp neigh the hold time goes to 13 secs under the hold column at times. So. it could be going higher when I am not looking at it. Should I configure this at the headends to be higher as well? Thanks, Pat.

###DS### You have it backwards. The holdtime reflects the value received from the peer and then decrements. When it says 13, that means two seconds have elapsed since we've received the hello from that peer.

marchess#sh ip eigrp neigh

EIGRP-IPv4 Neighbors for AS(99)

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

1 10.3.68.1 Tu1 12 2d18h 51 306 0 2473

0 172.20.68.1 Tu0 13 2d18h 25 200 0 2677

Sent from Cisco Technical Support iPad App

[Patrick McHenry]

Thanks, Don. Duh! I forgot it was a countdown but, what about the question? do you think it is a long enough hold time for a DMVPN?

[Reza Sharifi]

Pat,

Read this doc before you change anything.

Also, have you talk to your provides about the link flaps? There may be an issue with the circuit.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094613.shtml#flap

HTH

[dslice]

The reason you would increase the hold time is if the delivery capabilities of the undlying structure can't reliably deliver hellos to the peers sharing the network.  Increasing the hold time is a band-aid to get past another symptom.  If in your case you're having problems getting hellos through, then increasing the hold time can give you a bit more time to keep things up while you try to determine the underlying problem.  It could be on the routers (queue drops, buffer drops, multicast replication issues, etc.) or in the "cloud" your mgre tunnel is running over.

[RUSTOM BILLIMORIA]

Hi Patrick

I know there could be a lot of issues pertaining to this problem. But I once had an issue where the neighborship in EIGRP would flap because the routers interfaces used for peering had inconsistent mask. (i.e. one had a /24 and one had /25). Do check this out and reply.

Rustom Billimoria

[Patrick McHenry]

Thanks Rustom, the Masks are the same.