Day 12. Troubleshooting Routing

Figure 12-1 Major Steps in Routing

The first three steps in the figure show how to route a packet over an internetwork; however, most applications require packet flow in both directions. So, when you are troubleshooting, any analysis of normal operations should also consider the packet that will be sent back to the first host, as shown in Steps 4, 5, and 6 in the figure.

Most traffic in today’s networks is sent to remote destinations. The routers between source and destination operate independently of each other using the following logic:

Step 1 For each received data-link frame, choose whether to process the frame. Process it if

a. The frame has no errors (per the data-link trailer frame check sequence or FCS field)

b. The frame’s destination data-link address is the router’s address (or an appropriate multicast or broadcast)

Step 2 If choosing to process the frame at Step 1, de-encapsulate the packet from inside the data-link frame.

Step 3 Make a routing decision. Compare the packet’s destination IP address to the routing table and find the route that matches the destination address. This route identifies the outgoing interface.

Step 4 Encapsulate the packet into a data-link frame appropriate for the outgoing interface.

Step 5 Transmit the frame out the outgoing interface, as listed in the matched IP route.

If the router does not have a route to the destination or a gateway of last resort set, the router drops the packet. Issues with routing are most likely due to the specific operation of the routing protocol or static routing configuration.

1. The router sends and receives routing messages on its interfaces.

2. The router shares routing messages and routing information with other routers that are using the same routing protocol.

3. Routers exchange routing information to learn about remote networks.

4. When a router detects a topology change, the routing protocol can advertise this change to other routers.

At any of the steps, a configuration issue might arise that requires resolution.

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, you can use the following method for issues related to routing:

1. 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.

2. 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:

Enabled 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.

Passive interface(s): An interface that should be sending and receiving updates could be configured as passive.

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. 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.

The “go to” command for troubleshooting routing is show ip route. Refer to Figure 12-2 and Table 12-1 to review the important details of the show ip route command.

Figure 12-2 Example Output for the show ip route Command

Table 12-1 Descriptions of the Output for the show ip route Command

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 the ping and traceroute commands.