Troubleshooting Static Routes


Followers of the assorted American political scandals of the past 30 or so years will have heard a congressional investigator ask the question, "What did he know and when did he know it?" The same question serves a networking investigator well. When troubleshooting routing problems, the first step should almost always be to examine the route table. What does the router know? How long has the information been in the route table? Does the router know how to reach the destination in question? Is the information in the route table accurate? Knowing how to trace a route is essential to successfully troubleshooting a network.

Case Study: Tracing a Failed Route

Figure 3-9 shows a previously configured network, with each router's associated static routes. A problem has been discovered. Devices on subnet 192.168.1.0/27, connected to Pooh's Ethernet interface, can communicate with devices on subnet 10.1.0.0/16 just fine. However, when a ping is sent from Pooh itself to subnet 10.1.0.0/16, the ping fails (see Example 3-36). This seems strange. If packets being routed by Pooh successfully reach their destinations, why do packets originated by the same router fail?

Figure 3-9. Packets from subnet 192.168.1.0/27 to subnet 10.1.0.0/16 are routed correctly, but Pooh itself cannot ping any device on 10.1.0.0/16.


Example 3-36. A device on subnet 192.168.1.0/27 successfully pings Piglet's Ethernet interface, but pings from Pooh fail.
C:\WINDOWS>ping 10.1.5.1 Pinging 10.1.5.1 with 32 bytes of data: Reply from 10.1.5.1: bytes=32 time=22ms TTL=253 Reply from 10.1.5.1: bytes=32 time=22ms TTL=253 Reply from 10.1.5.1: bytes=32 time=22ms TTL=253 Reply from 10.1.5.1: bytes=32 time=22ms TTL=253 Pooh#ping 10.1.5.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoechoes to 10.1.5.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Pooh#

Addressing this problem requires tracing the route of the ping. First, Pooh's route table is examined (Example 3-37). The destination address of 10.1.5.1 matches the route entry for 10.0.0.0/8, which (according to the table) is reached via the next-hop address 192.168.1.34one of Eeyore's interfaces.

Example 3-37. A packet with a destination address of 10.1.5.1 matches the route entry for 10.0.0.0/8 and will be forwarded to the next-hop router at 192.168.1.34.
Pooh#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set      10.0.0.0 is variably subnetted, 2 subnets, 2 masks S      10.0.0.0 255.0.0.0 [1/0] via 192.168.1.34 S      10.4.7.25 255.255.255.255 [1/0] via 192.168.1.66      192.168.1.0 255.255.255.224 is subnetted, 4 subnets C      192.168.1.64 is directly connected, Serial0 C      192.168.1.32 is directly connected, Serial1 C      192.168.1.0 is directly connected, Ethernet0 S      192.168.1.192 [1/0] via 192.168.1.66 Pooh#

Next the route table for Eeyore must be examined (Example 3-38). The destination address 10.1.5.1 matches the entry 10.1.0.0/16, with a next-hop address of 10.4.6.1. This address is one of Tigger's interfaces.

Example 3-38. 10.1.5.1 matches the entry for 10.1.0.0/16 and will be forwarded to 10.4.6.1.
Eeyore#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set       10.0.0.0 is variably subnetted, 3 subnets, 2 masks C       10.4.6.0 255.255.255.0 is directly connected, Serial1 C       10.4.7.0 255.255.255.0 is directly connected, Ethernet0 S       10.1.0.0 255.255.0.0 [1/0] via 10.4.6.1       192.168.1.0 255.255.255.224 is subnetted, 1 subnets C       192.168.1.32 is directly connected, Serial0 S       192.0.0.0 255.0.0.0 [1/0] via 10.4.6.1 Eeyore#

Example 3-39 shows Tigger's route table. The destination address matches the entry for 10.1.0.0/16 and will be forwarded to 192.168.1.194, which is at Piglet.

Example 3-39. 10.1.5.1 matches the entry for 10.1.0.0/16 and will be forwarded to 192.168.1.194.
Tigger#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set      10.0.0.0 is variably subnetted, 3 subnets, 2 masks C      10.4.6.0 255.255.255.0 is directly connected, Serial1 S      10.4.7.0 255.255.255.0 [1/0] via 10.4.6.2 S      10.1.0.0 255.255.0.0 [1/0] via 192.168.1.194      192.168.1.0 255.255.255.224 is subnetted, 3 subnets C      192.168.1.64 is directly connected, Serial0 S      192.168.1.0 [1/0] via 192.168.1.65 C      192.168.1.192 is directly connected, Ethernet0 Tigger#

