Eigrp neighborship flapping issue

[Raja_D]

Hi, 

Does a high utilization on a point to point link with eigrp routing protocol configured on both ends lead to eigrp neighborship flapping issue frequently ?

If high utilization leads to frequent eigrp neighborship flapping between both end router's, is there any way to overcome this flapping issue although if there is high link congestion ?

please suggest...

Example:

20mb is the bandwidth over a p2p link and almost 20mb of utilization is noticed on both the interfaces on which the eigrp is enabled. Will this lead to frequent eigrp neighborship flapping ?

Regards, 

James. 

[azibnaseem]

Hi rajadanduluri  '

From my real time experience, high utilization isn't an issue because as I am internet service provider & I have two links connected to different ISP's using BGP & my one link is almost remain chocked but I didn't faced any neighbor-ship flapping. My BGP neighbor-ship to my UP-LINK provider remain intact.

Moreover, for the sake of troubleshooting, please ask your provider to temporarily increased the bandwidth or decrease some load to resolve the issue.

Kind Regards'

[Raja_D]

Hi Azib,

well, so based on your explanation so even when there is high congestion on the link the hello packets should not get dropped and the eigrp neighborship should remain up/stable . right ?

i have noticed that the peer termination with hold timer expired logs noticed on the router much frequently where the hello/hold timers for the eigrp configured on both ends remained same and also the other parameters for proper neighborship are identical on both sides. 

Its a dedicated link which is mainly used for the replication sort of traffic exchanged between the source and destination server's. so utilization will be pretty high always but noticed frequent flapping so need clarification if its common with high utilization on p2p link or not.

As said that its a dedicated point to point link i am not sure if the provider can increase the bandwidth temporarily but will try to check. Infact i have made passive on one end to break up the eigrp  neighborship and to ignore the eigrp hello packets from being forwarded by which I tried to ping end to end to confirm if there is any issue in the link but with it i did not notice any packet drops at all.

Any other suggestion please let me know.  

[azibnaseem]

Hi rajadanduluri  '

Congested Links can causes many issues like packet drops etc. There are number of factors of neghborship flapping. You can read through from given link.

http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/21324-trouble-eigrp.html

Kind Regards'

[willwetherman]

Hi

I experienced a similar issue with routers that had an EIGRP adjacency over a VPLS network. The issue was caused by congestion which resulted in missed hellos and the EIGRP adjacencies to be torn down. The circuits were subrate 30/100Mbps with policing configured on the providers side to enforce the bandwidth.

To fix this issue I configured traffic shaping with a nested CBWFQ policy on each of the routers WAN interface. This shaped egress traffic to the link bandwidth and prioritised EIGRP within the shaper queue. Example config

class-map match-any network-critical

 match dscp cs6

!

policy-map child

 class network-critical

  bandwidth percent 5

!

policy-map parent

 class class-default

  shape average 27000000

  service-policy child

!

interface GigabitEthernet0/0

 bandwidth 30000

 service-policy output parent

You will note that the shape rate is less than the contracted bandwidth. I’ve had advice from others on this forum that shapers don't always account for L2 overhead so I typically reduce the rate by 10% which seems to work quite well.

Hope this helps

Edit: I forgot to mention that I dont think that the Cisco routers were dropping the EIGRP hellos during congestion, it was more the result of traffic exceeding the providers ingress policer. By configuring the above we made sure that our egress traffic stayed within the providers rate and prevented dropped packets.

[Raja_D]

Hi Will,

So this CBWFQ policy need to be configured on both the end routers which are connected over p2p ? 

Mine is of 40 mb p2p link so with 10% reduction i will get an shape average to 36000000

Can you explain me what does the command "bandwidth percent 5" under policy child will have an action actually? 

So as per my understanding with the configuration that you have done on an p2p link of 30 mbps the eigrp flapping is avoided although there is high utilization . is tht correct? 

Kindly clarify

Sos

[willwetherman]

Hi,

Yes this solved the issue for this particular network but please note that there a number of reasons for adjacencies to flap so this may not fix your particular issue.

bandwidth percent 5 enables CBWFQ under the class and provides a minimum bandwidth guarantee of 5% of the shapers bandwidth. Note that this isn’t always required as some devices uses the PAK_Priority mechanism to priorities IGP control traffic, see below.

The important part is the shaping which prevents egress traffic from exceeding the providers ingress policers.

This is from Cisco's Enterprise QoS Solution Reference Network Design Guide

 By default, Cisco IOS software (in accordance with RFC 791 and RFC 2474) marks Interior  Gateway Protocol (IGP) traffic such as Routing Information Protocol  (RIP/RIPv2), Open Shortest Path First (OSPF), and Enhanced Interior  Gateway Routing Protocol (EIGRP) to DSCP CS6. However, Cisco IOS  software also has an internal mechanism for granting internal priority  to important control datagrams as they are processed within the router.  This mechanism is called PAK_PRIORITY.

As datagrams are processed though the router and down to the interfaces,  they are internally encapsulated with a small packet header, referred  to as the PAKTYPE structure. Within the fields of this internal header  there is a PAK_PRIORITY flag that indicates the relative importance of  control packets to the internal processing systems of the router.  PAK_PRIORITY designation is a critical internal Cisco IOS software  operation and, as such, is not administratively configurable in any way.

Note that Exterior  Gateway Protocol (EGP) traffic such as Border Gateway Protocol (BGP)  traffic is marked by default to DSCP CS6 but does not receive such  PAK_PRIORITY preferential treatment and may need to be explicitly  protected in order to maintain peering sessions.

When addressing the QoS needs of IP Routing traffic, Cisco recommends the following guidelines:

•IP Routing traffic should be marked to DSCP CS6; this is default behavior on Cisco IOS platforms.

•IGPs  are usually adequately protected with the Cisco IOS internal  PAK_Priority mechanism; Cisco recommends that EGPs such as BGP have an explicit class for IP routing with a minimal bandwidth guarantee.

•Cisco IOS automatically marks IP Routing traffic to DSCP CS6.

[Georg Pauwen]

Hello,

in addition to the other posts, EIGRP by default can reserve up to 50% of bandwidth for control traffic. So it is almost impossible for congestion to cause dropped hello packets.

That said, you might want to enable debugging for EIGRP:

debug eigrp neighbor

debug eigrp packet

debug eigrp transmit