How to delay EIGRP adjacency Check

[datamodule]

I am having issue with eigrp neighbor adjacency so i am planning to reconfigure eigrp neighbor adjacency check to every 8 hrs is it possible?

Thanks

[Steve Fuller]

Hi,

An EIGRP neighbour is constantly checked by virtue of the fact it sends a periodic hello packet, and loss of three consecutive hello packets will result in the EIGRP neighbour being reset.

Perhaps I've totally misunderstood your question, but do you mean that you are seeing the EIGRP neighbour relationship being reset, and so you want to change the timers such that it won't reset as much as it is currently?

This is possible by using the command ip hello-interval eigrp <as-number> <seconds> under the interface configuration and setting the hello interval to 9600 seconds. This would mean the EIGRP neighbour would only be reset every 28,800 seconds (8-hours), but I'm not sure this is a good approach to the problem.

You really need to understand why the neighbour is being reset.

Is this across a link with very high packet loss so the hello packets are being lost, or is there something else that's causing the neighbour to reset?

Regards

[datamodule]

Thanks for you reply.We are seeing EIGRP adjacency reset this seems to have cause we are trying to run Eigrp over Cisco Nexus vPC's which is giving real issues.

Before i find some solution i want to make it stable but after entering the following command

ip hello-interval eigrp 100 9600

The EIGRP adjacency started flapping every 15sec

Our design is

DC1--cisco 4948 switch -----Layer2 FW-----Nexus 7K(2 Nexus switches with vPC)----OTV---Cloud---DC2-OTV(ASR1K)----Cisco 6500 (2 cisco 6500 switches no VSS)---Layer2FW---cisco 4948 switch

We are seeing EIGRP adjacency reset on DC1 cisco 4948 switch every 3 to 4 min                    

[datamodule]

I have added the following times to eigrp interface

ip hello-interval eigrp 1 9600
ip hold-time eigrp 1 28800

This seems to be more promising at the moment

[Steve Fuller]

Hi,

Is the EIGRP adjacency between the two Catalyst 4948? If so that's some Layer-2 path you have :-)

Can you post the SYSLOG message? I'm assuming it's some form of %EIGRP-NBRCHANGE_DUAL message, but does it also include "retry limit exceeded" on one of the peers? That would indicate the device that is resetting the neighbour relationship, possibly because it's sent an EIGRP packet that requires an ACK and has not received the required response.

If that's the case then one area I would look into is MTU. Given you have OTV etc., I'm assuming you've changed the MTU in various places to accommodate the OTV encapsulation.

Do you have a consistent MTU end to end between the two EIGRP peers and can you ping between them with the ping packet size set to the maximum and the DF bit set?

The reason I ask is this. When there's a change in the network EIGRP will send an "update" packet which must be acknowledged by the neighbour. If the sending router transmits the packet at its MTU, and let's say you've set the maximum for the Catalyst 4948 of 9198 bytes, then unless that packet can be carried through all the L2 hops in the path at that size, it will be dropped on the path from source to destination. After attempting 16 times the sending device will reset the peer.

If you have an MTU issue / mismatch somewhere in the path, the EIGRP neighbour can come up OK as the hello packets are small. The neighbour can also remain stable for some time as EIGRP only sends updates when there's a change in the network. If that change results in packets that are large, only then do you see the issue.

Regards

[datamodule]

I spoke too soon we are still seeing the issue with eigrp adjacency.

Requested logs

The Eigrp adjacency issue router logs

Jul 30 09:58:18.276: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.12 (Vlan28) is down: holding time expired
Jul 30 09:58:33.492: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.2 (Vlan28) is down: holding time expired
Jul 30 09:59:07.657: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.12 (Vlan28) is up: new adjacency
Jul 30 09:59:07.661: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.2 (Vlan28) is up: new adjacency
Jul 30 10:08:17.634: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.12 (Vlan28) is down: holding time expired
Jul 30 10:08:32.866: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.2 (Vlan28) is down: holding time expired
Jul 30 10:09:06.346: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.12 (Vlan28) is up: new adjacency
Jul 30 10:09:06.354: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.2 (Vlan28) is up: new adjacency

Remote Router logs

Jul 30 01:08:37.003: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is down: Interface PEER-TERMINATION received
Jul 30 01:09:08.880: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is up: new adjacency
Jul 30 01:18:37.259: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is down: Interface PEER-TERMINATION received
Jul 30 01:19:07.052: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is up: new adjacency
Jul 30 01:38:20.487: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is down: Peer Termination received
Jul 30 01:39:05.780: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is up: new adjacency
Jul 30 01:44:37.917: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is down: Interface PEER-TERMINATION received
Jul 30 01:45:06.742: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.30.24.3 (Vlan28) is up: new adjacency

[Steve Fuller]

Hi,

It's not clear which router is part of your DC1 or DC2, but we can see that traffic from the routers with the IP address 172.30.24.2 and 172.30.24.12 towards the router with the IP address 172.30.24.3 is being lost.

This is going to be a case of going through and checking each hop in the path and looking for drops or errors on any of the interfaces that the hello packets towards the 172.30.24.3 router would take.

A couple of questions:

• Does the problem occur throughout the day or is it only seen at certain times?
• If it's seen at certain times, do you know whether there is any large data transfer taking place e.g., backup, that would account for an increase in traffic volumes?

If the problem is due to congestion you may be able to resolve with applying a suitable QoS policy. The EIGRP packets are marked as Class Selector 6 (CS6) and so a policy to prioritise that traffic may be beneficial.

Regards

[datamodule]

DC1 router ip 172.30.24.3

This problem occurs every 10 to 15 min

[Steve Fuller]

And have you been able to find any packet drops or errors on any of the interfaces on the path from DC2 to DC1? Do you have any choke points e.g., where the speed of the incoming link is 10GE and the outgoing link is 1GE?

In terms of the platforms, the Nexus 7000, ASR 1000 and the Catalyst 6500 are typically capable of forwarding at high rates, but what about the L2 firewall you show? What is it and what is it's capacity?

Regards

[paul driver]

Hello

I guess it dosent matter what hello and hold intervals you set - this error indicates the eigrp neigbour hasnt heard any eigrp packets within the hold interval  its receiving.

Possible to to packet loss?

 - Can these peers ping each other via peering address or  M/C 224.0.0.10
 -  look for missing ace entries in acls,  layer 2 issues?
  - debug ip eigrp packet hello

res

paul