Lab Tip: Clear Your EIGRP Process

I spent a good chunk of my weekend going over EIGRP metric manipulation and how it affects EIGRP unequal-cost load-balancing.  More than a few times I ran into weird output like routes dropping, metric values not changing, and even this doozy:

r1#sh ip ei top 164.1.26.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2693120
  Routing Descriptor Blocks:
  164.1.13.3 (Serial0/1), from 164.1.13.3, Send flag is 0×0
      Composite metric is (3026432/2514432), Route is Internal
      Vector metric:
        Minimum bandwidth is 1280 Kbit
        Total delay is 40100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  164.1.12.2 (Serial0/0), from 164.1.12.2, Send flag is 0×0
      Composite metric is (10514432/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 256 Kbit
        Total delay is 20100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

The AD of the successor is not equal to the FD????

By clearing the EIGRP process, these discrepancies go away.  You can do this the soft way:

r1#clear ip eigrp 100 neighbors soft
*Mar  2 05:22:13.522: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is resync: manually cleared

Or the rough way:

r1#clear ip eigrp 100 neighbors
*Mar  2 05:22:48.708: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is down: manually cleared
*Mar  2 05:22:49.782: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is up: new adjacency

I like it rough. 

In the case of EIGRP it really doesn’t matter as the protocol reconverges so quickly.