- Dynamic Routing Review
- Troubleshooting EIGRP
- Implementing EIGRP for IPv6
- Chapter Summary
- Review Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Troubleshooting EIGRP
The ability to troubleshoot problems related to the exchange of routing information and missing information from the routing table is one of the most essential skills for a network engineer who is involved in the implementation and maintenance of a routed enterprise network that uses a routing protocol.
This section provides a suggested troubleshooting flow and explains the Cisco IOS commands that you can use to gather information from the EIGRP data structures and routing processes to detect and correct routing issues.
Components of Troubleshooting EIGRP
In troubleshooting EIGRP, as with any networking issue, follow a structured methodology. Figure 3-11 shows a suggested flowchart.
)
Figure 3-11 EIGRP Troubleshooting Flowchart
After configuring EIGRP, first test connectivity to the remote network, using ping. If the ping fails, check that the router has EIGRP neighbors and troubleshoot on a link-by-link basis. Neighbor adjacency might not be running for a number of reasons. Figure 3-12 provides a very basic design with two EIGRP neighbors connected by an Ethernet switch. The HQ router has three loopback interfaces, and both routers have two FastEthernet interfaces. One FastEthernet (0/0) interface from each router is connected to a switch. The switch has only one VLAN for all ports.
)
Figure 3-12 Simple Network Example
Now let’s examine a few potential scenarios, via show commands:
The interface between the devices is down:
HQ# show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.20 YES NVRAM down down FastEthernet0/1 10.5.0.1 YES NVRAM up up Loopback1 5.5.5.5 YES NVRAM up up Loopback30 2.2.2.2 YES NVRAM up up Loopback100 1.1.1.1 YES NVRAM up up
In this case, FastEthernet0/0 is down. Possibilities include a disconnected cable, a down switch, or faulty hardware.
The two routers have mismatching EIGRP AS numbers:
HQ# show ip protocol Routing Protocol is "eigrp 1" <output omitted> Branch# show ip protocol Routing Protocol is "eigrp 10" <output omitted>
In this case, the Branch and HQ routers are misconfigured with different EIGRP AS numbers.
Proper interfaces are not enabled for the EIGRP process:
HQ# show running-config <output omitted> router eigrp 1 network 192.168.1.0 255.255.255.0 <output omitted> HQ# show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.20 YES NVRAM up up FastEthernet0/1 10.5.0.1 YES NVRAM up up Loopback1 5.5.5.5 YES NVRAM up up Loopback30 2.2.2.2 YES NVRAM up up Loopback100 1.1.1.1 YES NVRAM up up
In this case, there is only a single interface configured for EIGRP.
The interface between the devices is up but can’t ping:
HQ# show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.20 YES NVRAM up up FastEthernet0/1 10.5.0.1 YES NVRAM up up Loopback1 5.5.5.5 YES NVRAM up up Loopback30 2.2.2.2 YES NVRAM up up Loopback100 1.1.1.1 YES NVRAM up up Branch# show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.1.25 YES NVRAM up up FastEthernet0/1 10.20.0.1 YES NVRAM up up
In this case, a potential Layer 2 problem exists. This could be a misconfigured switch port and/or VLAN misconfiguration.
An interface is configured as passive:
HQ# show running-config <output omitted> router eigrp 1 passive-interface FastEthernet0/0 network 192.168.1.0 255.255.255.0 <output omitted>
In this case, a passive-interface is configured. The show ip protocols command will also identify passive interfaces.
Aside from the issues reviewed here, there are a number of other, more advanced concerns that can prevent neighbor relationships from forming. Two examples are misconfigured EIGRP authentication or mismatched K values, depending on which EIGRP calculates its metric. The next section covers specifically neighbor adjacency.
Troubleshooting EIGRP Neighbor Issues
The previous section examined several possible reasons why EIGRP might not be working properly. This section takes a closer look at troubleshooting EIGRP neighbor relationships. As previously mentioned, a major prerequisite for the neighbor relationship to form between routers is Layer 3 connectivity. By investigating the output of show ip interface brief, you can verify that the status and protocol are both up for the interface between the routers. In Figure 3-13 and Example 3-10, the Serial0/0/0 interface that is connected to the Branch router is up. A successful ping then confirms IP connectivity between routers.
)
Figure 3-13 Determining If the Interface Is Operational
Example 3-10 Verifying Protocol and Status of Link Between Neighbors
Branch# show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 10.1.1.1 YES NVRAM up up Serial0/0/0 192.168.1.1 YES NVRAM up up Branch# ping 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
If the ping is not successful, as shown in Example 3-10, you should use the technologies discussed in Chapter 2, “Troubleshooting Basic Connectivity.” First, check the cabling and verify that the interfaces on connected devices are on a common subnet.
If you notice a log message such as the following that states that EIGRP neighbors are “not on common subnet,” this indicates that there is an improper IP address on one of the two EIGRP neighbor interfaces:
*Mar 28 04:04:53.778: IP-EIGRP(Default-IP-Routing-Table:100): Neighbor 192.168.100.1 not on common subnet for Serial0/0/0
If this message was received on the Branch router, you can see that the reported IP address of the neighbor does not match what you expected. However, you can still have an IP address mismatch and not see this message.
Next, check that the AS numbers are the same between neighbors. The command that starts the EIGRP process is followed by the AS number, router eigrp as_number. This AS number is significant to the entire network, as it must match between all the routers within the same routing domain. In other routing protocols, the numbering used to start the process may have only local significance (for instance, the OSPF routing protocol is started with a process-id and does not use an AS number).
In Figure 3-14 and Example 3-11, show ip protocols helps to determine if the AS numbers match.
)
Figure 3-14 Determining AS Numbers
Example 3-11 Using show ip protocols to Verify EIGRP AS Numbers
Branch# show ip protocols Routing Protocol is "EIGRP 1" <output omitted> HQ# show ip protocols Routing Protocol is "EIGRP 2" <output omitted>
Also confirm that EIGRP is running on the correct interfaces. The network command configured under the EIGRP routing process indicates which router interfaces will participate in EIGRP.
The show ip eigrp interfaces interface command shows you which interfaces are enabled for EIGRP. If connected interfaces are not enabled for EIGRP, then neighbors will not form an adjacency. If an interface is not on the list, that means the router is not communicating EIGRP through that interface. Figure 3-15 shows that EIGRP is running on the Branch router. Run the same command on the HQ router and look for the same results. In this case, both routers are neighbors.
)
Figure 3-15 EIGRP Interface Enabled
You can also check the interface by referring to the “Routing for Networks” section of the show ip protocols command output. As shown in Example 3-12, this indicates which networks have been configured; any interfaces in those networks participate in EIGRP.
Example 3-12 Check the “Routing for Networks” Output
HQ# show ip protocols
<output omitted>
Routing Protocol is "eigrp 1"
<output omitted>
Routing for Networks:
172.16.0.0
192.168.1.0
Passive Interface(s):
Serial0/0/0
<output omitted>
With the show ip protocols command, you can also confirm if an interface is in passive mode only. The passive-interface command prevents both outgoing and incoming routing updates, because the effect of the command causes the router to stop sending and receiving hello packets over an interface. For this reason, routers do not become neighbors. An example where you would need to configure an interface as passive toward a specific LAN. You want to advertise LANs but don’t want to have the security risk of transmitting hello packets into the LAN. A final suggestion for checking a failed neighbor relationship is to confirm a mismatch in the authentication parameters. The key authentication configuration must match on both neighbors. The key number and key string should be checked in the running configuration.
Troubleshooting EIGRP Routing Table Issues
This section covers issues that cause missing entries in the routing table when proper connectivity and neighbor relationships exist. The exclusion of routes that should be in the routing table can be caused by routes not being advertised, by route filtering, or by network summarization. Missing routing entries due to these issues can be related to a problem either with a directly connected EIGRP neighbor or with an EIGRP router that is in another section of the network.
Issues Caused by Unadvertised Routes
Routing table issues caused by unadvertised routes are indicated by a failed ping test. Figure 3-16 illustrates the Branch/HQ example that has been implemented. It is established by checking the neighbor adjacency.
)
Figure 3-16 Troubleshooting EIGRP Routing Table Issues with the show ip protocols Command
In this case, checking the show ip protocols command output from the HQ router indicates the HQ router is not advertising 172.16.1.0/24. Adding the network statement to EIGRP, as demonstrated in Example 3-13, should resolve the issue.
Example 3-13 Adding the Correct Network Command
HQ(config)# router eigrp 1 HQ(config-router)# network 172.16.1.0
This should restore the routing table. If it does not, check route filtering. Route filtering can be performed by route maps or ACLs, as discussed in the next section.
Issues Caused by Route Filtering
Routing protocols can be configured to filter routes. This is a powerful tool, especially when connecting different routing domains (different AS). However, a misconfigured filter can be difficult to detect.
When investigating filtering issues, first check the show ip protocols command, as demonstrated in Example 3-14.
Example 3-14 Indentifying Incoming Filtering
Branch# show ip protocols
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is 1
As you can see, there is an ACL. Next, check the ACL, as shown in Example 3-15.
Example 3-15 Identifying Access List Used for Filtering
Branch# show ip access-lists
Standard IP access list 1
10 deny 172.16.0.0, wildcard bits 0.0.255.255 (2 matches)
20 permit any (6 matches)
The ACL matches the missing network. In this case, remove the ACL from the EIGRP configuration, as demonstrated in Example 3-16.
Example 3-16 Removing the Distribute List Used for Filtering
Branch# config t Enter configuration commands, one per line. End with CNTL/Z. Branch(config)# router EIGRP 1 Branch(config-router)# no distribute-list 1 in
The console output shows the change in the adjacency after changing the configuration, as demonstrated in Example 3-17.
Example 3-17 Console Reporting Neighbor Change Due to Reconfiguration
*Mar 1 00:17:37.775: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.1 (FastEthernet0/0) is down: route configuration changed *Mar 1 00:17:41.431: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.1 (FastEthernet0/0) is up: new adjacency
Take notice of the “in” on the distribute-list. ACLs can be placed in both inbound and outbound directions. Inbound and outbound lists are structured the same, but the transmission or reception of routes is controlled by direction.
Issues Caused by Automatic Network Summarization
EIGRP can be configured to automatically summarize routes at classful boundaries. If you have discontiguous networks, automatic summarization can cause inconsistencies in the routing tables.
In Figure 3-17, Router B is not receiving individual routes for the 172.16.1.0/24 and 172.16.2.0/24 subnets. Both Router A and Router C automatically summarized those subnets to the 172.16.0.0/16 classful boundary when sending EIGRP update packets to Router C.
)
Figure 3-17 Automatic Summarization Issues
Router B has two routes to 172.16.0.0/16 in the routing table, which can result in inaccurate routing and packet loss, as shown in Example 3-18.
Example 3-18 Inaccurate Routing Entries
RouterB# show ip route
<output omitted>
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.1.0 is directly connected, Serial0/2/0
C 10.2.2.0 is directly connected, Serial0/3/0
D 172.16.0.0/16 [90/2172416] via 10.1.1.1, 00:03:51, Serial0/2/0
[90/2172416] via 10.2.2.3, 00:00:14, Serial0/3/0
In Example 3-19, automatic summarization is disabled by entering the no auto-summary command in the router eigrp configuration mode:
Example 3-19 Disable Automatic Summarization
RouterB(config)# router eigrp 1 RouterB(config-if)# no auto-summary