EIGRP neighbor adjacency resets when update distribute list

[Jignesh Desai]

When I update the distribute list under eigrp process, all eigrp neighbors reset.  Is this normal?  Here is the config and log messages:

router eigrp 1

distribute-list prefix Redistribute out TenGigabitEthernet1/1

distribute-list prefix Redistribute out TenGigabitEthernet1/2

distribute-list prefix Redistribute out Port-channel1

!

ip prefix-list Redistribute seq 10 permit 10.100.0.0/16

ip prefix-list Redistribute seq 20 permit 10.10.0.0/16

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.16.1 (Port-channel1) is resync: route configuration changed

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.16.1 (Port-channel1) is down: Interface Goodbye received

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.16.1 (Port-channel1) is up: new adjacency

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.100.1.234 (TenGigabitEthernet1/1) is resync: route configuration changed

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.100.1.234 (TenGigabitEthernet1/1) is down: stuck in active

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.100.1.234 (TenGigabitEthernet1/1) is up: new adjacency

[Dan-Ciprian Cicioiu]

Hi ,

Yes it is normal.

Dan

[Peter Paluch]

Dan, Jignesh,

As Dan commented already, this is  normal. Let me just add that this adjacency "flap" is performed in order  to make the changes actually effective. As you know, EIGRP sends the  full topology table to a neighbor when the neighbor first comes up, and  then it sends only the changes.

After the routers are  synchronized, configuring a distribute list with the event-driven nature  of EIGRP would make it difficult for the changes to actually apply. The  routers would need to keep track of every route sent to and received  from a neighbor to know which route has changed (i.e. would or would not  be sent/accepted) to apply the changes as dictated by the current  distribute list. It is much easier to simply tear down and reestablish  the adjacency between neighbors. When an adjacency is tear down and  reestablished, all learned routes between particular neighbors are  simply forgotten and the entire synchronization between the neighbors is  performed anew - with the new distribute list in place. Although  somewhat primitive approach, it is very effective.

So  it is normal and actually necessary to see the EIGRP adjacency flap  whenever a configuration change is applied that results in changes to  routing information sent or received from neighbors - in particular,  distribute lists, offset lists and changes to summarization.

Best regards,

Peter

[Jignesh Desai]

Thanks for the great information!  Although this is normal behavior, is there a way to prevent this from happeneing?  Is NSF an option?

[Peter Paluch]

Hello Jignesh,

Although this is normal behavior, is there a way to prevent this from happeneing?  Is NSF an option?

Prevent what from happening? The EIGRP adjacency flap? As I tried to explain, the adjacency flap is the only way the EIGRP can actually apply the changes. Technically, the restart is performed by setting a special flag in EIGRP packet header that indicates the restart, invalidating the current topology table and re-synchronizing it. Please note that the routing table is modified only after the processes have resynchronized - during the resync, the routing table is not modified.

I am not sure if this answers your question - please ask further.

Best regards,

Peter

[Richard Burts]

I believe that the neighbor flap was the traditional operation when a distribute list was changed. I believe that enhancements associated with NSF have changed that behavior and that in recent code is is possible to change a distribute list, to have the changed distribute list affect advertised routes, and for the neighbor not to flap.

HTH

Rick

[kathpric]

Rick is right, in later code with EIGRP NSF enhancements the neighbor won't flap.  It will only resync.  I verified with a quick test on my lab device.

R15(config)#do sh ip eigrp neigh

EIGRP-IPv4 Neighbors for AS(1)

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.67.67.14             Et0/0             13 2w1d      208  1248  0  1036

R15(config)#router eigrp 1

R15(config-router)#distribute-list prefix test out

R15(config-router)#

*Jan  7 00:53:30.092: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.67.67.14 (Ethernet0/0) is resync: route configuration changed

R15(config-router)#                               

R15(config-router)#end

R15#

*Jan  7 00:53:47.896: %SYS-5-CONFIG_I: Configured from console by console

R15#

R15#sh ip eigrp neigh  

EIGRP-IPv4 Neighbors for AS(1)

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.67.67.14             Et0/0             12 2w1d      174  1044  0  1037

R15#conf t

This router was running 15.1(1)T.  Peter is right about the older code, it will flap every time you make a change like this before these enhancements.

Kathy

[Richard Burts]

Kathy

Thanks for confirming that the behavior of EIGRP did change and for including the results of your test which demonstrate this.

HTH

Rick