Core Issue
Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco proprietary enhanced distance vector routing protocol. EIGRP had a number of advantages, including its ability to speed up convergence by storing backup routes in the topology table. However, at times, EIGRP might encounter these performance issues:
- Flapping of EIGRP neighbors. The stability of the neighbor relationship is of primary concern. A failure in the neighbor relationship is accompanied by increased CPU and bandwidth utilization. EIGRP neighbors might flap for these reasons:
- Underlying link flaps. When an interface goes down, EIGRP takes down the neighbors that are reachable through that interface and flushes all routes learned through that neighbor.
- Misconfigured hello and hold intervals. The EIGRP hold interval can be set independently of the hello interval by issuing the ip hold-time eigrp command. Setting a hold interval smaller that the hello interval results in the neighbors flapping continuously.
- Loss of hello packets: Hello packets might be lost on overly congested links or error prone links (CRC errors, Frame errors, excessive collisions)
- Existence of unidirectional links. A router on a unidirectional link might be able to receive hello packets. However, the hello packets sent out are not received at the other end. The existence of this state is usually indicated by the retry limit exceeded messages on one end.
- Route goes stuck-in-active. When a route enters the stuck-in-active state, the neighbors from which the reply was expected is reinitialized, and the router goes active on all routes learned from those neighbors.
- Not provisioning sufficient bandwidth for the EIGRP process. When sufficient bandwidth is not available, packets might be lost, which causes neighbors to go down.
- High CPU utilization. This might occur for these reasons:
- Presence of a large number of specific routing table entries. If a large number of specific routes exist in the routing table (such as 32 entries corresponding to async interfaces), a large number of EIGRP updates need to be exchanged. The EIGRP process is triggered more frequently, each time an interface changes state or a route is lost.
- Issues addressed in Cisco bug ID CSCdt15109.
- Issues addressed in Cisco bug ID CSCdw91468.
- Issues addressed in Cisco bug ID CSCdk73832. In certain older versions of Cisco IOS Software, when the number of equal cost paths available is greater than the number of paths configured by issuing the maximum-paths command, high CPU utilization is observed.
Resolution
Issue the eigrp log-neighbor-changes command to resolve unstable neighbor relationships. The output of the command includes information on when neighbors have been reset and the reasons
To ensure stability, consider the following issues:
- Ensure that the underlying link is stable.
- Make sure that the configured value of the hold interval is larger that the hello interval.
- On overly congested or error prone links, set the hold interval to a sufficiently large value to cater for lost hello packets.
- Make sure that the link is bidirectional.
- Make sure that routes do not enter the stuck-in-active state by decreasing the query scope with techniques such as summarization, use of distribute-lists and defining routers as stub-routers.
- Ensure that sufficient bandwidth is available for EIGRP traffic. Issue the ip bandwidth-percent eigrp command in the interface configuration mode to configure the percentage of bandwidth that may be used by EIGRP on an interface.
EIGRP neighbors are also reset when a summary changes on an interface, the delay or bandwidth value is changed or a distribute-list is added, removed or changed on an interface. This is done in order to synchronize the topology entries. Though this is unavoidable, care should be taken not to make these configuration changes when the network is already under stress.
The problem of high CPU utilization by the EIGRP process can be mitigated by refering to these solutions:
- Configure route summarization to prevent the EIGRP process from triggering each time an interface changes state or a specific route is lost. For information on configuring route summarization, refer to Configuring Summary Aggregate Addresses and TAC Case Collection (TAC CC) solution K17263253.
- On routers facing the issues in Cisco bug ID CSCdt15109 and CSCdw91468, refer to the respective release-notes.
- On routers facing the issues in Cisco bug ID CSCdk73832, increase the maximum-paths to six or switch to Cisco IOS version 11.2(16) or later.
