Troubleshooting EIGRP
As an advanced distance vector routing protocol, EIGRP scales well with a growing network. However, this scalability introduces complexity in design, configuration, and maintenance. This section introduces some of the common issues surrounding an EIGRP network and a flowchart approach to troubleshooting these issues.
Components of Troubleshooting EIGRP
When troubleshooting any network protocol, it is important to follow a defined flow or methodology. The main aspect of troubleshooting routing protocols involves ensuring that communication exists between the routers. The following sections describe the basic components of troubleshooting a network that is running EIGRP. Figure 5-8 shows an example of the flow used for diagnosing EIGRP problems.
)
Figure 5-8 EIGRP Troubleshooting
The major components of EIGRP troubleshooting include the following items:
- EIGRP neighbor relationships
- EIGRP routes in the routing table
- EIGRP authentication
Troubleshooting EIGRP Neighbor Relationships
The first step in the flow is to troubleshoot neighbor relationships. Figure 5-9 shows the steps for troubleshooting these issues.
)
Figure 5-9 Troubleshooting EIGRP Neighbor Issues
Example 5-9 shows output from the show ip eigrp neighbors command, which indicates that a successful neighbor relationship exists with two routers.
Example 5-9. Confirming EIGRP Neighbor Relationships
RouterX# show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.23.23.2 Se0/0/1 13 00:02:26 29 2280 0 15
0 10.140.1.1 Se0/0/0 10 00:28:26 24 2280 0 25
For EIGRP routers to form a neighbor relationship, both routers must share a directly connected IP subnet. A log message that displays that EIGRP neighbors are "not on common subnet" indicates that an improper IP address exists on one of the two EIGRP neighbor interfaces. Use the show interface interface command to verify the IP addresses.
In the output in Example 5-10, the interface address is 10.2.2.3/24.
Example 5-10. Confirming EIGRP Neighbor IP Address
RouterX# show ip interface fa0/0 FastEthernet0/0 is up, line protocol is up Internet address is 10.2.2.3/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set
The network command that is configured under the EIGRP routing process indicates which router interfaces will participate in EIGRP. The "Routing for Networks" section of the show ip protocols command indicates that the networks have been configured; any interfaces in those networks participate in EIGRP. In the output of Example 5-11, EIGRP is running on any interfaces that have an IP address on the 10.0.0.0 and 192.168.1.0 networks.
Example 5-11. Confirming Router Interface Participation in EIGRP Routing
RouterX# show ip protocols
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
--output omitted --
Maximum path: 4
Routing for Networks:
10.0.0.0
192.168.1.0
Routing Information Sources:
Gateway Distance Last Update
(this router) 90 00:01:08
10.140.1.1 90 00:01:08
Distance: internal 90 external 170
The show ip eigrp interfaces command can quickly indicate on which interfaces EIGRP is enabled and show how many neighbors can be found on each interface. In the output in Example 5-12, no peers currently exist on the FastEthernet 0/0 interface, and one peer exists on the Serial 0/0/0 interface.
Example 5-12. Confirming EIGRP Status and Neighbors on an Interface
RouterX# show ip eigrp interfaces
IP-EIGRP interfaces for process 100
Xmit Queue Mean Pacing Time Multicast Pending
Int Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa0/0 0 0/0 0 0/1 0 0
Se0/0/0 1 0/0 38 10/380 552 0
EIGRP routers create a neighbor relationship by exchanging hello packets. Certain fields in the hello packets must match before an EIGRP neighbor relationship is established:
- EIGRP autonomous system (AS) number
- EIGRP K values
You can use the debug eigrp packets command to troubleshoot when hello packet information does not match. In Example 5-13, a K value mismatch exists.
Example 5-13. Verifying EIGRP Hello Packet Mismatches
RouterX# debug eigrp packets Mismatched adjacency values 01:39:13: EIGRP: Received HELLO on Serial0/0 nbr 10.1.2.2 01:39:13:AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0 01:39:13: K-value mismatch
Troubleshooting EIGRP Routing Tables
If the neighbor relationships are established, routes can be exchanged. If they are not being exchanged, the next step is to troubleshoot EIGRP routing table issues. Figure 5-10 shows the steps involved in troubleshooting these problems.
)
Figure 5-10 Troubleshooting EIGRP Routing Tables
EIGRP routes that appear with a "D" in the routing table indicate that they are intra-AS routes, and those with "D EX" indicate that they are external AS routes. No EIGRP routes in the routing table can indicate that a Layer 1 or 2 issue or an EIGRP neighbor problem exists.
In the output in Example 5-14, the 172.16.31.0/24 network is an intra-AS route, and 10.3.3.0/24 is a route that was redistributed into EIGRP.
Example 5-14. Confirming EIGRP Intra-AS and Redistributed Routes
RouterX# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.31.0/24 [90/40640000] via 10.140.1.1, 00:01:09, Serial0/0/0
O 172.16.31.100/32 [110/1563] via 10.140.1.1, 00:26:55, Serial0/0/0
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C 10.23.23.0/24 is directly connected, Serial0/0/1
D EX 10.3.3.0/24 [170/40514560] via 10.23.23.2, 00:01:09, Serial0/0/1
C 10.2.2.0/24 is directly connected, FastEthernet0/0
The show ip eigrp topology command displays the EIGRP router ID. The EIGRP router ID comes from the highest IP address assigned to a loopback interface. If no loopback interfaces are configured, the highest IP address assigned to any other active interface is chosen as the router ID. No two EIGRP routers can have the same EIGRP router ID. If they do, you will experience problems exchanging routes between the two routers with equal router IDs.
In the output in Example 5-15, the router ID is 192.168.1.65.
Example 5-15. Displaying EIGRP Router IDs
RouterX# show ip eigrp topology
IP-EIGRP Topology Table for AS(100)/ID(192.168.1.65)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.1.1.0/24, 1 successors, FD is 40514560
via 10.140.1.1 (40514560/28160), Serial0/0/0
P 10.2.2.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 10.3.3.0/24, 1 successors, FD is 40514560
via 10.23.23.2 (40514560/28160), Serial0/0/1
P 10.23.23.0/24, 1 successors, FD is 40512000
via Connected, Serial0/0/1
P 192.168.1.64/28, 1 successors, FD is 128256
via Connected, Loopback0
P 192.168.1.0/24, 1 successors, FD is 40640000
via 10.23.23.2 (40640000/128256), Serial0/0/1
P 10.140.2.0/24, 2 successors, FD is 41024000
via 10.23.23.2 (41024000/40512000), Serial0/0/1
via 10.140.1.1 (41024000/40512000), Serial0/0/0
P 10.140.1.0/24, 1 successors, FD is 40512000
via Connected, Serial0/0/0
P 172.16.31.0/24, 1 successors, FD is 40640000
EIGRP routes that are found in the topology table but not in the routing table can indicate an issue that requires help from Cisco Technical Assistance Center (TAC) to diagnose the problem.
Route filtering enables routes to be filtered from an EIGRP routing advertisement as they come in from a neighbor or as they are sent out to a neighbor. These filters can cause routes to be missing from the routing table. The show ip protocols command shows whether any filter lists are applied to EIGRP.
By default, EIGRP is classful and performs automatic network summarization. Automatic network summarization causes connectivity issues in discontiguous networks. The show ip protocols command confirms whether automatic network summarization is in effect.
In the sample output in Example 5-16, no filter lists are applied to EIGRP AS 100, and automatic network summarization is in effect.
Example 5-16. Confirming EIGRP Automatic Network Summarization
RouterX# show ip protocols
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is in effect
Automatic address summarization:
192.168.1.0/24 for FastEthernet0/0, Serial0/0/0, Serial0/0/1
Summarizing with metric 128256
10.0.0.0/8 for Loopback0
Summarizing with metric 28160
Maximum path: 4
Troubleshooting EIGRP Authentication
The last step in the flowchart in Figure 5-8 is to troubleshoot EIGRP authentication problems, if configured. This is accomplished by verifying that EIGRP authentication is successful.
Example: Successful MD5 Authentication
The output of the debug eigrp packets command on Router X, shown in Example 5-17, illustrates that Router X is receiving EIGRP packets with MD5 authentication and a key ID equal to 1 from Router Y.
Example 5-17. Confirming MD5 Authentication on Router X
RouterX# debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
*Jan 21 16:38:51.745: EIGRP: received packet with MD5 authentication, key id = 1
*Jan 21 16:38:51.745: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.102
*Jan 21 16:38:51.745: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ
un/rely 0/0
Similarly, the output of the debug eigrp packets command on Router Y, shown in Example 5-18, illustrates that Router Y is receiving EIGRP packets with MD5 authentication and a key ID equal to 2 from Router X.
Example 5-18. Confirming MD5 Authentication on Router Y
RouterY# debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)
RouterY#
*Jan 21 16:38:38.321: EIGRP: received packet with MD5 authentication, key id = 2
*Jan 21 16:38:38.321: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.101
*Jan 21 16:38:38.321: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ
un/rely 0/0
Example: Troubleshooting MD5 Authentication Problems
In the example, the key string for key 2 of Router X, the one that is used when EIGRP packets are sent, is changed to be different from the key string that Router Y is expecting.
The output of the debug eigrp packets command on Router Y, shown in Example 5-19, illustrates that Router Y is receiving EIGRP packets with MD5 authentication and a key ID equal to 2 from Router X, but that an authentication mismatch exists. The EIGRP packets from Router X are ignored, and the neighbor relationship is declared to be down. The output of the show ip eigrp neighbors command should confirm that Router Y has no EIGRP neighbors.
Example 5-19. MD5 Authentication Mismatch
RouterY# debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
RouterY#
*Jan 21 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch
*Jan 21 16:50:18.749: EIGRP: Serial0/0/1: ignored packet from 192.168.1.101, opc
ode = 5 (invalid authentication)
*Jan 21 16:50:18.749: EIGRP: Dropping peer, invalid authentication
*Jan 21 16:50:18.749: EIGRP: Sending HELLO on Serial0/0/1
*Jan 21 16:50:18.749: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Jan 21 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.101
(Serial0/0/1) is down: Auth failure
RouterY# show ip eigrp neighbors
IP-EIGRP neighbors for process 100
RouterY#
The two routers keep trying to reestablish their neighbor relationship. Because of the different keys that are used by each router in this scenario, Router X authenticates the hello messages that are sent by Router Y using key 1. However, when Router X sends a hello message back to Router Y using key 2, an authentication mismatch will occur. From the perspective of Router X, the relationship appears to be up for a while, but then it times out, as illustrated by the messages that were received on Router X, shown in Example 5-20. The output of the show ip eigrp neighbors command on Router X also illustrates that Router X does have Router Y in its neighbor table for a short time.
Example 5-20. Confirming MD5 Authentication
RouterX# debug eigrp packets
*Jan 21 16:54:09.821: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0/
0/1) is down: retry limit exceeded
*Jan 21 16:54:11.745: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0/
0/1) is up: new adjacency
RouterX# show ip eigrp neighbors
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.102 Se0/0/1 13 00:00:38 1 5000 1 0
Summary of Troubleshooting EIGRP
The following summarizes the key points that were discussed in this section:
- Troubleshooting EIGRP includes several aspects, such as resolving neighbor relationships, routing table issues, and authentication problems.
- Issues that can cause EIGRP neighbor problems include incorrect network commands and hello packet information mismatches. Use the show ip eigrp neighbors command to help troubleshoot these issues.
- Missing EIGRP routes from the routing table can be because of route filtering or automatic summarization in discontiguous networks. Use the show ip route command to help troubleshoot these issues.
- The debug eigrp packets command can help you troubleshoot MD5 authentication problems.