EIGRP distribute-list & adjacency flaps

[acennami]

I am curious about modifying ACLs associated with an outbound distribute-list.

Upon making modifications to the ACL (ip access-list XX permit xx.xx.xx.xx) is it normal behavior for the peers to flap (distribute list is attached to a named interface).

In any event, in the environment I am in, this does occur, which coming from a BGP/carrier environment, is particularly undesirable.

If this is the norm, is there a method to restrict outbound announcements via EIGRP, while not actually causing the adjacencies to be reset and reconverge?

Regards,

Anthony

[Richard Burts]

Anthony

Yes that is normal for an EIGRP environment. When you change the access list used by a distribute list in EIGRP then the router knows that you have changed the policy about advertisement and it tears down and then rebuilds the neighbor relationship so that the routes advertised to the neighbor (or routes learned from the neighbor if inbound distribute list) will conform to the new policy.

If you come from BGP/carrier environment it may help to compare the operation of BGP and of EIGRP about filtering routing updates. With BGP if you have an established filter it will have applied to routes already advertised and in the tables. If you then make a change in the filter (change the access list) the change will apply to any new updates but will not apply to existing routes until you reset the neighbor (hard reset or soft reset). EIGRP works differently. When you change the access list in EIGRP then EIGRP assumes that you want the policy change to be effective immediately and tears down and rebuilds the neighbor relationship. I do not know of any way to run EIGRP and to change access lists for distribute list and not impact neighbor relationships on the interface with the distribute list.

HTH

Rick

[ruwhite]

CSCdy20284 should have changed this so the mechanism used in graceful restart is used to prevent the neighbor flap on a filter change. I don't know what versions of code this is available in, but I show it integrated in 12.3(7) or thereabouts. I'm certain there's documentation on this feature on CCO, but I can't remember what it's called, and I couldn't find it in a couple of minutes poking around.

HTH

:-)

Russ

[Richard Burts]

Russ

Thanks for pointing this out. I was used to the behavior that would reset the neighbor relationship and missed the change in behavior. It now does a resync. Since we get a syslog message about neighbor change I missed the change from reset to resync.

test_1841(config)#access-list 50 permit 10.0.0.0

test_1841(config)#

Oct 5 15:02:13 EDT: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1999: Neighbor 10.24.68.1 (Tunnel1) is resync: route configuration changed

but the neighbor does stay up now.

Thanks

Rick

[acennami]

Thank you both for your input. I was shocked to find that a widely deployed routing protocol would require a complete reset for a new network announcement; it's 2007, i guess since everybody has redundant gig links everywhere this isn't a major concern. :)

Thanks,

anthony

[royalblues]

I was able to find a PPT on the web for the advances that are planned for EIGRP.

Most of them might have already been incorporated in the protocol but i thought it could help some.

Narayan