Piglet's route table (Example 3-40) reveals that the target network, 10.1.0.0, is directly connected. In other words, the packet has arrived. The target address 10.1.5.1 is Piglet's own interface to that network. Because the path to the address has just been verified as good, we can assume that the ICMP echo packets from Pooh are reaching the destination.

Example 3-40. The destination network, 10.1.0.0, is directly connected to Piglet.
Piglet#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set      10.0.0.0 255.255.0.0 is subnetted, 2 subnets C      10.1.0.0 is directly connected, Ethernet1 S      10.4.0.0 [1/0] via 192.168.1.193      192.168.1.0 is variably subnetted, 2 subnets, 2 masks S      192.168.1.0 255.255.255.0 [1/0] via 192.168.1.193 C      192.168.1.192 255.255.255.224 is directly connected, Ethernet0 Piglet#

The next step is to trace the path of the responding ICMP echo reply packets. To trace this path, you need to know the source address of the echo packet. That address will be the destination address of the echo reply packet. The source address of a packet that is originated from a router is the address of the interface from which the packet was transmitted.[7] In this example, Pooh originally forwarded the echo packet to 192.168.1.34. Figure 3-9 shows that the source address of that packet is 192.168.1.33. So this address is the destination address to which Piglet will send the echo reply.

[7] Unless the Extended Ping utility is used to set the source address to something different.

Referring again to Piglet's route table in Example 3-34, 192.168.1.33 will match the entry for 192.168.1.0/24 and be forwarded to 192.168.1.193, which is another of Tigger's interfaces. A re-examination of Tigger's route table in Example 3-39 at first suggests that there is an entry for 192.168.1.0. But take care to interpret correctly the information that is actually there.

Compare the entries in Tigger's route table for the 10.0.0.0 subnets to those of the 192.168.1.0 subnets. The heading for the former says that 10.0.0.0 is variably subnetted; in other words, Tigger's static route to subnet 10.4.7.0 uses a 24-bit mask, and the static route to subnet 10.1.0.0 uses a 16-bit mask. The table records the correct mask at each subnet.

The heading for 192.168.1.0 is different. This heading states that Tigger knows of three subnets of 192.168.1.0 and that they all have a mask of 255.255.255.224. This mask will be used on the destination address of 192.168.1.33 to derive a destination network of 192.168.1.32/27. The route table has entries for 192.168.1.64/27, 192.168.1.0/27, and 192.168.1.192/27. There is no entry for 192.168.1.32/27, so the router does not know how to reach this subnet.

The problem, then, is that the ICMP echo reply packet is being dropped at Tigger. One solution is to create another static route entry for network 192.168.1.32, with a mask of 255.255.255.224 and pointing to a next hop of either 192.168.1.65 or 10.4.6.2. Another solution would be to change the mask in the existing static route entry for 192.168.1.0 from 255.255.255.224 to 255.255.255.0.

The moral of this story is that when you are tracing a route, you must consider the complete communication process.

Note

Check both the destination and return path when a route fails.


Verify not only that the path to a destination is good but also that the return path is good.

Case Study: A Protocol Conflict

Figure 3-10 shows two routers connected by two Ethernet networks, one of which includes a simple bridge. This bridge handles traffic for several other links not shown and occasionally becomes congested. The host Milne is a mission-critical server; the network administrator is worried about traffic to Milne being delayed by the bridge, so a static host route has been added in Roo that will direct packets destined for Milne across the top Ethernet, avoiding the bridge.

Figure 3-10. A host route directs packets from Roo to Milne across the top Ethernet, avoiding the occasionally congested bridge.


This solution seems to be logical, but it isn't working. After the static route was added, packets routed through Roo no longer reach the server. Not only that, but packets routed through Kanga no longer reach the server, although no changes were made to that router.

The first step, as always, is to check the route table. Roo's route table (Example 3-41) indicates that packets with a destination address of 172.16.20.75 will, in fact, be forwarded to Kanga's E1 interface, as desired. Kanga is directly connected to the destination network, so no more routing should be occurring; a quick check verifies that the Ethernet interfaces are functioning at both Kanga and at Milne.

