Enhanced Interior Gateway Routing Protocol (EIGRP) is an enhanced distance-vector protocol based on the diffusing update algorithm (DUAL). It is capable of (conservatively) finding all loop-free paths to any given destination based on route advertisements from neighbors. The neighbor (or neighbors) with the best path to a destination is called the successor. The remaining neighbors with loop-free paths to the destination are called feasible successors. To reduce traffic load on the network, EIGRP maintains neighbor relationships and exchanges routing information only as needed, using a query process to find alternate paths when all loop-free paths to a destination have failed.
There are no specific requirements for this document.
The information in this document is based on Cisco IOS® Software Release 12.0.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Routes that have a valid successor are said to be in a “passive” state. If, for some reason, a router loses a route through its successor and does not have a feasible successor for that route, then the route transitions to an “active” state. In the active state, a router sends queries out to its neighbors requesting a path to the lost route.
When an EIGRP neighbor receives a query for a route, it behaves as follows:
If the EIGRP topology table does not currently contain an entry for the route, then the router immediately replies to the query with an unreachable message, stating that there is no path for this route through this neighbor.
If the EIGRP topology table lists the querying router as the successor for this route and a feasible successor exists, then the feasible successor is installed and the router immediately replies to the query.
If the EIGRP topology table lists the querying router as the successor for this route and a feasible successor does not exist, then the router queries all of its EIGRP neighbors except those sent out the same interface as its former successor. The router will not reply to the querying router until it has received a reply to all queries that it originated for this route.
If the query was received from a neighbor that is not the successor for this destination, then the router replies with its successor information.
The DUAL-3-SIA error message indicates that an EIGRP route is in the “stuck in active” (SIA) state.
The SIA state means that an EIGRP router has not received a reply to a query from one or more neighbors within the time allotted (approximately 3 minutes). When this happens, EIGRP clears the neighbors that did not send a reply and logs a DUAL-3-SIA error message for the route that went active.
Consider the following topology as an example:
R2 learns about network 10.1.2.0/24 via R1.
The link between R1 and R2 goes down. R2 looses its successor (R1) for 10.1.2.0/24.
R2 checks the EIGRP topology table for a feasible successor (another neighbor with a route to 10.1.2.0/24 that meets the feasibility condition); it has none.
R2 transitions from passive to active for 10.1.2.0/24.
R2 sends queries to R3 and R5, asking if they have another path to 10.1.2.0/24. The SIA timer starts.
R5 checks the EIGRP topology table for a feasible successor; it has none.
R5 transitions from passive to active for 10.1.2.0/24.
R5 checks its EIGRP neighbor table and only finds EIGRP neighbors out the interface facing R2 (its former successor for 10.1.2.0/24).
R5 replies with an unreachable message because it has no alternative path and has no other neighbors to query.
R5 transitions from active to passive for 10.1.2.0/24.
R3 checks the EIGRP topology table for a feasible successor; it has none.
R3 transitions from passive to active for 10.1.2.0/24.
R3 checks its EIGRP neighbor table and finds R4.
R3 sends a query to R4 for network 10.1.2.0/24. The SIA timer starts.
R4 never receives the query either due to problems with the link between R3 and R4 or congestion. You can see this problem by issuing either the show ip eigrp neighbor command or the show ip eigrp topology active command on R3; the queue count for R4 should be higher than usual.
The SIA timer on R2 reaches approximately 3 minutes.
R3 can not reply to R2’s query until it hears a reply from R4.
R2 logs a DUAL-3-SIA error for network 10.1.2.0/24 and clears the neighbor adjacency with R3.
DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1:
Neighbor 10.1.4.3 (Serial0) is down: stuck in active
DEC 20 12:15:23: %DUAL-3-SIA:
Route 10.1.2.0/24 stuck-in-active state in IP-EIGRP 1.
R3’s retry timer for R4 expires.
Note: This event prevents R3 from also reporting a DUAL-3-SIA error because R3’s SIA timer may also be about to reach 3 minutes.
R3 clears its neighbor adjacency with R4.
R3 reports the following error to its log:
DEC 20 12:12:01: %DUAL-5-NBRCHANGE: IP-EIGRP 1:
Neighbor 10.1.5.4 (Serial1) is down: retry limit exceeded
R3 now replies to R2’s query with an unreachable message.
R4 reports the following error to its log:
DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1:
Neighbor 10.1.5.3 (Serial0) is down: peer restarted
Note: The DUAL-5-NBRCHANGE messages will only be displayed if you have configured the eigrp log-neighbor-changes command under the EIGRP process. Configuring this command on all EIGRP routers is recommended for troubleshooting EIGRP SIA problems. Without it, there is no way to tell why EIGRP neighbors are being reset or which router reset the adjacency.
As you can see above, the DUAL-3-SIA error is caused by the following concurrent, yet unrelated, problems:
An interface problem between R1 and R2, which causes the 10.1.2.0/24 route to disappear from R2. The route flap may have been caused by something other than an actual link failure (for instance, a remote user disconnected and the PPP-derived host route is then removed).
An interface, congestion, or delay problem between R3 and R4.
When the SIA error message occurs, it indicates that the EIGRP routing protocol failed to converge for the specified route. Usually, this failure is caused by a flapping interface, a configuration change, or dialup clients (the route loss is normal). The routing to other destinations is not affected while the EIGRP process is in active state for the specified route. When the SIA timer for the neighbor that did not reply expires, the neighbor is cleared (EIGRP does not trust the state of a neighbor that exceeds the timer). As a consequence, routes in the topology table beyond that neighbor are cleared and must then re-converge. This means that the forwarding table can be effected by an SIA, and that packets can be dropped while the network is converging.
This section provides the steps necessary to troubleshoot SIA issues and provides common causes of SIA issues.
Although there are many different ways in which an SIA can occur, the problem should always be approached in the same manner.
Whenever you troubleshoot SIA errors, you should answer the following two questions (listed in order of urgency) to identify the possible causes of the SIA.
Why did the router not get a response from all of its neighbors?
Why did the route disappear?
Note: With Cisco bug ID CSCdp33034 (registered customers only) —effective with Cisco IOS Software Release 12.1(4.4)E—the following enhancements have been made to help resolve the SIA problem:
Use these commands to gather more details for troubleshooting:
Unfortunately, this question is the hardest part of troubleshooting SIAs. Because the SIA timer is a little over 3 minutes by default, it is necessary to track down an unresponsive router within this time period. To do so, make sure that you have a network topology diagram that includes all routers in the network along with their IP addresses. You should also have the Telnet password for each router.
With this information in hand, go to the router that has been reporting SIAs and watch for that route or other routes to go active. You can determine which routes are active on a router by issuing the show ip eigrp topology active command. It is normal for this command to list some active routes. The existence of an active route does not, by itself, indicate a problem; pay particular attention to routes that have been active for longer than one minute.
R2# show ip eigrp topology active
IP-EIGRP Topology Table for process 1
Codes: P - Passive, A - Active, U - Update,
Q - Query, R - Reply, r - Reply status
A 10.1.2.0 255.255.255.0, 1 successors, FD is 2733056 1 replies,
active 0:00:38, query-origin: Multiple Origins
!--- The output above will appear on one line.
via 10.1.4.3 (Infinity/Infinity), r, Serial0, serno 1232
via 10.1.6.5 (Infinity/Infinity), Serial1, serno 1227
The output above tells you that EIGRP has been active for 10.1.2.0/24 for 38 seconds, has queried two neighbors, and is still waiting on a reply from 10.1.4.3. The lowercase r indicates that the router is waiting for a reply to a query. A capital R indicates that it received a reply from this neighbor. Depending on the state of the topology table when you issue this command, you can also see the neighbor in a separate section called “Remaining Replies.”
Once you identify from which router EIGRP is awaiting a response, you can Telnet to that router to determine for what EIGRP is waiting. This process should eventually lead to the actual router that is not responding to queries. Once you identify this router, troubleshoot why it is not responding to queries. Several common reasons are explained below.
Use of older EIGRP code (Cisco IOS Releases earlier than 10.3, 11.0, and 11.1)
EIGRP was enhanced in Cisco IOS Software Releases 10.3(11), 11.0(8), and 11.1(3). One of these enhancements prevents any single EIGRP process from using more than 50 percent of the available bandwidth for that link; you can adjust this percentage, which may differ on multipoint interfaces. This enhancement uses pacing, which allows EIGRP packets to be delivered more reliably on congested links. For more information on packet pacing, refer to the Enhanced Interior Gateway Routing Protocol White Paper.
Missing or incorrect bandwidth interface configuration parameter
If the bandwidth statement is not properly configured for an interface or subinterface, EIGRP can not properly pace EIGRP data packets. The default value of the bandwidth parameter for a serial interface is T1 or 1500 kbps. For serial interfaces other than T1s—including fractional or channelized T1 interfaces—this parameter must be manually set to reflect the correct bandwidth based on the interface’s clock rate. Never use the bandwidth parameter to influence EIGRP path selection.
Incorrect bandwidth configured to influence path selection
In the case of redundant paths, a common practice to force a routing protocol to select one path instead of another is to modify the bandwidth parameter on the interface. Configuring an artificially low bandwidth value on one interface prevents the routing protocol from using the path across that interface. You should avoid this method with EIGRP, as it also uses this bandwidth setting for EIGRP packet pacing. To influence EIGRP path selection on an interface basis, use the delay interface configuration parameter.
You should always ensure that the bandwidth parameter is set to the actual available bandwidth for the interface or subinterface.
EIGRP routing loops
Routing loops can also cause SIA errors. You can identify this problem using the show ip eigrp topology active command. If you see a circular pattern of unanswered EIGRP queries, continue troubleshooting the issue as a routing loop problem.
Mismatched primary and secondary addresses
ip address 10.1.1.1 255.255.255.0
ip address 10.2.1.1 255.255.255.0 secondary
ip address 10.2.1.2 255.255.255.0
In the example above, R1 receives EIGRP hello packets from R2, and shows R2 as an EIGRP neighbor. However, R2 does not see R1 as a neighbor because R1’s hello packets are sourced from 10.1.1.1, which is not a subnet that R2 recognizes. In later versions of Cisco IOS Software, R2 will return the neighbor not on common subnet error. This error causes SIAs because queries sent from R1 to R2 are never answered. To see if R1 continually clears R2 as a neighbor, use the show ip eigrp neighbor command.
Router with limited resources
A lack of system resources—such as CPU, memory, or buffers—can also prevent a router from replying to queries or from processing packets of any type. To identify a problem with resources, ping the affected router and troubleshoot it as if it were any other router resource problem.
There are several common causes of flapping routes, explained below.
A flapping link.
Use the show interface command to look for an increasing “interface resets” or “carrier transitions” counter.
A degraded WAN link.
Use the show interface command to look for an increasing “input errors” or “output errors” counter.
A dialup server—such as a Cisco AS5800—which has not been configured to summarize host routes created by the dialup PPP links.
By default, PPP connections install a 32-bit host route for the remote side of the PPP link. If these routes are not aggregated, EIGRP goes active when every dialup user disconnects.