- Objectives
- Key Terms
- Introduction (2.0.1.1)
- Static Routing Implementation (2.1)
- Configure Summary and Floating Static Routes (2.4)
- Troubleshoot Static and Default Route Issues (2.5)
- Summary (2.6)
- Practice
- Check Your Understanding Questions
Troubleshoot Static and Default Route Issues (2.5)
Now that you have learned how to configure different types of static routes, this section discusses how to troubleshoot some of the common problems you might encounter. Troubleshooting exercises are an excellent method to help better understand network protocols and configurations. When a static route is no longer needed, that static route should be deleted from the running and startup configuration files.
Packet Processing with Static Routes (2.5.1)
Now that you have configured static routes, you need to learn about the process that a packet goes through as it is forwarded by a router.
Static Routes and Packet Forwarding (2.5.1.1)
The following example describes the packet forwarding process with static routes.
Examine Figure 2-69, where PC1 is sending a packet to PC3:
- The packet arrives on the FastEthernet 0/0 interface of R1.
- R1 does not have a specific route to the destination network, 192.168.2.0/24; therefore, R1 uses the default static route.
- R1 encapsulates the packet in a new frame. Because the link to R2 is a point-to-point link, R1 adds an “all 1s” address for the Layer 2 destination address.
- The frame is forwarded out of the Serial 0/0/0 interface. The packet arrives on the Serial 0/0/0 interface on R2.
- R2 de-encapsulates the frame and looks for a route to the destination. R2 has a static route to 192.168.2.0/24 out of the Serial 0/0/1 interface.
- R2 encapsulates the packet in a new frame. Because the link to R3 is a point-to-point link, R2 adds an “all 1s” address for the Layer 2 destination address.
- The frame is forwarded out of the Serial 0/0/1 interface. The packet arrives on the Serial 0/0/1 interface on R3.
- R3 de-encapsulates the frame and looks for a route to the destination. R3 has a connected route to 192.168.2.0/24 out of the FastEthernet 0/0 interface.
- R3 looks up the ARP table entry for 192.168.2.10 to find the Layer 2 Media Access Control (MAC) address for PC3. If no entry exists, R3 sends an Address Resolution Protocol (ARP) request out of the FastEthernet 0/0 interface, and PC3 responds with an ARP reply, which includes the PC3 MAC address.
- R3 encapsulates the packet in a new frame with the MAC address of the FastEthernet 0/0 interface as the source Layer 2 address and the MAC address of PC3 as the destination MAC address.
The frame is forwarded out of the FastEthernet 0/0 interface. The packet arrives on the network interface card (NIC) interface of PC3.
Figure 2-69 Static Routes and Packet Forwarding
Troubleshoot IPv4 Static and Default Route Configuration (2.5.2)
Troubleshooting is a skill that develops as you gain experience. It is always best to look for the most obvious and simplest issues first, such as an interface still in shutdown mode or an interface with the wrong IP address. After these items have been verified, begin looking for more complicated possibilities like an error in the static route configuration.
Troubleshooting a Missing Route (2.5.2.1)
When end-to-end connectivity is a problem, begin by making sure that you can ping your own interface and other devices on your own directly connected networks. When this has been verified, begin testing connectivity to remote networks from other devices.
Networks are subject to forces that can cause their status to change quite often:
- An interface fails.
- A service provider drops a connection.
- Links become oversaturated.
- An administrator enters a wrong configuration.
When there is a change in the network, connectivity may be lost. Network administrators are responsible for pinpointing and solving the problem. To find and solve these issues, a network administrator must be familiar with tools to help isolate routing problems quickly.
Common IOS troubleshooting commands include:
- ping
- traceroute
- show ip route
- show ip interface brief
- show cdp neighbors detail
Figure 2-70 displays the result of an extended ping from the source interface of R1 to the LAN interface of R3. An extended ping is when the source interface or source IP address is specified.
Figure 2-70 Extended Ping
The following output displays the result of a traceroute from R1 to the R3 LAN:
R1# traceroute 192.168.2.1 Type escape sequence to abort. Tracing the route to 192.168.2.1 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.2.2 4 msec 4 msec 8 msec 2 192.168.1.1 12 msec 12 msec * R1#
The following output displays the routing table of R1:
R1# show ip route | begin Gateway Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks S 172.16.1.0/24 [1/0] via 172.16.2.2 C 172.16.2.0/24 is directly connected, Serial0/0/0 L 172.16.2.1/32 is directly connected, Serial0/0/0 C 172.16.3.0/24 is directly connected, GigabitEthernet0/0 L 172.16.3.1/32 is directly connected, GigabitEthernet0/0 S 192.168.1.0/24 [1/0] via 172.16.2.2 S 192.168.2.0/24 [1/0] via 172.16.2.2 R1#
The following output provides a quick status of all interfaces on the router:
R1# show ip interface brief Interface IP-Address OK? Method Status Protocol Embedded-Service-Engine0/0 unassigned YES unset administratively down down GigabitEthernet0/0 172.16.3.1 YES manual up up GigabitEthernet0/1 unassigned YES unset administratively down down Serial0/0/0 172.16.2.1 YES manual up up Serial0/0/1 unassigned YES unset administratively down down R1#
The show cdp neighbors command in the following output provides a list of directly connected Cisco devices. This command validates Layer 2 (and therefore Layer 1) connectivity. For example, if a neighbor device is listed in the command output, but it cannot be pinged, then Layer 3 addressing should be investigated.
R1# show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, D - Remote, C - CVTA, M - Two-port Mac Relay Device ID Local Intrfce Holdtme Capability Platform Port ID netlab-cs5 Gig 0/0 156 S I WS-C2960- Fas 0/1 R2 Ser 0/0/0 153 R S I CISCO1941 Ser 0/0/0 R1#
Solve a Connectivity Problem (2.5.2.2)
Finding a missing (or misconfigured) route is a relatively straightforward process, if the right tools are used in a methodical manner.
For instance, in this example, the user at PC1 reports that he cannot access resources on the R3 LAN. This can be confirmed by pinging the LAN interface of R3 using the LAN interface of R1 as the source (see Figure 2-71). The results show that there is no connectivity between these LANs.
Figure 2-71 Verify Connectivity to the R3 LAN
A traceroute in the following output reveals that R2 is not responding as expected. For some reason, R2 forwards the traceroute back to R1. R1 returns it to R2. This loop would continue until the time to live (TTL) value decrements to zero, in which case, the router would then send an Internet Control Message Protocol (ICMP) Destination Unreachable message to R1.
R1# traceroute 192.168.2.1 Type escape sequence to abort. Tracing the route to 192.168.2.1 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.2.2 4 msec 4 msec 8 msec 2 172.16.2.1 12 msec 12 msec 12 msec 3 172.16.2.2 12 msec 8 msec 8 msec 4 172.16.2.1 20 msec 16 msec 20 msec 5 172.16.2.2 16 msec 16 msec 16 msec 6 172.16.2.1 20 msec 20 msec 24 msec 7 172.16.2.2 20 msec R1#
The next step is to investigate the routing table of R2, because it is the router displaying a strange forwarding pattern. Using the show ip route | begin Gateway command, the routing table in the following output reveals that the 192.168.2.0/24 network is configured incorrectly. A static route to the 192.168.2.0/24 network has been configured using the next-hop address 172.16.2.1. Using the configured next-hop address, packets destined for the 192.168.2.0/24 network are sent back to R1. It is clear from the topology that the 192.168.2.0/24 network is connected to R3, not R1. Therefore, the static route to the 192.168.2.0/24 network on R2 must use next-hop 192.168.1.1, not 172.16.2.1.
R2# show ip route | begin Gateway Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks C 172.16.1.0/24 is directly connected, GigabitEthernet0/0 L 172.16.1.1/32 is directly connected, GigabitEthernet0/0 C 172.16.2.0/24 is directly connected, Serial0/0/0 L 172.16.2.2/32 is directly connected, Serial0/0/0 S 172.16.3.0/24 1/0] via 172.16.2.1 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.0/24 is directly connected, Serial0/0/1 L 192.168.1.2/32 is directly connected, Serial0/0/1 S 192.168.2.0/24 [1/0] via 172.16.2.1 R2#
The following shows output from the running configuration that reveals the incorrect ip route statement. The incorrect route is removed and the correct route is then entered.
R2# show running-config | section ip route ip route 172.16.3.0 255.255.255.0 172.16.2.1 ip route 192.168.2.0 255.255.255.0 172.16.2.1 R2# R2# conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)# no ip route 192.168.2.0 255.255.255.0 172.16.2.1 R2(config)# ip route 192.168.2.0 255.255.255.0 192.168.1.1 R2(config)#
The following output verifies that R1 can now reach the LAN interface of R3. As a last step in confirmation, the user on PC1 should also test connectivity to the 192.168.2.0/24 LAN.
R1# ping 192.168.2.1 source g0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: Packet sent with a source address of 172.16.3.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/28 ms R1#