Day 11 Troubleshooting Routing
CCNA 640-802 Exam Topics
Troubleshoot routing issues.
Key Topics
During the past three days, we have reviewed both static and dynamic routing, including static routes, default routes, RIPv1, RIPv2, EIGRP, and OSPF. These reviews by their very nature included some brief discussion on troubleshooting routing issues related to each of the routing methods. Today we finish our review of routing concepts and configuration with a focus on troubleshooting routing issues.
The Basic Commands
Troubleshooting routing issues may begin with basic ping and traceroute commands to discover where connectivity is lacking. In the case of a large network, however, these two commands are probably not the most efficient way to find a problem. In addition, if these commands do track down a problem, you still have to discover the cause.
A better method might be to start with your core devices. These devices should be a collection point for all routes in the enterprise. To check for missing routes and track down the reason, the following method can be used for issues related to dynamic routing:
-
Check the routing tables for convergence with the show ip route command. All expected routes should be in the routing table. Barring a security policy that prevents some routes, the device should be able to route to any other location in the enterprise.
-
If you find a missing route or routes, use the show ip protocols command to investigate the routing protocol operation on the local router. The show ip protocols command summarizes just about every detail of a routing protocol’s operation. Helpful information for all protocols includes the following:
— Enable routing protocol: If the expected routing protocol is not enabled, configure it.
— Routing for networks: If a network that should be advertised is missing, it could be that the network command is missing for that route. However, it might also be that the interface or interfaces that belong to that network are not functioning. If so, use show ip interface brief to isolate problems with interfaces.
— Routing information sources: This is a list of neighbors from which the local router is receiving updates. A missing neighbor could be a problem with the local router (missing network command or down interface). Or the problem could be with the neighbor. For EIGRP and OSPF, you can use the display of neighbor relationships as a first step in discovering why a neighbor is not advertising routes to the local router (via the show ip eigrp neighbors and show ip ospf neighbor commands). If neighbor relationships are operating as expected, log in to the neighbor router to discover why the neighbor is not advertising routes.
3. If a static route is missing from the routing table, verify that it is configured using the show running-config command. If configured, either the local exit interface is down or the interface with the next-hop address is down.
VLSM Troubleshooting
The following list summarizes the key troubleshooting points to consider when you’re troubleshooting potential variable-length subnet masking (VLSM) problems on the exam:
Pay close attention to whether the design really uses VLSM. If it does, note whether a classless routing protocol is used.
Be aware that overlapping subnets can indeed be configured.
The outward problem symptoms might be that some hosts in a subnet work well, but others cannot send packets outside the local subnet.
Use the traceroute command to look for routes that direct packets to the wrong part of the network. This could be a result of the overlapped subnets.
On the exam, you might see a question you think is related to VLSM and IP addresses. In that case, the best plan of attack might well be to analyze the math for each subnet and ensure that no overlaps exist, rather than troubleshooting using ping and traceroute.
Discontiguous Networks
Automatic summarization does not cause any problems as long as the summarized network is contiguous rather than discontiguous. For RIPv2 and EIGRP, you must disable automatic summarization in a discontiguous network or you will have a less-than-full convergence situation.
Even a contiguous network design can become discontiguous if one or more link failures divide a classful network into two or more parts. Figure 11-1 shows an internetwork with two contiguous classful networks: 10.0.0.0 and 172.16.0.0.
In this figure, with all links up and working and automatic summarization in effect, all hosts can ping all other hosts. In this design, packets for network 172.16.0.0 flow over the high route, and packets for network 10.0.0.0 flow over the low route.
However, if any link between the routers fails, one of the two classful networks becomes discontiguous. For example, if the link between R3 and R4 fails, the route from R1 to R4 passes through subnets of network 172.16.0.0, so network 10.0.0.0 is discontiguous. The solution, as always, is to use a classless routing protocol with automatic summarization disabled.
Troubleshooting RIP
Most RIP configuration errors involve an incorrect network statement configuration, a missing network statement configuration, or the configuration of discontiguous subnets in a classful environment. As shown in Figure 11-2, using debug ip rip can be an effective way to find issues with RIP updates. This output is from the topology we used on Day 14, “Static, Default, and RIP Routing,” shown in Figure 14-3.
This command displays RIPv1 routing updates as they are sent and received. Because it’s RIPv1, the subnet masks are not included. Because updates are periodic, you need to wait for the next round of updates before seeing any output. The list that follows corresponds to the numbers in Figure 11-2.
-
You see an update coming in from R1 on interface Serial 0/0/0. Notice that R1 sends only one route to the 192.168.1.0 network. No other routes are sent because doing so would violate the split horizon rule. R1 is not allowed to advertise networks back to R2 that R2 previously sent to R1.
-
The next update that is received is from R3. Again, because of the split horizon rule, R3 sends only one route: the 192.168.5.0 network.
-
R2 sends out its own updates. First, R2 builds an update to send out the FastEthernet 0/0 interface. The update includes the entire routing table except for network 192.168.3.0, which is attached to FastEthernet 0/0.
-
Next, R2 builds an update to send to R3. Three routes are included. R2 does not advertise the network R2 and R3 share, nor does it advertise the 192.168.5.0 network because of split horizon.
-
Finally, R2 builds an update to send to R1. Three routes are included. R2 does not advertise the network that R2 and R1 share, nor does it advertise the 192.168.1.0 network because of split horizon.
-
Don’t forget to disable debugging with either no debug ip rip or, as shown in the figure, undebug all.
Troubleshooting EIGRP and OSPF Interface Issues
This section reviews how to verify the interfaces on which the routing protocol has been enabled. Both EIGRP and OSPF configuration enables the routing protocol on an interface by using the network router subcommand. For any interfaces matched by the network commands, the routing protocol tries the following two actions:
Attempts to find potential neighbors on the subnet connected to the interface
Advertises the subnet connected to that interface
At the same time, the passive-interface router subcommand can be configured so that the router does not attempt to find neighbors on the interface (the first action listed) but still advertises the connected subnet (the second action listed).
Table 11-1 summarizes the three show commands you need in order to know exactly which interfaces have been enabled with EIGRP and OSPF and which interfaces are passive.
Troubleshooting Neighbor Adjacency Issues
When a routing protocol has been enabled on an interface, and the interface is not configured as a passive interface, the routing protocol attempts to discover neighbors and form a neighbor relationship with each neighbor that shares the common subnet.
OSPF and EIGRP both use Hello messages to learn about new neighbors and to exchange information used to perform some basic verification checks. After an EIGRP or OSPF router hears a Hello from a new neighbor, the routing protocol examines the information in the Hello, along with some local settings, to decide if the two neighbors should even attempt to become neighbors. Table 11-2 lists the neighbor requirements for both EIGRP and OSPF.
Any two EIGRP routers that connect to the same data link, and whose interfaces have been enabled for EIGRP and are not passive, will at least consider becoming neighbors. To quickly and definitively know which potential neighbors have passed all the neighbor requirements for EIGRP, look at the output of the show ip eigrp neighbors command. If one or more expected neighbors are not listed, and the two routers can ping each other’s IP address on their common subnet, the problem is probably related to one of the neighbor requirements listed in Table 11-2. Table 11-3 summarizes the EIGRP neighbor requirements and notes the best commands with which to determine which requirement is the root cause of the problem.
Similar to EIGRP, the show ip ospf neighbor command lists all the neighboring routers that have met all the requirements to become an OSPF neighbor as listed in Table 11-2.
If one or more expected neighbors exist, before moving on to look at OSPF neighbor requirements, you should confirm that the two routers can ping each other on the local subnet. As soon as the two neighboring routers can ping each other, if the two routers still do not become OSPF neighbors, the next step is to examine each of the OSPF neighbor requirements. Table 11-4 summarizes the requirements, listing the most useful commands with which to find the answers.