Example 3-41. Roo's route table, showing the static host route to Milne via Kanga's E1 interface.
Roo#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default,        U - per-user static route Gateway of last resort is not set      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks C       172.16.20.0/24 is directly connected, Ethernet0 C       172.16.21.0/24 is directly connected, Ethernet1 S       172.16.20.75/32 [1/0] via 172.16.21.2 Roo#

In Example 3-42, a trace is performed from Roo to Milne, and a symptom is found. Instead of delivering the packets to Milne, Kanga is forwarding them to Roo's E0 interface. Roo forwards the packets to Kanga's E1 interface, and Kanga sends the packets right back to Roo. A routing loop seems to have occurred, but why?

Example 3-42. A trace from Roo to Milne reveals that Kanga is forwarding the packets back to Roo instead of delivering them to the correct destination.
Roo#trace 172.16.20.75 Type escape sequence to abort. Tracing the route to 172.16.20.75 1 172.16.21.2 0 msec 0 msec 0 msec 2 172.16.20.1 4 msec 0 msec 0 msec 3 172.16.21.2 4 msec 0 msec 0 msec 4 172.16.20.1 0 msec 0 msec 4 msec 5 172.16.21.2 0 msec 0 msec 4 msec 6 172.16.20.1 0 msec 0 msec 4 msec 7 172.16.21.2 0 msec 0 msec 4 msec 8 172.16.20.1 0 msec 0 msec 4 msec 9 172.16.21.2 4 msec 0 msec 4 msec 10 172.16.20.1 4 msec 0 msec 4 msec 11 172.16.21.2 4 msec Roo#

The suspicious aspect of all of this is that Kanga should not be routing the packet, which appears to be the case.

Kanga should recognize that the destination address of the packet is for its directly connected network 172.16.20.0 and should be using the data link to deliver the packet to the host. Therefore, suspicion should fall on the data link. Just as the route table should be examined to see whether the router has the correct information for reaching a network across a logical path, the ARP cache should be examined to see whether the router has the correct information for reaching a host across a physical path.

Example 3-43 shows the ARP cache for Kanga. The IP address for Milne is in Kanga's cache as expected, with a MAC identifier of 00e0.1e58.dc39. When Milne's interface is checked, though, it shows that it has a MAC identifier of 0002.6779.0f4c; Kanga has somehow acquired incorrect information.

Example 3-43. Kanga's ARP cache has an entry for Milne, but the associated data-link identifier is wrong.
Kanga#show arp Protocol Address     Age (min)  Hardware Addr   Type  Interface Internet 172.16.21.1         2  00e0.1e58.dc3c  ARPA  Ethernet1 Internet 172.16.20.2         -  00e0.1e58.dcb1  ARPA  Ethernet0 Internet 172.16.21.2         -  00e0.1e58.dcb4  ARPA  Ethernet1 Internet 172.16.20.75        2  00e0.1e58.dc39  ARPA  Ethernet0 Kanga#

