EIGRP continually flapping

[pugs17211721]

This is the message that I am getting from my 1941w router. I have a isakmp tunnel built with a GRE tunnel going through it. I keep getting the following message, continously.

Nov 16 08:58:09.352 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

Nov 16 08:59:47.361 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is down: Interface PEER-TERMINATION received

Nov 16 08:59:51.217 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

Nov 16 09:01:27.230 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is down: Interface PEER-TERMINATION received

Nov 16 09:01:27.782 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

Nov 16 09:03:03.792 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is down: Interface PEER-TERMINATION received

Nov 16 09:03:04.372 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

Nov 16 09:04:40.381 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is down: Interface PEER-TERMINATION received

Nov 16 09:04:40.909 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

Nov 16 09:06:13.774 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is down: Interface PEER-TERMINATION received

Nov 16 09:06:18.282 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

Nov 16 09:07:54.296 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is down: Interface PEER-TERMINATION received

Nov 16 09:07:58.436 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

Nov 16 09:09:29.521 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is down: Interface PEER-TERMINATION received

Nov 16 09:09:30.233 EST: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.20.255.97 (Tunnel31) is up: new adjacency

The other end of the device is a 2801 router and it doesnt show anything in the logs. Anyone have any ideas? Thanks.

[cadet alain]

Hi,

can you post output of following command:

debug eigrp packet

Regards.

Alain

[pugs17211721]

Here is the result.

[Richard Burts]

What can you tell us about the router on the other end of the tunnel?

It looks to me like the problem is not on your router but is on the router at the other end of the tunnel.

To me the most significant part of the output that you posted is this

(Tunnel31) is down: Interface PEER-TERMINATION received

What I think is happening is this:

- your router sends a hello over the tunnel.

- your router receives a hello over the tunnel from the other router.

- your router adds the new neighbor.

- your router receives a PEER-TERMINATION from the other router and tears down the neighbor relationship.

So why is the other router sending the PEER-TERMINATION? When we find the answer to that we will know what the problem is.

HTH

Rick

[pugs17211721]

It is a 2801 running 12.4(5a).

It currently has 10 other vpn tunnels connected to it, and they are not having the same problem.

Here is what I think is the relative config.

FLOH-2801-001#show run | section eigrp

router eigrp 1

network 172.20.0.0

network 172.21.0.0

maximum-paths 1

default-metric 128 344 200 200 200

no auto-summary

no eigrp log-neighbor-changes

neighbor 172.20.255.98 Tunnel21018

snmp-server enable traps eigrp

FLOH-2801-001#show run int tunnel 21018

Building configuration...

Current configuration : 214 bytes

!

interface Tunnel21018

description T-SATX-108

ip address 172.20.255.97 255.255.255.252

ip mtu 1500

ip route-cache flow

keepalive 10 3

tunnel source 172.20.240.31

tunnel destination 172.21.100.18

end

[Kristian Alexander Brown]

Hi,

I would probably have started with some eigrp debugging on your 2801 router to see whats actually happening.

Sent from Cisco Technical Support iPad App

[joshua izzi]

Hello,

My issue was due to MTU sizing not matching. EIGRP will try to use the highest MTU size supported on the link for sending it's routing table when neighbor adjacency is first brought up. If the MTU size is too large for the ANY link in between the two peers, the packet/frame will be dropped causing the peer to not receive any routes...this causes a peer-termination since it isn't getting an acknowledgement of the routing updates it sent...hope this helps.

I would also check to make sure your tcp segment sizing is correct - ip tcp adjust-mss xx (usually you want to set it to the same size as your MTU or a little smaller if I'm not mistaken but I would recommend researching this and seeing what your tunnel needs/is using from MTU and MSS since GRE/IPsec all have their own overheads and increase size since they're encapsulating.

[deepak george]

Dear Joshua,

Thanks for getting back with your views. In our case the tunnel has got an MTU size of 17984, so do we reduce this same as to the physical interface level,or do we reduce it to a value around 14k.

Thanks in advance

[joshua izzi · Accepted solution]

Sorry - I was referring to the tunnel transport MTU. Are all your physical links in between the two tunnels based on 1500MTU? If so....

You can first try using this on both sides under your tunnel interfaces (make sure that your physical interface is 1500, if it's Ethernet, the default should be 1500 unless it was globally changed).

Under tunnel interfaces:

 ip tcp adjust-mss 1376
 tunnel path-mtu-discovery

ip mtu 1400

You only need 1 of the last 2 commands but Cisco recommends putting them both...

Here's a good document although it's a bit 'lengthy' : http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

[Chennai NOC]

Hi ALL 

I found the Correct  solution 

The Solution  is  remove ip nhrp map multicast dynamic and add static multicast mapping to the real interface IP not the tunnel IP . IT worked Bingo 

[Richard Burts]

Thanks for the additional information. I find it interesting that it looks like the remote router has specified an EIGRP neighbor for this router. Would I be correct in assuming that this is the only neighbor for which it has done this?

If so then I believe that we shoud investigate why the remote neighbor did this for one neighbor and not for others.

I would also be interesting to know what would be the result if you configured your router with an EIGRP neighbor statement for this remote neighbor.

HTH

Rick

[Bekzod Fakhriddinov]

I have the similar problem , changed mtu to 1400 , increased EIGRP hello and hold timers still flapping. Question is : are these mtu and EIGRP hello/hold parameters must be changed on both sides hub-and-spoke  ? must they be equal on both sides ?

[Richard Burts]

While I believe that it would be advisable to have the hold time and hello time parameters match at both ends it is not required. EIGRP should run just fine with different settings for the hold time and hello time.

It would be more important that the MTU setting match at both ends.

HTH

Rick

[NeilGouws]

Doesn't have to be the same on both sides

On your HUB change MTU to 1300, adjust-mss to 1260 on the tunnel interface, not the physical interface

EIGRP is pushing lots of route updates

give it 15 minutes and then up the MTU and adjust mss again

I prefer to leave it at :

ip mtu 1390

ip tcp adjust-mss 1350

Had a case where the EIGRP neighbor relationship was unstable between 2 Spokes and a Hub (Point-2-Point IPSEC over GRE with EIGRP)

set mtu to 1300

adjust-mss to 1260

problem went away immediately

changed it back to preferred after a few minutes and it was still stable

[Kishore Chennupati]

Hi,

My thoughts here. You are using GRE tunnels and by default GRE allocates 9kbps BW for the routing protocol traffic and EIGRP uses 50% of that to send its hellos,updates etc. I believe in this case the BW is not enough on the tunnel for this traffic and hence you are seeing the flapping. Please use the physical interface bandwidth using the "bandwidth < bandwidth> on the tunnel interface and see if helps.

for example if you are using gigethernet then just put the command bandwidth 1000000 on the tunnel interface at both ends and see if that helps.

you can also see the load on the tunnel interfaces as well. do a sh int tunnel 21018 and you should be able to see the load on the interface. it should look something like X/255  where X is the load.

Also you might want to change the ip mtu to 1476 so that the packets dont get fragmented.

Regards,

Kishore