In this article, we will examine the “art” of Troubleshooting EIGRP. This content should help those engineers in the field, as well as assist candidates studying for any level of the Routing and Switching track of Cisco Certification.
We will start with a review of key information tp keep in mind about the protocol or its proper implementation and troubleshooting, and then specific scenarios will be illustrated. The article will also provide specific command guidance and usage. Understand that the review portion of this article is just that—it is a review. The material is not taught from the ground up, as it is assumed that you have studied EIGRP at the CCENT and CCNA levels if you are reading this article.
EIGRP Review
EIGRP is a hybrid or advanced distance vector protocol. It does indeed utilize three databases in its approach to routing, and this is similar to a pure link-state routing protocol approach like OSPF or IS-IS. The three databases are:
- A neighbor table—this table is critical to check during troubleshooting. Obviously, you are not going to be able to route properly in the network if you do not have all of the adjacencies established that you should between your routers. To check the EIGRP Neighbor Table contents, use show ip eigrp neighbors.
- A topology table—this table is used to store all of the EIGRP prefix information. This is particularly important in EIGRP since the protocol will mark certain routes as Feasible Successors. These are second best routes and act as quick convergence backups to the Successor routes. Successor routes are best paths and these routes are installed in the third database—the forwarding table. You view this database with show ip eigrp topology.
- The forwarding (routing) table—this is the classic routing table that we know and love on your Cisco device. You can view this table for EIGRP with show ip route eigrp.
Remember that EIGRP uses Hello packets in order to help establish and maintain adjacencies. These Hello packets are typically multicast to 224.0.0.10. The default interval for these packets varies from a high speed LAN interface to a WAN as follows:
- LAN (greater than T1)—Hello 5 sec Hold 15 sec
- WAN—Hello 60 sec Hold 180 sec
Engineers can vary these timers from the defaults, and surprisingly, they do not even need to match. The routers will agree on a value to use during adjacency formation.
EIGRP can use up to four components in its calculation of metric. These values are Bandwidth, Delay, Load, and Reliability. A fifth component, MTU, is carried in EIGRP updates to act as a tiebreaker, but the value is not used in the metric calculation. To manipulate the values used in the metric and their weighting, you can use the K values for EIGRP. The default settings of these values are K1 = 1 and K3 = 1, with K2, K4, and K5 set to 0.
How does EIGRP pick a feasible successor route (if one exists)? EIGRP uses a concept called the Feasibility Condition (FC). It states that the Advertised Distance (AD) of the potential Feasible Successor must be less than the Feasible Distance (FD) of the current successor route. This is a loop prevention mechanism.
If a prefix is lost in EIGRP and there is no Feasible Successor route, then the route is marked Active (instead of Passive) and the router sends Query packets to its neighbors. The router must get a response from these queries or the prefix can be SIA (Stuck In Active) and neighbor relationships could be torn down. Cisco has improved this process with SIA Queries in an attempt to no longer down relationships between routers that actually have valid communication capabilities between each other.
EIGRP can load balance between unequal paths. You use a command called variance to control this.
Key Troubleshooting Commands
Here are some critical EIGRP troubleshooting commands and their particular uses:
- show ip eigrp neighbors—this command is critical for ensuring EIGRP adjacencies are in place as expected. Common reasons for the failure of an adjacency include a mismatch in the Autonomous System number, a failure of the multicast communications on the circuit, misconfigured EIGRP authentication, or misconfigured passive interface.
- show ip eigrp interfaces—this command is useful for a quick view of what local interfaces on the device are actually running EIGRP. Should you find key interfaces missing from the output, and ensure your interface is enabled and properly referenced in an EIGRP network command.
- show ip eigrp topology—this command is critical for two main reasons. One, it allows us to see which routes are marked as Passive and which are Active. Two, it allows us to see which routes possess Feasible Successors. Advertised Distances and Feasible Distance information is given for each prefix in the topology database.
- debug ip routing—while not specific to EIGRP, this powerful debug command sends console messages for each major event that transpires in the Routing Table. Should an EIGRP prefix be deleted or added, instant alerts can be viewed by the administrator. This command is critical during redistribution scenarios to ensure that the forwarding database is stable.
- debug eigrp packets—this more advanced troubleshooting command allows the administrator to see EIGRP packets as they are sent or received. You can control the debug with keywords to limit the packet types that are displayed. In addition to being critical during certain troubleshooting scenarios, this command is also a very valuable tool when studying EIGRP.
- debug ip eigrp—while often confused with the debug eigrp packets command, this command focuses more on events that occur with EIGRP. There is more of an emphasis on the contents of routing updates, and events that occur as a result of these contents.
A Sample Troubleshooting Scenario
Imagine three routers, R1->R2->R3, connected via a FastEthernet interfaces. R3 has a loopback 100 interface with a prefix of 100.100.100.0/24 that should appear in the EIGRP database and routing table of R1. This is not occurring. Our job is to quickly determine why, and fix any problems that we discover.
We decide to start at R1, where the prefix should exist. A logical starting point there is to check for the adjacency with R2.
R1#show ip eigrp neighbors IP-EIGRP neighbors for process 100 R1#
There is no neighborship. Let us examine the state of the interfaces and the EIGRP configuration on this device.
R1#show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 12.12.12.1 YES manual up up FastEthernet0/1 unassigned YES unset administratively down down R1#show running-config | section eigrp router eigrp 100 network 12.12.12.1 0.0.0.0 auto-summary neighbor 12.12.12.2 FastEthernet0/0 R1#
The interface is UP/UP which is perfect, and it is correctly defined under the EIGRP AS 100 router configuration. Notice the neighbor command, however. This indicates that packets will be unicast instead of multicast to the R2 device. This is fine, as long as the R2 device has a matching configuration.
Let us examine R2 now in a similar fashion.
R2#show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 12.12.12.2 YES manual up up FastEthernet0/1 23.23.23.2 YES manual up up R2#show running-config | section eigrp router eigrp 101 network 12.12.12.2 0.0.0.0 network 23.23.23.2 0.0.0.0 auto-summary R2#
The interfaces are fine and the network statements appear correct, but the AS number does not match, and there is no matching neighbor command. We will apply these fixes and check for a neighborship.
R2(config)#no router eigrp 101
R2(config)#router eigrp 100
R2(config-router)#network 12.12.12.2 0.0.0.0
R2(config-router)#network 23.23.23.2 0.0.0.0
R2(config-router)#neighbor 12.12.12.1 fa0/0
R2(config-router)#do show ip eigrp neigh
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 12.12.12.1 Fa0/0 13 00:00:06 73 438 0 4
0 23.23.23.3 Fa0/1 12 00:00:40 1273 5000 0 4
R2(config-router)#
Notice that R2 neighbors with the devices now just fine. Let us check for the prefix here on R2.
R2(config-router)#do show ip route eigrp
D 100.0.0.0/8 [90/409600] via 23.23.23.3, 00:07:10, FastEthernet0/1
23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 23.0.0.0/8 is a summary, 00:07:13, Null0
12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 12.0.0.0/8 is a summary, 00:07:13, Null0
R2(config-router)#
The prefix does indeed exist on R2, but notice it is being automatically summarized by EIGRP. Let us check for it on R1.
R1#show ip route eigrp D 100.0.0.0/8 [90/435200] via 12.12.12.2, 00:08:16, FastEthernet0/0 D 23.0.0.0/8 [90/307200] via 12.12.12.2, 00:08:16, FastEthernet0/0 R1#
Excellent. The prefix now exists, and the only remaining problem is the automatic summarization. To make the fewest changes possible, we can turn off automatic summarization in the scenario where it is affecting us only, the R3 device. After this step, we verify the routing table on R1.
R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#
R1#show ip route eigrp
100.0.0.0/24 is subnetted, 1 subnets
D 100.100.100.0 [90/435200] via 12.12.12.2, 00:00:09, FastEthernet0/0
D 23.0.0.0/8 [90/307200] via 12.12.12.2, 00:09:47, FastEthernet0/0
We hope you enjoyed this EIGRP Troubleshooting article and sample scenario. Join us for the many more that will follow!