Another look at Kanga's ARP table reveals that the MAC identifier associated with Milne is suspiciously similar to the MAC identifier of Kanga's own Cisco interfaces. (The MAC addresses with no ages associated with them are for the router's interfaces.) Because Milne is not a Cisco product, the first three octets of its MAC identifier should be different from the first three octets of Kanga's MAC identifier. The only other Cisco product in the network is Roo, so its ARP cache is examined (Example 3-44); 00e0.1e58.dc39 is the MAC identifier of Roo's E0 interface.

Example 3-44. Roo's ARP cache shows that the MAC identifier that Kanga has for Milne is actually Roo's E0 interface.
Roo#show arp Protocol Address     Age (min)  Hardware Addr    Type   Interface Internet 172.16.21.1        -   00e0.1e58.dc3c   ARPA   Ethernet0 Internet 172.16.20.1        -   00e0.1e58.dc39   ARPA   Ethernet0 Internet 172.16.20.2        7   00e0.1e58.dcb1   ARPA   Ethernet0 Internet 172.16.21.2        7   00e0.1e58.dcb4   ARPA   Ethernet1 Roo#

So Kanga mistakenly believes that the E0 interface of Roo is Milne. It frames packets destined for Milne with a destination identifier of 00e0.1e58.dc39; Roo accepts the frame, reads the destination address of the enclosed packet, and routes the packet back to Kanga.

But how did Kanga get the wrong information? The answer is proxy ARP. When Kanga first receives a packet for Milne, it will use ARP to determine that device's data-link identifier. Milne responds, but Roo also hears the ARP request on its E0 interface. Because Roo has a route to Milne on a different network from the one on which it received the ARP Request, it issues a proxy ARP in reply. Kanga receives Milne's ARP reply and enters it into the ARP cache. The proxy ARP reply from Roo arrives later because of the delay of the bridge. The original ARP cache entry is overwritten by what Kanga thinks is new information.

There are two solutions to the problem. The first is to turn off proxy ARP at Roo's E0 with the following command sequence:

Roo(config)#interface e0 Roo(config-if)#no ip proxy-arp

The second solution is to configure a static ARP entry for Milne at Kanga with the following command:

Kanga(config)#arp 172.16.20.75 0002.6779.0f4c arpa

This entry will not be overwritten by any ARP reply. Example 3-45 shows the static ARP entry being entered and the resulting ARP cache at Kanga. Note that because the entry is static, no age is associated with it.

Example 3-45. A static ARP entry on Kanga corrects the problem caused by proxy ARP.
Kanga(config)#arp 172.16.20.75 0002.6779.0f4c arpa Kanga(config)#^Z Kanga# %SYS-5-CONFIG_I: Configured from console by console Kanga#show arp Protocol Address     Age (min)   Hardware Addr    Type   Interface Internet 172.16.21.1        10   00e0.1e58.dc3c   ARPA   Ethernet1 Internet 172.16.20.2         -   00e0.1e58.dcb1   ARPA   Ethernet0 Internet 172.16.21.2         -   00e0.1e58.dcb4   ARPA   Ethernet1 Internet 172.16.20.75        -   0002.6779.0f4c   ARPA Kanga#

The circumstances of the network should help determine which of the two solutions is best. A static ARP entry means that if the network interface at Milne is ever replaced, someone must remember to change the ARP entry to reflect the new MAC identifier. On the other hand, turning off proxy ARP is a good solution only if no hosts make use of it.

Case Study: A Replaced Router

Figure 3-11 shows two routers, Honeypot and Honeybee, connected via a Frame Relay link. The routers are configured for both IPv4 and IPv6, and use static routes to create the route tables.

Figure 3-11. A simple network with both IPv4 and IPv6.


Example 3-46 shows the route configurations for Honeypot and Example 3-47 shows the route configurations for Honeybee.

Example 3-46. Route configurations for Honeypot.
ip route 10.4.0.0 255.255.0.0 192.168.1.193 ip route 192.168.1.0 255.255.255.0 192.168.1.193 ipv6 route FEC0::/62 Serial 0/0.2 ipv6 route FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0

Example 3-47. Route configurations for Honeybee.
ip route 10.1.0.0 255.255.0.0 192.168.1.194 ipv6 route FEC0:0:0:5::/64 Serial 0/0.1

Example 3-48 shows pings and traces between the two routers are working fine. Both IPv4 and IPv6 traffic is working fine between the two sites.

Example 3-48. Pings and traces show two routers can successfully communicate with each other.
Honeypot#ping Protocol [ip]: Target IP address: 10.4.8.1 Extended commands [n]: y Source address or interface: 10.1.5.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.4.8.1, timeout is 2 seconds: Packet sent with a source address of 10.1.5.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/33 ms Honeypot#ping fec0:0:0:8:204:c1ff:fe50:f1c0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FEC0::8:204:C1FF:FE50:F1C0, timeout is 2 secon ds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/33 ms Honeypot#trace Protocol [ip]: ipv6 Target IPv6 address: fec0:0:0:8:204:c1ff:fe50:f1c0 Source address: fec0:0:0:5:230:94ff:fe24:b780 Type escape sequence to abort. Tracing the route to FEC0::8:204:C1FF:FE50:F1C0   1 FEC0::3:204:C1FF:FE50:F1C0 24 msec 24 msec 24 msec Honeypot#trace Protocol [ip]: ipv6 Target IPv6 address: fec0::a:0:0:0:1 Source address: fec0::5:230:94ff:fe24:b780 Type escape sequence to abort. Tracing the route to FEC0:0:0:A::1  1 FEC0::3:204:C1FF:FE50:F1C0 24 msec 24 msec 24 msec

Honeypot can reach Honeybee's Ethernet address from its own Ethernet address, for both IPv4 and IPv6. Another address, FEC0:0:0:A::1, is also reachable from Honeypot, via Honeybee.

Honeybee, however, is due to be replaced with a new router. The router is replaced, Honeybee's configuration is loaded into the new router, and all the interfaces are up. Testing shows that IPv4 traffic is working between the two sites, but IPv6 traffic to some addresses fails (see Example 3-49).

Example 3-49. After a router replacement, IPv4 works fine, while IPv6 fails.
Honeypot#ping Protocol [ip]: Target IP address: 10.4.8.1 Extended commands [n]: y Source address or interface: 10.1.5.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.4.8.1, timeout is 2 seconds: Packet sent with a source address of 10.1.5.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms Honeypot#ping fec0:0:0:8:204:c1ff:fe50:f1c0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FEC0::8:204:C1FF:FE50:F1C0, timeout is 2 seconds: ...H. Success rate is 0 percent (0/5) Honeypot#trace Protocol [ip]: ipv6 Target IPv6 address: fec0::8:204:c1ff:fe50:f1c0 Source address: fec0::5:230:94ff:fe24:b780 Type escape sequence to abort. Tracing the route to FEC0::8:204:C1FF:FE50:F1C0   1 FEC0::3:2B0:64FF:FE30:1DE0 24 msec 24 msec 24 msec   2  *  !H  * Honeypot#trace Protocol [ip]: ipv6 Target IPv6 address: fec0::a:0:0:0:1 Source address: fec0::5:230:94ff:fe24:b780 Type escape sequence to abort. Tracing the route to FEC0:0:0:A::1  1 FEC0::3:2B0:64FF:FE30:1DE0 24 msec 20 msec 20 msec

Pings and traces to the IPv6 address FEC0::8:204:c1FF:FE50:F1C0, Honeybee's Ethernet IPv6 address, fail. A trace to FEC0::A:0:0:0:1 is still successful.

Take a look at Honeypot's route tables in Example 3-50. Honeypot's IPv6 route table shows a static route entry for FEC0:0:0:8::/62 via the next-hop address FEC0::3:204:C1FF:FE50:F1C0.

Example 3-50. The IPv6 route table has not changed. Static route are installed.
Honeypot#show ipv6 route IPv6 Routing Table - 8 entries L   FE80::/10 [0/0]      via ::, Null0 S   FEC0::/62 [1/0]      via ::, Serial0/0.2 C   FEC0:0:0:3::/64 [0/0]      via ::, Serial0/0.2 L   FEC0::3:230:94FF:FE24:B780/128 [0/0]      via ::, Serial0/0.2 C   FEC0:0:0:5::/64 [0/0]      via ::, Ethernet0/0 L   FEC0::5:230:94FF:FE24:B780/128 [0/0]      via ::, Ethernet0/0 S   FEC0:0:0:8::/62 [1/0]      via FEC0::3:204:C1FF:FE50:F1C0

FEC0:0:0:8::/62 is known via FEC0::3:204:C1FF:FE50:F1C0, and FEC0:0:0:3::/64 is connected to Serial0/0.2. Traffic for both FEC0:0:0:8::/64 and FEC0:0:0:A::/64 are forwarded out Serial 0/0.2 to Honeybee.

These route entries are exactly the same as they were before the router Honeybee was replaced. So what's the problem? Maybe Honeybee's Ethernet didn't come up after the router was replaced. Example 3-51 displays the state of Honeybee's Ethernet interface.

Example 3-51. show ipv6 interface ethernet 0/0 displays the status of the interface and some information about the IPv6 configuration.
Honeybee#show ipv6 interface e 0/0 Ethernet0/0 is up, line protocol is up   IPv6 is enabled, link-local address is FE80::2B0:64FF:FE30:1DE0   Global unicast address(es):     FEC0::8:2B0:64FF:FE30:1DE0, subnet is FEC0:0:0:8::/64   Joined group address(es):     FF02::1     FF02::2     FF02::1:FF30:1DE0

The interface is up and IPv6 is configured on it. According to the documentation and diagrams for the network, this is the interface to which a ping was successful before the router replacement, and now fails.

Look closer at the Ethernet output. The last 64 bits of the Global Unicast Address have changed. The address is now FEC0::8:2B0:64FF:FE30:1DE0. The IPv6 address is an EUI-64 address; therefore, the last 64 bits of the address are determined by the MAC address on the interface. When the router was replaced, the MAC address changed. FEC0::8:204:C1FF:FE50:F1C0 no longer exists on the router. This is why the address is no longer pingable.

But, Honeypot's static route points to the next-hop address FEC0::3:204:c1FF:FE50:F1C0 for the destination FEC0:0:0:8::/62, according to the route table (Example 3-50), and if the MAC addresses have changed, this address is no longer the serial interface's address. Example 3-52 displays Honeybee's new serial interface address.

Example 3-52. All IPv6 serial interfaces on a router configured with EUI-64 addresses will have the same final 64 bits, which are derived from a MAC address on the router.
Honeybee#show ipv6 interface serial0/0.1 Serial0/0.1 is up, line protocol is up   IPv6 is enabled, link-local address is FE80::2B0:64FF:FE30:1DE0   Description: Link to Piglet   Global unicast address(es):     FEC0::3:2B0:64FF:FE30:1DE0, subnet is FEC0:0:0:3::/64   Joined group address(es):     FF02::1     FF02::2     FF02::1:FF30:1DE0

Honeypot's IPv6 static route for addresses in the range FEC0:0:0:8::/62 directs traffic to the next-hop address FEC0::3:204:C1FF:FE50:F1C0. The configured next-hop address is the MAC address of the old router, yet traffic using this route (traffic destined to FEC0:0:0:A::1) is still routed successfully.

Even though a next-hop address is specified, and the next-hop address is not valid anymore, the old address and the new address of Honeybee's serial interface belong to the same subnet (FEC0:0:0:3::/64), and as seen in Honeypot's route table, this subnet is connected to Honeypot's interface Serial 0/0.2. Through recursive forwarding table lookups, the traffic destined for FEC0:0:0:A::1 is forwarded out Serial 0/0.2, even though the specified next-hop address does not exist.

Whenever a router or interface card is replaced, remember to modify any static route entries that reference an EUI-64 IPv6 address on the old router.

Case Study: Tracing An IPv6 Failed Route

A link is added to the network in Figure 3-3 between Honeypot and Honeytree to have an alternative route in case the primary route becomes unavailable. Figure 3-12 shows the new network. The IPv6 applications using the network are not sensitive to delay, but they are bandwidth-intensive, so the network administrator decides to use the new link also for load sharing. Static routes are entered in each router to take advantage of the new link.

Figure 3-12. Alternative route added to the IPv6 network creates a triangle, with alternate paths to reach each router.


As Example 3-53 shows, routes are added into Honeypot to create a second route for each of the router's existing routes. Similar routes are entered for Honeytree and Honeybee in Example 3-54 and Example 3-55.

Example 3-53. Honeypot's router configurations for the new network in Figure 3-12.
ipv6 route FEC0::/62 FEC0::2:2B0:64FF:FE30:1DE0 ipv6 route FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 ipv6 route FEC0:0:0:8::/62 FEC0::2:2B0:64FF:FE30:1DE0 ipv6 route FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0

Example 3-54. Honeytree's router configurations for the new network in Figure 3-12.
ipv6 route FEC0:0:0:3::/64 FEC0::2:230:94FF:FE24:B780 ipv6 route FEC0:0:0:3::/64 FEC0::1:204:C1FF:FE50:F1C0 ipv6 route FEC0:0:0:5::/64 FEC0::2:230:94FF:FE24:B780 ipv6 route FEC0:0:0:5::/64 FEC0::1:204:C1FF:FE50:F1C0 ipv6 route FEC0:0:0:8::/64 FEC0::1:204:C1FF:FE50:F1C0 ipv6 route FEC0:0:0:8::/64 FEC0::2:230:94FF:FE24:B780

Example 3-55. Honeybee's router configurations for the new network in Figure 3-12.
ipv6 route FEC0:0:0:2::/64 FEC0::1:2B0:64FF:FE30:1DE0 ipv6 route FEC0:0:0:2::/64 FEC0::3:230:94FF:FE24:B780 ipv6 route FEC0:0:0:5::/64 FEC0::1:2B0:64FF:FE30:1DE0 ipv6 route FEC0:0:0:5::/64 FEC0::3:230:94FF:FE24:B780 ipv6 route FEC0:0:0:B::/64 FEC0::3:230:94FF:FE24:B780 ipv6 route FEC0:0:0:B::/64 FEC0::1:2B0:64FF:FE30:1DE0

IPv6 routing is now intermittently failing. Sometimes pings work, sometimes not. A look at the route tables shows all static routes in place as designed. Pings from Honeypot to Honeybee's Ethernet interface address result in success sometimes, and host unreachable at other times (see Example 3-56).

Example 3-56. IPv6 pings are sometimes successful.
Honeypot#ping fec0::8:204:c1ff:fe50:f1c0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FEC0::8:204:C1FF:FE50:F1C0, timeout is 2 secon ds: !!HHH Success rate is 40 percent (2/5), round-trip min/avg/max = 60/90/120 ms Honeypot#

Debugging IPv6 ICMP packets on Honeypot (see Example 3-57) reveal some reply packets received successfully, and some ICMP destination unreachable messages coming from Honeytree.

Example 3-57. Debugging on Honeypot shows some successful packets; others fail.
ICMPv6: Sending echo request to FEC0::8:204:C1FF:FE50:F1C0 ICMPv6: Received ICMPv6 packet from FEC0::8:204:C1FF:FE50:F1C0, type 129 ICMPv6: Received echo reply from FEC0::8:204:C1FF:FE50:F1C0 ICMPv6: Sending echo request to FEC0::8:204:C1FF:FE50:F1C0 ICMPv6: Received ICMPv6 packet from FEC0::2:2B0:64FF:FE30:1DE0, type 1 ICMPv6: Received ICMP unreachable code 3 from FEC0::2:2B0:64FF:FE30:1DE0

Debugging ICMPv6 on Honeytree (see Example 3-58) shows that IPv6 packets are coming in S0/0.3 and S0/0.2.

Example 3-58. Debugging shows packets arriving on two different interfaces.
Honeytree#  IPV6: source FEC0::2:230:94FF:FE24:B780 (Serial0/0.3)        dest FEC0::8:204:C1FF:FE50:F1C0 (Serial0/0.2)        traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, forwarding  IPV6: source FEC0::8:204:C1FF:FE50:F1C0 (Serial0/0.2)        dest FEC0::2:230:94FF:FE24:B780 (Serial0/0.3)        traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, forwarding  IPV6: source FEC0::2:230:94FF:FE24:B780 (Serial0/0.3)        dest FEC0::8:204:C1FF:FE50:F1C0 (Serial0/0.3)        traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, destination is not connected  IPv6: SAS picked source FEC0::2:2B0:64FF:FE30:1DE0 for FEC0::2:230:94FF:FE24:B780 (Serial0/0.3)  ICMPv6: Sending ICMP unreachable code 3 to FEC0::2:230:94FF:FE24:B780 about FEC0::8:204:C1FF:FE50:F1C0

Packets with a source address fec0::2:230:94ff:fe24:b780 are arriving at Honeytree, interface S0/0.3 (from Honeypot over the link connecting Honeypot to Honeytree). The exit interface, for destination fec0::8:204:c1ff:fe50:f1c0, is either S0/0.2 or S0/0.3. Honeytree is performing per-packet load-sharing, alternating forwarding packets between S0/0.2 and S0/0.3. When the outgoing interface to the destination is S0/0.2 and the incoming interface is S0/0.3, the packet is forwarded. When IOS forwards the packet to S0/0.3, the same interface on which the packet arrived, pings fail, the router generates an ICMP error message.

A packet destined out the same serial interface on which it arrived indicates a routing loop. Since the routers are process switching and thus per packet load sharing, each router alternates forwarding packets using each of its two route entries. Some packets will thus arrive on the same interface to which the packet is destined.




CCIE Professional Development Routing TCP/IP (Vol. 12005)
Routing TCP/IP, Volume 1 (2nd Edition)
ISBN: 1587052024
EAN: 2147483647
Year: 2005
Pages: 233

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net