An important observation from Chapter 1, “TCP/IP Review,” is that the data link/physical layers and the transport/network layers, as defined by the OSI model, perform very similar duties: They provide the means for conveying data from a source to a destination across some path. The difference is that the data link/physical layers provide communications across a physical path, whereas the transport/network layers provide communications across a logical or virtual path made up of a series of data links.
Further, Chapter 1 showed that for communications to take place across a physical path, certain information about data-link identifiers and encapsulations must be acquired and stored in a database such as the ARP cache. Similarly, information that the transport/network layers require to do their job must also be acquired and stored. This information is stored in the route table, also known as the routing information database (RIB).
This chapter examines what sort of information is required to route a packet, how that information is stored in the route table, how to enter the information into the database, and some techniques for building a routed network by entering the proper information into the proper routers’ route tables.
To understand the kind of information that exists in the route table, it is useful to begin with an examination of what happens when a framed packet arrives at one of a router’s interfaces. The data-link identifier in the frame’s destination address field is examined. If it contains either the identifier of the router’s interface or a broadcast identifier, the router strips off the frame and passes the enclosed packet to the network layer. At the network layer, the destination address of the packet is examined. If the destination address is either the IP address of the router’s interface or an all-hosts broadcast address, the protocol field of the packet is examined and the enclosed data is sent to the appropriate internal process.[1]
Any other destination address calls for routing. The address might be for a host on another network to which the router is attached (including the router interface attached to that network) or for a host on a network not directly connected to the router. The address might also be a directed broadcast, in which there is a distinct network or subnet address, and the remaining host bits are all ones. These addresses are also routable.
If the packet is to be routed, the router will do a route table lookup to acquire the correct route. At a minimum, each route entry in the database must contain two items:
Destination address—. This is the address of the network the router can reach. As this chapter explains, the router might have more than one route to the same address, or a group of subnets of the same or of varying lengths, grouped under the same major IP network address.
Pointer to the destination—. This pointer either will indicate that the destination network is directly connected to the router or it will indicate the address of another router on a directly connected link or the local interface to that link. That router, which will be one router hop closer to the destination, is a next-hop router.
The router will match the most specific address it can.[2] In descending order of specificity, the address may be one of the following:
Host address (a host route)
Subnet
Group of subnets (a summary route)
Major network number
Group of major network numbers (a supernet)
Default address
This chapter provides examples of the first four types. Supernets are covered in Chapter 6, “RIPv2, RIPng, and Classless Routing.” A default address is considered a least-specific address and is matched only if no other match can be found. Default addressing is the topic of Chapter 12, “Default Routes and On-Demand Routing.”
If the destination address of the packet cannot be matched to any route table entry, the packet is dropped and a Destination Unreachable ICMP message is sent to the source address.
Figure 3-1 shows a simple network and the route table entries required by each router. Of primary importance here is the “big picture,” seeing how the route tables work as a whole to transport packets correctly and efficiently. The destination addresses that the router can reach are listed in the Network column of the route tables. The pointers to the destinations are in the Next Hop column.
Figure 3-1. The minimum information needed for each route table entry consists of the destination networks and the pointers to those networks.
If router Carroll in Figure 3-1 receives a packet with a source address of 10.1.1.97 and a destination address of 10.1.7.35, a route table lookup determines that the best match for the destination address is subnet 10.1.7.0, reachable via next-hop address 10.1.2.2, on interface S0. The packet is sent to that next router (Dahl), which does a lookup in its own table and sees that network 10.1.7.0 is reachable via next-hop address 10.1.4.2, out interface S1. The process continues until the packet reaches router Baum. That router, receiving the packet on its interface S0, does a lookup, and sees that the destination is on one of its directly connected subnets, out E0. Routing is completed, and the packet is delivered to host 10.1.7.35 on the Ethernet link.
The routing process, as explained, assumes that the router can match its listed next-hop addresses to its interfaces. For example, router Dahl must know that Lewis’s address 10.1.4.2 is reachable via interface S1. Dahl will know from the IP address and subnet mask assigned to S1 that S1 is directly connected to subnet 10.1.4.0. It then knows that 10.1.4.2, a member of the same subnet, must be connected to the same data link.
Notice that every router must have consistent and accurate information for correct packet switching to occur. For example, in Figure 3-1, an entry for network 10.1.1.0 is missing from Dahl’s route table. A packet from 10.1.1.97 to 10.1.7.35 will be delivered, but when a reply is sent from 10.1.7.35 to 10.1.1.97, the packet is passed from Baum to Lewis to Dahl. Then, Dahl does a lookup and finds that it has no entry for subnet 10.1.1.0, so the packet is dropped, and an ICMP Destination Unreachable message is sent to host 10.1.7.35.
Example 3-1 shows the route table from router Lewis of Figure 3-1. The IOS command for examining the IP route table of a Cisco router is show ip route.
Example 3-1. The route table for router Lewis of Figure 3-1.
Lewis#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,
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2,
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, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 7 subnets
S 10.1.3.0 [1/0] via 10.1.4.1
S 10.1.2.0 [1/0] via 10.1.4.1
S 10.1.1.0 [1/0] via 10.1.4.1
S 10.1.7.0 [1/0] via 10.1.6.2
C 10.1.6.0 is directly connected, Serial1
C 10.1.5.0 is directly connected, Ethernet0
C 10.1.4.0 is directly connected, Serial0
Lewis#Examine the contents of this database and compare it with the generic table shown for Lewis in Figure 3-1. A key at the top of the table explains the letters down the left side of the table. These letters indicate how each route entry was learned; in Example 3-1, all routes are tagged with either a C for “directly connected,” or an S for “static entry.” The statement “gateway of last resort is not set” refers to a default route.
At the top of the table is a statement indicating that the route table knows of seven subnets of the major network address 10.0.0.0, subnetted with a 24-bit mask. For each of the seven route entries, the destination subnet is shown; for the entries that are not directly connected—routes for which the packet must be forwarded to a next-hop router—a bracketed tuple indicates [administrative distance/metric] for that route. Administrative distances are introduced later in this chapter and are covered in detail in Chapter 11, “Route Redistribution.”
Metrics, discussed in greater detail in Chapter 4, “Dynamic Routing Protocols,” are a way for multiple routes to the same destination to be rated by preference—the lower the metric, the “shorter” the path and so the more desirable the route. Notice that the static routes shown in Example 3-1 have a metric of 0. Finally, either the address of the directly connected interface of the next-hop router or the interface to which the destination is connected is shown.
The route table acquires information in one of three ways:
The information can be entered based on what the router knows about its directly connected subnets.
The information can be entered manually, by means of a static route entry.
The information can be entered automatically by one of several systems of automatic information discovery and sharing known as dynamic routing protocols.
The bulk of this book concerns dynamic IP routing protocols, but this discussion of static route configuration will prepare you for understanding the subsequent chapters.
More to the point, static routing is preferred over dynamic routing in certain circumstances. As with any process, the more automatic it is, the less control you have over it. Although dynamic (automatic) routing requires much less human intervention, static routing allows very precise control over the routing behavior of a network. The price to be paid for this precision is the necessity of manual reconfiguration any time the topology of the network changes.
Figure 3-2 shows a network with four routers and six data links. Notice that the subnets of network 10.0.0.0 are discontiguous—there is a different major network subnet (192.168.1.192, in the Tigger-to-Piglet link) separating 10.1.0.0 from the other 10.0.0.0 subnets. The subnets of 10.0.0.0 are also variably subnetted—the subnet masks are not consistent throughout the network: Subnet 10.1.0.0 has a 16-bit mask, while 10.4.0.0 has a 24-bit mask. Finally, the subnet address of Pooh’s Ethernet link is an all-zero subnet. Later chapters demonstrate that an addressing scheme with these characteristics causes problems for simpler, classful routing protocols such as RIP and IGRP; but static routes work fine here.
Figure 3-2. Routing protocols such as RIP and IGRP cannot easily route this discontiguous, variably subnetted network, but static routing will work.
The procedure for statically routing a network has three steps:
For each data link within the network, identify all subnet or network addresses.
For each router, identify all data links not directly connected to that router.
For each router, write a route statement for each address not directly connected to it.
Writing route statements for a router’s directly connected data links is unnecessary, because the addresses and masks configured on the router’s interfaces cause those networks to be recorded in its route table.
For example, the network in Figure 3-2 has six subnets:
10.1.0.0/16
10.4.6.0/24
10.4.7.0/24
192.168.1.192/27
192.168.1.64/27
192.168.1.0/27
To configure static routes for Piglet, the subnets that are not directly connected are identified as follows:
10.4.6.0/24
10.4.7.0/24
192.168.1.64/27
192.168.1.0/27
These are the subnets for which static routes must be written. Example 3-2 shows the commands for entering Piglet’s static routes.[3]
Example 3-2. Configuring Piglet’s static routes.
Piglet(config)# ip route 192.168.1.0 255.255.255.224 192.168.1.193 Piglet(config)# ip route 192.168.1.64 255.255.255.224 192.168.1.193 Piglet(config)# ip route 10.4.6.0 255.255.255.0 192.168.1.193 Piglet(config)# ip route 10.4.7.0 255.255.255.0 192.168.1.193
Following the same steps, Example 3-3 shows the route entries for the other three routers.
Example 3-3. Route entries for Routers Pooh, Tigger, and Eeyore.
Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1.66 Pooh(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.66 Pooh(config)# ip route 10.4.6.0 255.255.255.0 192.168.1.66 Pooh(config)# ip route 10.4.7.0 255.255.255.0 192.168.1.66 _________________________________________________________________ Tigger(config)# ip route 192.168.1.0 255.255.255.224 192.168.1.65 Tigger(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.194 Tigger(config)# ip route 10.4.7.0 255.255.255.0 10.4.6.2 _________________________________________________________________ Eeyore(config)# ip route 192.168.1.0 255.255.255.224 10.4.6.1 Eeyore(config)# ip route 192.168.1.64 255.255.255.224 10.4.6.1 Eeyore(config)# ip route 192.168.1.192 255.255.255.224 10.4.6.1 Eeyore(config)# ip route 10.1.0.0 255.255.0.0 10.4.6.1
The routing commands themselves are easily read if the reader remembers that each command describes a route table entry. The command for IPv4 is ip route, followed by the address to be entered into the table, a mask for determining the network portion of the address, and the address of the directly connected interface of the next-hop router.
An alternative configuration command for IPv4 static routes specifies the interface out of which an address is reached instead of the interface address of the next-hop router. For example, Example 3-4 shows the possible route entries for Tigger.
Example 3-4. Alternative route entries for Tigger.
ip route 192.168.1.0 255.255.255.224 S0 ip route 10.1.0.0 255.255.0.0 E0 ip route 10.4.7.0 255.255.255.0 S1
Certain conditions must be met before a static route is written into the route table. IP routing must be enabled, the next-hop address, if used, must be reachable, the exit interface must have an IP address configured on it, and the exit interface must be up.
Example 3-5 compares the route table resulting from this configuration with the route table resulting from entries pointing to a next-hop router. Notice that a certain inaccuracy is introduced: All addresses specified with a static route referring to an exit interface are entered into the table as if they are directly connected to that interface. The implications for route redistribution are discussed in Chapter 11.
A point of interest in Example 3-5 is that the header for the 10.0.0.0 subnets indicates the variable subnet masks used in the network. Variable-length subnet masking (VLSM) can be a useful tool and is discussed at length in Chapter 6.
Example 3-5. The top route table is the result of static route entries pointing to the next-hop router. The bottom route table is the result of static routes that point to the interface a packet must exit to reach the destination network.[4]
Tigger#show ip route 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# Tigger#show ip route 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 is directly connected, Serial1 S 10.1.0.0 255.255.0.0 is directly connected, Ethernet0 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 is directly connected, Serial0 C 192.168.1.192 is directly connected, Ethernet0 Tigger#
A third option for static routes is to use a combination of the outgoing interface and the next-hop address. The next-hop address is coupled with the specified exit interface. If the exit interface goes down, the route is removed from the route table, even if the next-hop address is recursively reachable via an alternate route. This minimizes table lookups associated with finding the outgoing interface associated with a next-hop address and the entry in the table is not considered a directly connected network.
Directing a static route to an exit broadcast interface without specifying the next-hop address can cause an excessive amount of traffic on the broadcast network, and also might eat up the router’s memory. For example, look at Tigger’s ip route 10.1.0.0 255.255.0.0 E0 command. The router assumes 10.1.0.0 is directly connected, as we have seen from the route table. Therefore, when attempting to route to any address on the 10.1.0.0/16 subnet, the router sends an ARP request to find the MAC address to which to forward the packet. Each attempt to reach an address on the 10.1.0.0 network, whether the destination is valid or not, will result in an ARP request, an ARP response if a router on the broadcast network is responding on behalf of the 10.1.0.0 network (proxy ARP), and a potentially large ARP cache on the router. By appending the next-hop address to the static route entry, ip route 10.1.0.0 255.255.0.0 E0 192.168.1.194, the router no longer assumes that the destination is directly connected. The only ARP traffic is for the next-hop address, which only occurs for the first packet destined to a host on network 10.1.0.0, rather than for every packet destined to a new host on network 10.1.0.0.
Specify the exit interface and the next-hop address to minimize table lookups associated with finding the exit interface for a specified next-hop address, and to minimize traffic on the broadcast network.
Example 3-6 shows the difference in the static route entries in the route tables when the next-hop address is used with the exit interface.
Example 3-6. Specifying an exit interface rather than the next-hop router address with static routing could generate excessive traffic on a broadcast network.
Tigger#show ip route static 10.0.0.0/16 is subnetted, 1 subnets S 10.1.0.0 is directly connected, Ethernet0 Tigger#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.1.193 - 0004.c150.f1c0 ARPA Ethernet0 Internet 10.1.8.1 0 0010.7b38.37d5 ARPA Ethernet0 Internet 192.168.1.194 24 0010.7b38.37d5 ARPA Ethernet0 Internet 10.1.5.5 0 0010.7b38.37d5 ARPA Ethernet0 Internet 10.1.1.1 0 0010.7b38.37d5 ARPA Ethernet0 Tigger# Tigger#show ip route static 10.0.0.0/16 is subnetted, 1 subnets S 10.1.0.0 [1/0] via 192.168.1.194, Ethernet0 Tigger#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.1.193 - 0004.c150.f1c0 ARPA Ethernet0 Internet 192.168.1.194 22 0010.7b38.37d5 ARPA Ethernet0
The first route table and ARP cache show that the static route entry was created with an exit interface and no next-hop address. The route is directly connected and there are multiple ARP cache entries for destinations on the 10.1.0.0 network. The MAC address for each entry is the same. It is the hardware address of the router with IP address 192.168.1.194. The router is sending ARP replies for all hosts on the 10.1.0.0 network. As discussed in Chapter 1, this proxy ARP is enabled by default in IOS.
The second set of tables shows the route table and ARP cache when the next-hop address is specified in addition to the exit interface. Notice the route is no longer directly connected. It is known via 192.168.1.194 and the exit interface is Ethernet 0. The ARP cache has no entries for the 10.1.0.0 network, only for the addresses that actually exist on the directly connected network, including 192.168.1.194.
IPv6 static routes are configured the same way as IPv4 static routes. The only difference is that the IPv6 prefix length of the destination network is entered rather than the dotted decimal form of the IPv4 network mask. Unlike IPv4, however, IPv6 routing is not enabled by default. Before entering a static route, IPv6 must be enabled using the ipv6 unicast-routing command. As with IPv4, an IPv6 address must be configured on the exit interface and the interface must be up before the static entry will be added to the route table. The command used to create a static route is ipv6 route followed by the network to be entered into the route table, the length, in bits of the prefix, and the address of the next-hop router, or the exit interface to be used to reach this destination.
To specify the next-hop address in the static route entry, you need to know what that address is. A detailed network drawing will help, but it may be out of date because of the dynamic nature of the Interface ID portion of the addresses. When addressing the IPv6 network, if you specify interface IDs manually rather than using the automatically constructed EUI-64 format addresses, the next-hop address will be predictable. However, if the interfaces on the data link are configured to use EUI-64 interface IDs, you only specify the first 64 bits of the address. The router determines the final 64 bits based on a MAC address. If a router is replaced, the new router will have different IPv6 addresses. (The first 64 bits will remain the same, but the final 64 bits will be different.) One way to identify the full 128-bit IPv6 address of a neighbor router is to use the Cisco Discovery Protocol (CDP) statistics. CDP displays information about neighboring routers, such as the router’s hostname, router type, IOS, and the IP addresses configured on the remote end of the link. Example 3-7 displays one form of the show cdp command.
Example 3-7. Cisco Discovery Protocol can tell you a lot of information about a device’s neighbors.
Honeybee#show cdp neighbor detail
-------------------------
Device ID: Honeytree
Entry address(es):
IP address: 10.4.6.2
IPv6 address: FE80::2B0:64FF:FE30:1DE0 (link-local)
IPv6 address: FEC0::1:2B0:64FF:FE30:1DE0 (site-local)
Platform: cisco 2610, Capabilities: Router
Interface: Serial0/0.2, Port ID (outgoing port): Serial0/0.2
Holdtime : 146 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.3(6), RELEASE SOFTWARE (fc3)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Wed 11-Feb-04 19:24 by kellythw
advertisement version: 2Example 3-7 displays a lot of information about the neighbor router, including the router type, IOS, host name and IP addresses. The detail keyword is required to obtain all the information that is displayed.
Another way to determine the IPv6 address of a link is to issue the show ipv6 interface command. This command displays the IPv6 information relevant to an interface. Example 3-8 shows the output from the command issued on Honeybee.
Example 3-8. show ipv6 interface displays IPv6 information relevant to an interface, including the IPv6 EUI-64 formatted addresses.
Honeybee#show ipv6 interface serial0/0.1
Serial0/0.1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::204:C1FF:FE50:F1C0
Description: Link to Piglet
Global unicast address(es):
FEC0::3:204:C1FF:FE50:F1C0, subnet is FEC0:0:0:3::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF30:1DE0Figure 3-3 shows a simple network with IPv6 addresses.[5]
Example 3-9 shows the commands for entering Honeypot’s IPv6 static routes.
Example 3-9. Configuring Honeypot’s IPv6 static routes.
ipv6 unicast-routing interface serial 0/0.2 point-to-point ipv6 address fec0:0:0:3::/64 eui-64 ipv6 route fec0::1:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 ipv6 route fec0::a:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0 ipv6 route fec0::8:0:0:0:0/64 fec0::3:204:c1ff:fe50:f1c0
Example 3-10 and Example 3-11 show the route entries for the other two routers, Honeytree and Honeybee, respectively.
Example 3-10. Configuring IPv6 static routes for Honeytree.
ipv6 route fec0::8:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 ipv6 route fec0::3:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0 ipv6 route fec0::5:0:0:0:0/64 fec0::1:204:c1ff:fe50:f1c0
Example 3-11. Configuring IPv6 static routes for Honeybee.
ipv6 route fec0::a:0:0:0:0/64 fec0::1:2b0:64ff:fe30:1de0 ipv6 route fec0::5:0:0:0:0/64 fec0::3:230:94ff:fe24:b780
Look at the next-hop address used for Honeypot’s routes, and the next-hop address used for Honeytree’s routes. Honeypot’s next-hop address for each route is fec0::3:204:c1ff:fe50:f1c0. The next-hop address used for Honeytree’s routes is fec0::1:204:c1ff:fe50:f1c0. These addresses are those of Honeybee’s interfaces to Honeypot and Honeytree, respectively. Notice that the last 64 bits of each of Honeybee’s interface addresses are the same. The router uses its first encountered MAC address to form the last 64 bits of the EUI-64 formatted IPv6 addresses on each of its serial interfaces.
As with IPv4, IPv6 static routes can use the outbound interface rather than next-hop address. There is an option to enter an address after the interface as there is with IPv4. You can put either the link-local address here or a configured address. This next-hop address should be used when the exit interface is a broadcast interface, such as Ethernet.
Example 3-12 displays Honeypot’s IPv6 route table with only the next-hop address specified in the ipv6 route statement. The command show ipv6 route displays the IPv6 route table. Prefixes, prefix lengths, and the next-hop address or outgoing interface are displayed, as are the administrative distance and route metric.
Example 3-12. As with IPv4, the IPv6 static route table displays the destination network and the next-hop address used to reach the destination.
Honeypot#show ipv6 route
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
L FE80::/10 [0/0]
via ::, Null0
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
S FEC0:0:0:A::/64 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
S FEC0:0:0:8::/64 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
S FEC0:0:0:1::/64 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
C FEC0:0:0:5::/64 [0/0]
via ::, Ethernet0/0
L FEC0::5:230:94FF:FE24:B780/128 [0/0]
via ::, Ethernet0/0
L FF00::/8 [0/0]
via ::, Null0The static routes displayed in Example 3-12 were entered using an IPv6 next-hop address. The router must determine the exit interface associated with this IPv6 address recursively, as it does with IPv4. The entry for FEC0:0:0:A::/64 has a next-hop address of FEC0::3:204:C1FF:FE50:F1C0. Looking further into the route table, FEC0:0:0:3::/64 is connected on Serial0/0.2. Notice that the administrative distance of the static routes entered with the next-hop IPv6 address is 1 and the route metric is 0, the same as IPv4 static route entered in this way.
Routes can also be entered with the outgoing interface toward the destination network. The outgoing interface and the next-hop address can be entered together, too. Example 3-13 shows what Honeypot’s static route configuration could be changed to.
Example 3-13. Alternative static route configuration for Honeypot.
ipv6 route fec0::a:0:0:0:0/64 serial 0/0.2 ipv6 route fec0::8:0:0:0:0/64 serial 0/0.2 ipv6 route fec0::1:0:0:0:0/64 serial 0/0.2 ipv6 route fec0::20:0:0:0:0/62 Ethernet0/0 FE80::2B0:64FF:FE30:1DE0
The last entry, using the exit interface and the next-hop address will help to illustrate the difference in the route table between the two forms of the command. Example 3-14 displays Honeypot’s new route table.
Example 3-14. Honeypot route table after changing the next hop to the exit interface.
Honeypot#show ipv6 route static
S FEC0:0:0:A::/64 [1/0]
via ::, Serial0/0.2
S FEC0:0:0:8::/64 [1/0]
via ::, Serial0/0.2
S FEC0:0:0:1::/64 [1/0]
via ::, Serial0/0.2
S FEC0:0:0:20::/62 [1/0]
via FE80::2B0:64FF:FE30:1DE0, Ethernet0/0One thing to notice in the route table is that the routes do not appear to be directly connected as it does with IPv4.
The next-hop address is undetermined when you enter the outbound interface unless you specify the exit interface and the next-hop address. You can see this in the route table shown in Example 3-14. The first statement, for instance, says that FEC0:0:0:A::/64 is known via ::, Serial 0/0.2. The “::” means that the next hop is unspecified, but the outgoing interface is Serial 0/0.2. On a point-to-point serial interface, an unspecified next-hop address is not a problem. There is only one other device on that point-to-point network, and all packets are forwarded out the interface and reach the other device.
On a broadcast interface, the router must find a neighbor to which to send the packet. The router multicasts a neighbor solicitation message on the Ethernet and waits for a neighbor advertisement from the next-hop device. There is no defined proxy address resolution mechanism with IPv6, other than for mobile IPv6 nodes. A router on the Ethernet that has a route to the destination will not respond to a neighbor solicitation on behalf of another device.
For this reason, when using an exit interface to configure a static route on a broadcast network, a next-hop address must also be specified. The recommended address to use as the next-hop address is the link-local address of the next-hop router. One reason to use the link-local address is that it is not likely to change. A link-local address will only change if the interface card, or the entire router, is replaced. Even if the site is renumbered with a different IPv6 global prefix, the link-local address on the interface does not change. Another reason to use the link-local address as the next hop is to remain consistent with the addresses routers advertise in the router advertisement messages and so that processes using those addresses, such as ICMPv6 Redirect, will operate as expected.
Routers advertise their presence, along with their link-local addresses, to all IPv6 devices on broadcast networks. Hosts use the router list created from the router advertisement to determine how to forward packets off the network. If a host forwards a packet to a router, and that router knows that a second router on the network is a better choice for the host to use, the first router will send a redirect to the host. The redirect includes the link-local IPv6 address of the better choice router. When the host processes the redirect, if the better router is in its router list, the host will begin to forward packets to the better router. If the better router is not in the list (or it is listed by a different IPv6 address), the host will discard the redirect.
A summary route is an address that encompasses several more specific addresses in a route table. It is the address mask used with a route entry that makes static routes as flexible as they are; by using an appropriate address mask, it is sometimes possible to create a single summary route for several destination addresses.
For example, the preceding two case studies use a separate entry for each data link. The mask of each entry corresponds to the address mask used on the device interfaces connected to that data link. Looking again at Figure 3-2, you can see that subnets 10.4.6.0/24 and 10.4.7.0/24 could be specified to Piglet with a single entry of 10.4.0.0/16, reachable via Tigger. Likewise, subnets 192.168.1.0/27 and 192.168.1.64/27 could be accounted for in its route table with a single entry pointing to 192.168.1.0/24, also reachable via Tigger. These two route entries, 10.4.0.0/16 and 192.16.1.0/24, are summary routes.
Using summary routes, Piglet’s static route entries are displayed in Example 3-15.
Example 3-15. Piglet’s static route entries are summarized into only two entries.
ip route 192.168.1.0 255.255.255.0 192.168.1.193 ip route 10.4.0.0 255.255.0.0 192.168.1.193
All subnets of network 10.0.0.0 are reachable from Pooh via Tigger, so a single entry to that major network address and a corresponding mask are all that is needed (see Example 3-16).
Example 3-16. Pooh’s static route entries for all of network 10.0.0.0 subnets are summarized into a single entry.
ip route 192.168.1.192 255.255.255.224 192.168.1.66 ip route 10.0.0.0 255.0.0.0 192.168.1.66
From Eeyore, all destination addresses beginning with 192 are reachable via Tigger. The single route entry does not even have to specify all of the Class C address bits[6], as displayed in Example 3-17.
Example 3-17. Eeyore summarizes all routes beginning with 192 into a single entry.
ip route 192.0.0.0 255.0.0.0 10.4.6.1 ip route 10.1.0.0 255.255.0.0 10.4.6.1
Summary routes can also be applied to the IPv6 destination addresses in Figure 3-3.
Honeypot’s two static routes can be summarized into a group consisting of fec0:0:0:8:: through fec0:0:0:b:: by changing the prefix length from 64 to 62, as in Example 3-18.
Example 3-18. Honeypot summarizes IPv6 static routes.
ipv6 route fec0::8:0:0:0:0/62 fec0::3:204:c1ff:fe50:f1c0By summarizing a group of subnets or even major networks, the number of static route entries may be reduced drastically—in this example, by more than one-third. However, caution must be used when summarizing addresses; when done incorrectly, unexpected routing behavior may occur (see “Case Study: Tracing a Failed Route,” later in this chapter). Summarization and the problems that can develop from incorrect summarization are examined in more depth in Chapters 7, “Enhanced Interior Gateway Routing Protocol (EIGRP),” and 8, “OSPFv2.”
In Figure 3-4, a new link has been added between Pooh and Eeyore. All packets from Pooh to the 10.0.0.0 networks will take this new path with the exception of packets destined for the host 10.4.7.25; a policy is in place stating that traffic to this host must go through Tigger. The static route commands at Pooh will be as displayed in Example 3-19.
Example 3-19. Pooh’s static route commands help implement a policy directing traffic through specific routers.
ip route 192.168.1.192 255.255.255.224 192.168.1.66 ip route 10.0.0.0 255.0.0.0 192.168.1.34 ip route 10.4.7.25 255.255.255.255 192.168.1.66
The first two route entries are the same as before except that the second path now points to the new interface 192.168.1.34 at Eeyore. The third entry is a host route, pointing to the single host 10.4.7.25 and made possible by setting the address mask to all ones. Notice that unlike the entry for the other 10.0.0.0 subnets, this host route points to Tigger’s interface 192.168.1.66.
The debugging function debug ip packet is turned on in Pooh (see Example 3-20) to observe the paths packets take from the router as a result of the new route entries. A packet is sent from a host 192.168.1.15 to host 10.4.7.25. The first two debug trap messages show that the packet is routed from interface E0 to the next-hop router 192.168.1.66 (Tigger) out interface S0, as required, and that the reply packet was received on S0 and routed to the host 192.168.1.15 out E0.
Example 3-20. Debugging verifies that the new route entries at Pooh are working correctly.
Pooh#debug ip packet
IP packet debugging is on
Pooh#
IP: s=192.168.1.15 (Ethernet0), d=10.4.7.25 (Serial0), g=192.168.1.66, forward
IP: s=10.4.7.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.168.1.15, forward
Pooh#
IP: s=192.168.1.15 (Ethernet0), d=10.4.7.100 (Serial1), g=192.168.1.34, forward
IP: s=10.4.7.100 (Serial0), d=192.168.1.15 (Ethernet0), g=192.168.1.15, forward
Pooh#Next, a packet is sent from host 192.168.1.15 to host 10.4.7.100. Packets destined for any host on 10.0.0.0 subnets, other than host 10.4.7.25, should be routed across the new link to Eeyore’s interface 192.186.1.34. The third debug message verifies that this is indeed happening. However, the fourth message shows something that at first might be surprising. The response from 10.4.7.100 to 192.168.1.15 arrived on Pooh’s interface S0 from Tigger.
Remember that the route entries in the other routers have not changed from the original example. This result might or might not be desired, but it does illustrate two characteristics of static routes:
First, if the network topology changes, the routers that are required to know about those changes must be reconfigured.
Second, static routes can be used to create very specific routing behavior. In this example, perhaps it is desirable to have traffic taking one path in one direction and another path in the opposite direction.
A final observation about this example is that packets routed from Pooh to subnet 10.1.5.0 take a less-than-optimal route, from Pooh to Eeyore to Tigger instead of directly from Pooh to Tigger. Example 3-21 shows a more efficient configuration for Router Pooh.
Example 3-21. Configuring a more efficient static route on Router Pooh.
ip route 192.168.1.192 255.255.255.224 192.168.1.66 ip route 10.0.0.0 255.0.0.0 192.168.1.34 ip route 10.1.0.0 255.255.0.0 192.168.1.66 ip route 10.4.7.25 255.255.255.255 192.168.1.66
The third entry will now send all packets for subnet 10.1.5.0 directly to Tigger.
Unlike other static routes, a floating static route is less preferred than other routes in the route table. It appears in the table only under the special circumstance of the failure of a more-preferred route.
In Figure 3-5, a new router (Rabbit) is connected to Piglet with two parallel links. One link connects their respective Serial 0 interfaces, and the second connection has been added between the two Serial 1 interfaces. This second link has been added for redundancy: If the primary link 10.1.10.0 fails, floating static routes will direct traffic across the backup link 10.1.20.0.
Figure 3-5. A new router has been connected to Piglet. Two serial links are used: one for the primary link and one for the backup link.
Additionally, the mask on Piglet’s Ethernet interface has changed from 10.1.5.1/16 to 10.1.5.1/24. This change allows the single route entry at Tigger—
ip route 10.1.0.0 255.255.0.0 192.168.1.194to point not only to 10.1.5.0 but also to all of the new subnets used in association with the new router.
To create the floating static route, Example 3-22 and Example 3-23 show the route entries for both Piglet and Rabbit, respectively.
Example 3-22. Route entries for Piglet to create a floating static route.
ip route 192.168.1.0 255.255.255.0 192.168.1.193 ip route 10.4.0.0 255.255.0.0 192.168.1.193 ip route 10.1.30.0 255.255.255.0 10.1.10.2 ip route 10.1.30.0 255.255.255.0 10.1.20.2 50
Example 3-23. Route entries for Rabbit to create a floating static route.
ip route 10.4.0.0 255.255.0.0 10.1.10.1 ip route 10.4.0.0 255.255.0.0 10.1.20.1 50 ip route 10.1.5.0 255.255.255.0 10.1.10.1 ip route 10.1.5.0 255.255.255.0 10.1.20.1 50 ip route 192.168.0.0 255.255.0.0 10.1.10.1 ip route 192.168.0.0 255.255.0.0 10.1.20.1 50
Two entries at Piglet point to Rabbit’s network 10.1.30.0; one specifies a next-hop address of Rabbit’s S0 interface, and the other specifies a next-hop address of Rabbit’s S1 interface. Rabbit has similar double entries for every route.
Notice that all static routes using subnet 10.1.20.0 are followed by a 50. This number specifies an administrative distance, which is a measure of preferability; when duplicate paths to the same network are known, the router will prefer the path with the lower administrative distance. At first this idea sounds like a metric; however, a metric specifies the preferability of a route, whereas an administrative distance specifies the preferability of the means by which the route was discovered.
By increasing the administrative distances of the static routes traversing subnet 10.1.20.0 to 50, they become less preferred than the routes traversing subnet 10.1.10.0. Example 3-24 shows three iterations of Rabbit’s route table. In the first table, all routes to nonconnected networks use a next-hop address of 10.1.10.1. The bracketed numbers associated with each route indicate an administrative distance of 1 and a metric of 0 (because no metrics are associated with static routes).
Example 3-24. When the primary link 10.1.10.0 fails, the backup link 10.1.20.0 is used. When the primary link is restored, it is again the preferred path.
Rabbit#show ip route 10.0.0.0 is variably subnetted, 5 subnets, 2 masks C 10.1.10.0 255.255.255.0 is directly connected, Serial0 S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 C 10.1.20.0 255.255.255.0 is directly connected, Serial1 S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 Rabbit# %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down %LINK-3-UPDOWN: Interface Serial0, changed state to down Rabbit#show ip route 10.0.0.0 is variably subnetted, 4 subnets, 2 masks S 10.4.0.0 255.255.0.0 [50/0] via 10.1.20.0 S 10.1.5.0 255.255.255.0 [50/0] via 10.1.20.1 C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 C 10.1.20.0 255.255.255.0 is directly connected, Serial1 S 192.168.0.0 255.255.0.0 [50/0] via 10.1.20.1 Rabbit# %LINK-3-UPDOWN: Interface Serial0, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up Rabbit#show ip route 10.0.0.0 is variably subnetted, 5 subnets, 2 masks C 10.1.10.0 255.255.255.0 is directly connected, Serial0 S 10.4.0.0 255.255.0.0 [1/0] via 10.1.10.1 S 10.1.5.0 255.255.255.0 [1/0] via 10.1.10.1 C 10.1.30.0 255.255.255.0 is directly connected, Ethernet0 C 10.1.20.0 255.255.255.0 is directly connected, Serial1 S 192.168.0.0 255.255.0.0 [1/0] via 10.1.10.1 Rabbit#
Next, trap messages announce that the state of the primary link connected to Serial 0 has changed to “down,” indicating a failure. A look at the second iteration of the route table shows that all nonconnected routes now point to a next-hop address of 10.1.20.1. Because the more-preferred entry is no longer available, the router has switched to the less-preferred backup link, with the administrative distance of 50 indicated in the brackets. And because subnet 10.1.10.0 has failed, it no longer shows up in the route table as a directly connected network.
Before the third iteration of the route table, trap messages indicate that the state of the primary link has changed to “up.” The route table then shows that subnet 10.1.10.0 is again in the table, and the router is again using the next-hop address of 10.1.10.1.
Chapter 11 discusses the administrative distances associated with the various dynamic routing protocols, but it can be said here that the administrative distances of all dynamic routing protocols are substantially higher than 1. Therefore, by default, a static route to a network will always be preferred over a dynamically discovered route to the same network.
IPv6 floating static route statements work the same way as IPv4. A second link has been added to the IPv6 network of Figure 3-3 between Honeypot and Honeybee, to route IPv6 traffic if the primary link fails (see Figure 3-6).
Figure 3-6. Backup link added between two IPv6 routers can be used to recover from a primary link failure with floating static routes.
Example 3-25 shows Honeypot’s configuration with new static route entries, which have an administrative distance greater than 1. Similar static routes are entered on Honeybee, as shown in Example 3-26.
Example 3-25. Honeypot is configured with floating static routes to be used over the new redundant parallel link to Honeybee.
ipv6 route FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 ipv6 route FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 50 ipv6 route FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0 ipv6 route FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 50
Example 3-26. Honeybee is configured with floating static routes to be used over the new redundant parallel link to Honeypot.
ipv6 route FEC0:0:0:5::/64 FEC0::3:230:94FF:FE24:B780 ipv6 route FEC0:0:0:5::/64 FEC0::2:230:94FF:FE24:B780 50 ipv6 route FEC0:0:0:A::/64 FEC0::1:2B0:64FF:FE30:1DE0
IPv6 traffic from Honeypot will continue to be forwarded out Serial0/0.2, unless this link goes down.
Example 3-27 shows Honeypot’s route table with the routes known via the fec0::3:0:0:0:0/64 subnet installed. Both routes have an administrative distance of 1. Then, interface S0/0.2 goes down. The backup routes, with administrative distance of 50, get installed in the route table. After the interface S0/0.2 comes back up, the routing process learns of better routes to the destinations and installs the routes with an administrative distance of 1 back into the table.
Example 3-27. Static routes with high administrative distances are installed in the IPv6 route table only when the lower administrative distance routes are deleted.
Honeypot#show ipv6 route static S FEC0::/62 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 S FEC0:0:0:8::/62 [1/0] via FEC0::3:204:C1FF:FE50:F1C0 Honeypot# %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, changed state to down %LINK-3-UPDOWN: Interface Serial0/2, changed state to down Honeypot#show ipv6 route static S FEC0::/62 [50/0] via FEC0::2:204:C1FF:FE50:F1C0 S FEC0:0:0:8::/62 [50/0] via FEC0::2:204:C1FF:FE50:F1C0 Honeypot# %LINK-3-UPDOWN: Interface Serial0/2, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2, changed state to up
The default administrative distance of IPv6 static routes, whether specified with an exit interface or a next-hop address, is 1. When static routes to a destination are specified both ways, the routes are considered equal, and load sharing (described in the next case study) occurs.
The problem with the configuration used in the previous section is that under normal circumstances the second link is never utilized. The bandwidth available on the link is wasted. Load sharing allows routers to take advantage of multiple paths to the same destination by sending packets over all the available routes.
Load sharing can be equal cost or unequal cost, where cost is a generic term referring to whatever metric (if any) is associated with the route:
Equal-cost load sharing distributes traffic equally among multiple paths with equal metrics. In this case, load sharing can also be called load balancing.
Unequal-cost load sharing distributes packets among multiple paths with different metrics. The traffic is distributed in inverse proportion to the cost of the routes. That is, paths with lower costs are assigned more traffic, and paths with higher costs are assigned less traffic.
Some routing protocols support both equal-cost and unequal-cost load sharing, whereas others support only equal cost. Static routes, which have no metric, support only equal-cost load sharing.
To configure the parallel links in Figure 3-5 for load sharing using static routes, Example 3-28 shows the route entries for Piglet and Example 3-29 shows the route entries for Rabbit.
Example 3-28. Configuring parallel links for load sharing using static routes: route entries for Piglet.
ip route 192.168.1.0 255.255.255.0 192.168.1.193 ip route 10.4.0.0 255.255.0.0 192.168.1.193 ip route 10.1.30.0 255.255.255.0 10.1.10.2 ip route 10.1.30.0 255.255.255.0 10.1.20.2
Example 3-29. Configuring parallel links for load sharing using static routes: route entries for Rabbit.
ip route 10.4.0.0 255.255.0.0 10.1.10.1 ip route 10.4.0.0 255.255.0.0 10.1.20.1 ip route 10.1.5.0 255.255.255.0 10.1.10.1 ip route 10.1.5.0 255.255.255.0 10.1.20.1 ip route 192.168.0.0 255.255.0.0 10.1.10.1 ip route 192.168.0.0 255.255.0.0 10.1.20.1
These entries were also used in the previous section for floating static routes, except both links now use the default administrative distance of 1. Rabbit’s route table, shown in Example 3-30, now has two routes to each destination.
Example 3-30. This route table indicates that there are two paths to the same destination networks. The router will balance the load across these multiple paths.
Rabbit#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 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.1.10.0/24 is directly connected, Serial0 S 10.1.5.0/24 [1/0] via 10.1.10.1 [1/0] via 10.1.20.1 S 10.4.0.0/16 [1/0] via 10.1.10.1 [1/0] via 10.1.20.1 C 10.1.20.0/24 is directly connected, Serial1 S 192.168.0.0/16 [1/0] via 10.1.10.1 [1/0] via 10.1.20.1 Rabbit#
IPv6 works the same way as IPv4. The static routes in Honeypot’s route table, shown in Example 3-31, will yield the route table shown in Example 3-32.
Example 3-31. Honeypot’s IPv6 static routes are configured for load-balancing, with each destination prefix using two different next-hop addresses.
ipv6 route FEC0::/62 FEC0::2:204:C1FF:FE50:F1C0 ipv6 route FEC0::/62 FEC0::3:204:C1FF:FE50:F1C0 ipv6 route FEC0:0:0:8::/62 FEC0::2:204:C1FF:FE50:F1C0 ipv6 route FEC0:0:0:8::/62 FEC0::3:204:C1FF:FE50:F1C0
Example 3-32. The router will load balance over these two IPv6 paths to the same destination networks.
Honeypot#show ipv6 route static
S FEC0::/62 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
via FEC0::2:204:C1FF:FE50:F1C0
S FEC0:0:0:8::/62 [1/0]
via FEC0::3:204:C1FF:FE50:F1C0
via FEC0::2:204:C1FF:FE50:F1C0Load sharing is also either per destination or per packet.
Per destination load sharing distributes the load according to destination address. Given two paths to the same network, all packets for one destination may travel over the first path, all packets for a second destination on the same network may travel over the second path, all packets for a third destination may again be sent over the first path, and so on. This is the default type of load sharing used by Cisco Express Forwarding (CEF). On most platforms, CEF is the default switching mode for IPv4, but not IPv6.
CEF is a very efficient switching process. Its forwarding information is obtained and stored in tables before any packet needs to use the information. CEF builds a forwarding information base (FIB) with information obtained from the route table. All the destination networks entered in the route table are entered into the CEF FIB. If the route table is stable and not changing, the FIB will not change. CEF uses a separate table, the adjacency table, to maintain Layer 2 forwarding information for each entry in the FIB. The adjacency table is created as Layer 2 information is learned, through IP ARP or IPv6 Neighbor Discovery, for instance. Both the FIB and adjacency table are created before packets need to be forwarded. Not even the first packet to a destination is process switched, as is the case with other switching schemes.
CEF performs per-destination load sharing by default. This is actually per source-destination pair load sharing. All traffic that has a particular source address and is destined to a specific destination address will exit the same interface. Traffic with a different source/destination address pair may exit the next interface.
Per packet load sharing is another method available to CEF switched IPv4 packets. IPv6 CEF only supports per destination load sharing. Per packet load sharing means that one packet is sent over one link, the next packet is sent over the next link, even if this next packet is to the same destination as the first, and so on, given equal-cost paths. If the paths are unequal cost, the load sharing may be one packet over the higher-cost link for every three packets over the lower-cost link, or some other proportion depending upon the ratio of costs. Per packet load sharing may distribute the load more evenly than per destination load sharing, depending upon the number of different source-destination pairs, but because the packets to a given destination will be taking different paths, the packets are likely to arrive out of order, which is unacceptable for some applications, such as Voice over IP.
To determine if CEF is enabled globally on a router, use the commands show ip cef and show ipv6 cef. If it is not enabled by default, you can turn it on globally using the command ip cef for IPv4. To enable CEF for IPv6, first enable CEF for IPv4, then use the command ipv6 cef.
Per packet load sharing is enabled for IPv4 using the interface command ip load-sharing per-packet. The command ip load-sharing per-destination re-enables per destination load sharing. You can see which type of load sharing is enabled using the show cef interface command. This displays the CEF information that is configured on the interface.
The router determines whether to use CEF switching based on the ingress interface and the type of source and destination address. The ingress interface must be configured with CEF switching for the router to even consider using CEF. If CEF is configured on the ingress interface, CEF will attempt to switch the packet. If for some reason the packet cannot be CEF switched, CEF punts the packet down to the next-best and available switching method. For IPv4, this would be fast switching, if it is enabled on the interface. For IPv6, this would be process switching.
You can verify that CEF is enabled on an interface using the commands show cef interface {interface} and show ipv6 cef {interface} detail.
IOS performs per destination load sharing on exit interfaces configured with fast switching. Fast switching is the default IOS switching mode in some routers.
Fast switching works as follows:
When a router switches the first packet to a particular destination, a route table lookup is performed and an exit interface is selected.
The necessary data-link information to frame the packet for the selected interface is then retrieved (from the ARP cache, for instance), and the packet is encapsulated and transmitted.
The retrieved route and data-link information is then entered into a fast switching cache.
As subsequent packets to the same destination enter the router, the information in the fast cache allows the router to immediately switch the packet without performing another route table and ARP cache lookup.
While switching time and processor utilization are decreased, fast switching means that all packets to a specific destination, not source-destination pair, are routed out the same interface. When packets addressed to a different host on the same network enter the router and an alternate route exists, the router may send all packets for that destination on the alternate route. Therefore, the best the router can do is balance traffic on a per destination basis.
Process switching simply means that for every packet, the router performs a route table lookup, selects an interface, and then looks up the data link information. Because each routing decision is independent for each packet, all packets to the same destination are not forced to use the same interface. To enable process switching on an interface, use the command no ip route-cache for IPv4. You don’t have to do anything to enable process switching for IPv6. It is enabled by default.
In Example 3-33, host 192.168.1.15 has sent six pings to host 10.1.30.25. Using debug ip packet, the ICMP echo request and echo reply packets are observed at Piglet. Looking at the exit interfaces and the forwarding addresses, it can be observed that both Piglet and Rabbit are using S0 and S1 alternately. Note that the command debug ip packet allows only process switched packets to be observed. Fast switched packets are not displayed.
Example 3-33. This router is alternating between S0 and S1 to send packets to the same destination. Notice that the router on the other end of the two links is doing the same thing with the reply packets.
Piglet#debug ip packet
IP packet debugging is on
Piglet#
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), g=10.1.10.2, forward
IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.168.1.193, forward
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), g=10.1.20.2, forward
IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), g=192.168.1.193, forward
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), g=10.1.10.2, forward
IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.168.1.193, forward
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), g=10.1.20.2, forward
IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), g=192.168.1.193, forward
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial0), g=10.1.10.2, forward
IP: s=10.1.30.25 (Serial0), d=192.168.1.15 (Ethernet0), g=192.168.1.193, forward
IP: s=192.168.1.15 (Ethernet0), d=10.1.30.25 (Serial1), g=10.1.20.2, forward
IP: s=10.1.30.25 (Serial1), d=192.168.1.15 (Ethernet0), g=192.168.1.193, forward
Piglet#Like many design choices, per packet load balancing has a price. The traffic may be distributed more evenly among the various links than with per destination load balancing, but the lower switching time and processor utilization of fast switching are lost.
IOS makes switching decisions based on the configuration of the inbound interface first. If CEF is configured on an inbound interface, the packet will be CEF switched regardless of the configuration on the outbound interface.
If CEF is not enabled on the inbound interface, then IOS processes and forwards the packet, and based on the configuration of the outbound interface, subsequent packets will be fast-switched or process switched. Table 3-1 shows which switching method will be used based on configuration of inbound and outbound interfaces.
IOS will switch a packet using CEF only if CEF is enabled on the inbound interface. If CEF is not configured on the inbound interface, the configuration of the exit interface determines the switching method. Notice that when process or fast-switching is configured inbound and CEF is configured on the outbound interface, fast-switching is used. CEF is only used if it is configured on the ingress interface. For IPv4, fast-switching is enabled outbound, even if CEF is enabled on the interface.
There are times when a packet will not be switched using CEF even if it is enabled (for example, if access-list logging is enabled and a packet will be logged). Packets will be punted down to the next fastest switching method. For IPv4, the next fastest switching method is fast-switching. For IPv6, this is process switching.
All route entries do not necessarily need to point to the next-hop router. Figure 3-7 shows a simplified version of the network of Figure 3-5. In this network, Pooh is configured as displayed in Example 3-34.
Example 3-34. Pooh’s static route entries use various addresses as the next-hop parameter. The addresses are not necessarily the actual next-hop router interface.
ip route 10.1.30.0 255.255.255.0 10.1.10.2 ip route 10.1.10.0 255.255.255.0 192.168.1.194 ip route 192.168.1.192 255.255.255.224 192.168.1.66
If Pooh needs to send a packet to host 10.1.30.25, it will look into its route table and find that the subnet is reachable via 10.1.10.2. Because that address is not on a directly connected network, Pooh must again consult the table to find that network 10.1.10.0 is reachable via 192.168.1.194. That subnet is also not directly connected, so a third table lookup is called for. Pooh will find that 192.168.1.192 is reachable via 192.168.1.66, which is on a directly connected subnet. The packet can now be forwarded.
Because each table lookup costs processor time, under normal circumstances forcing a router to perform multiple lookups is a poor design decision. Fast switching significantly reduces these adverse effects by limiting the recursive lookups to the first packet to each destination, but a justification should still be identified before using such a design.
Figure 3-8 shows an example of an instance in which recursive lookups might be useful. Here, Sanderz reaches all networks via Heffalump. However, the network administrator plans to eliminate Heffalump and repoint all of Sanderz’s routes through Woozle. The first 12 entries point not to Heffalump, but to the appropriate router attached to the 10.87.14.0 subnet. The last entry specifies that the 10.87.14.0 subnet is reached via Heffalump.
Figure 3-8. Configuring Sanderz for recursive lookups enables the network administrator to redirect all of that router’s exit traffic from Heffalump to Woozle by changing one route entry.
With this configuration, all of Sanderz’s entries can be repointed through Woozle simply by changing the last static entry as in Example 3-35.
Example 3-35. Sanderz’s routing can easily be modified to forward all routes through a different next-hop router simply by changing one static route entry.
Sanderz(config)# ip route 10.87.14.0 255.255.255.0 10.23.5.95 Sanderz(config)# no ip route 10.87.14.0 255.255.255.0 10.23.5.20
Had all the static routes referenced 10.23.5.20 as the next-hop address, it would have been necessary to delete all 13 lines and type 13 new lines. Nevertheless, the effort saved in retyping static routes must be weighed carefully against the extra processing burden that recursive lookups put on the router.
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.
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.34—one 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.
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.
Verify not only that the path to a destination is good but also that the return path is good.
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 arpaThis 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.
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.
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:F1C0FEC0: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:1DE0The 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:1DE0Honeypot’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.
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:F1C0Packets 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.
For precise control over routing behavior in a network, static routing is a powerful tool. However, if topology changes are prevalent, the demands of manual reconfiguration may make static routing administratively unfeasible. Dynamic routing protocols enable a network to respond quickly and automatically to topology changes. Before examining the details of specific IP routing protocols, the general issues surrounding all dynamic protocols must be examined. The next chapter introduces dynamic routing protocols.
Description | |
|---|---|
arp ip-address hardware-address | Statically maps an IP type [alias] address to a hardware address. |
debug ip packet | Displays information on IP packets received, generated, and forwarded. Information on fast-switched packets will not be displayed. |
debug ipv6 packet | Displays information on IPv6 packets received, generated, and forwarded. |
ip cef | Enables Cisco Express Forwarding for IPv4. |
ip load-sharing {per-packet | per-destination} | Configures the type of load-sharing on an outbound interface. |
ip proxy-arp | Enables proxy ARP. |
ip route prefix mask {address | interface [next-hop-address]} [distance] [permanent] [name name] [tag tag-number] | Statically adds a route entry to the route table. |
ip route-cache | Configures the type of switching cache an interface will use for IPv4. |
ipv6 cef | Enables Cisco Express Forwarding for IPv6. IPv4 CEF must be enabled before IPv6 CEF can be enabled. |
ipv6 unicast-routing | Enables IPv6 routing. IPv6 routing is not enabled by default. |
ipv6 route prefix/prefix length {address | interface [next-hop-address]} [distance] [permanent] [name name] [tag tag-number] | Statically adds an IPv6 route. |
show cdp neighbor detail | Displays information about a neighbor router, including IOS version, and IPv4 and IPv6 interface configuration. |
show ip cef | Displays CEF forwarding cache or a message indicating CEF is not enabled. |
show ipv6 cef | |
show ipv6 cef {interface} detail | Displays whether CEF is enabled on an interface, among other things. |
show ipv6 interface {interface} | Displays interface and IPv6 specific interface information. |
show ip route | Displays the IP route table. |
show ipv6 route | Displays the IPv6 route table. |
Configure static routes for each router of the network shown in Figure 3-13. Write the routes so that every subnet of the Internet has an individual entry. | |
Rewrite the static routes created in Configuration Exercise 1 to use the minimum possible route entries.[8] (Hint: RTA will have only two static route entries.) | |
For the network shown in Figure 3-14, write static routes for each router. Assume that all links are identical media. Use load balancing on equal cost paths and floating static routes for maximum efficiency and redundancy. |
In the network of Figure 3-2 and the associated configurations, the route entries for Piglet are changed from Piglet(config)# ip route 192.168.1.0 255.255.255.0 192.168.1.193 Piglet(config)# ip route 10.4.0.0 255.255.0.0 192.168.1.193 to Piglet(config)# ip route 192.168.1.0 255.255.255.224 192.168.1.193 Piglet(config)# ip route 10.0.0.0 255.255.0.0 192.168.1.193 What is the result? | |
Example 3-59 shows the static route configurations for the routers in Figure 3-15. Example 3-59. Static route configurations for routers in Figure 3-15. !RTA ip route 172.20.96.0 255.255.240.0 172.20.20.1 ip route 172.20.82.0 255.255.240.0 172.20.20.1 ip route 172.20.64.0 255.255.240.0 172.20.20.1 ip route 172.20.160.0 255.255.240.0 172.20.30.255 ip route 172.20.144.0 255.255.240.0 172.20.30.255 ip route 172.20.128.0 255.255.240.0 172.20.30.255 _________________________________________________ !RTB ip route 172.20.192.0 255.255.240.0 172.20.16.50 ip route 172.20.224.0 255.255.240.0 172.20.16.50 ip route 172.20.128.0 255.255.240.0 172.20.16.50 ip route 172.20.160.0 255.255.240.0 172.20.30.255 ip route 172.20.144.0 255.255.240.0 172.20.30.255 ip route 172.20.128.0 255.255.240.0 172.20.30.255 _________________________________________________ !RTC ip route 172.20.192.0 255.255.240.0 172.20.16.50 ip route 172.20.208.0 255.255.255.0 172.20.16.50 ip route 172.20.224.0 255.255.240.0 172.20.16.50 ip route 172.20.96.0 255.255.240.0 172.20.20.1 ip route 172.20.82.0 255.255.240.0 172.20.20.1 ip route 172.20.64.0 255.255.240.0 172.20.20.1 Users are complaining of several connectivity problems in this internet. Find the mistakes in the static route configurations. | |
Figure 3-16 shows another network in which users are complaining of connectivity problems. Example 3-60 through Example 3-63 show the route tables of the four routers. Find the mistakes in the static route configurations. Example 3-60. The route table of RTA in Figure 3-16. RTA#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
10.0.0.0/8 is subnetted, 9 subnets
S 10.5.9.0 [1/0] via 10.5.3.2
S 10.5.8.0 [1/0] via 10.5.3.2
S 10.5.7.0 [1/0] via 10.5.3.2
S 10.5.6.0 [1/0] via 10.5.3.2
S 10.5.5.0 [1/0] via 10.5.3.2
S 10.5.4.0 [1/0] via 10.5.3.2
C 10.5.3.0 is directly connected, Serial0
C 10.5.2.0 is directly connected, TokenRing1
C 10.5.1.0 is directly connected, TokenRing0
RTA#Example 3-61. The route table of RTB in Figure 3-16. RTB#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
10.0.0.0/8 is subnetted, 9 subnets
S 10.5.9.0 [1/0] via 10.5.5.2
S 10.5.8.0 [1/0] via 10.5.5.2
S 10.5.7.0 [1/0] via 10.5.5.2
S 10.5.6.0 [1/0] via 10.5.5.2
C 10.5.5.0 is directly connected, Serial1
C 10.5.4.0 is directly connected, TokenRing0
C 10.5.3.0 is directly connected, Serial0
S 10.5.2.0 [1/0] via 10.5.3.1
S 10.5.1.0 [1/0] via 10.5.3.1
RTB#Example 3-62. The route table of RTC in Figure 3-16. RTC#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
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
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, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 8 subnets
S 10.5.9.0 [1/0] via 10.5.7.2
S 10.5.8.0 [1/0] via 10.5.5.1
C 10.5.7.0 is directly connected, Serial1
C 10.5.6.0 is directly connected, Ethernet0
S 10.1.1.0 [1/0] via 10.5.5.1
C 10.5.5.0 is directly connected, Serial0
S 10.5.3.0 [1/0] via 10.5.5.1
S 10.5.2.0 [1/0] via 10.5.5.1
RTC#Example 3-63. The route table of RTD in Figure 3-16. RTD#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
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
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, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 9 subnets
C 10.5.9.0 is directly connected, Ethernet1
C 10.5.8.0 is directly connected, Ethernet0
C 10.5.7.0 is directly connected, Serial0
S 10.5.6.0 [1/0] via 10.5.7.1
S 10.5.5.0 [1/0] via 10.5.7.1
S 10.4.5.0 [1/0] via 10.5.7.1
S 10.5.3.0 [1/0] via 10.5.7.1
S 10.5.2.0 [1/0] via 10.5.7.1
S 10.5.1.0 [1/0] via 10.5.7.1
RTD# |
[1] There is also the special case of a multicast address, which is destined for a group of devices, but not for all devices. An example of a multicast address is the class D address 224.0.0.5, reserved for all OSPF-speaking routers.
[2] There are two basic procedures for finding the best match, depending upon whether the router is behaving classfully or classlessly. Classful table lookups are explained in more detail in Chapter 5, “Routing Information Protocol (RIP),” and classless table lookups are explained in Chapter 6, “RIPv2, RIPng, and Classless Routing.”
[3] For the static routes in this example and the subsequent examples in this chapter to work properly, two global commands must be added to the routers: ip classless and ip subnet-zero. In IOS 11.3 and later, ip classless is enabled by default. These commands are introduced in Chapter 6 and are mentioned here for readers who wish to try the configuration examples in a lab.
[4] The key normally seen at the top of the route table (as in Figure 3-2) has been removed for clarity.
[5] The interface addresses are configured with EUI-64 addresses. The addresses, therefore, are unique to each router based on MAC address. To reproduce the configuration, you’d have to determine your router’s interface addresses to use as the next hop.
[6] This method of summarizing a group of major network addresses with a mask shorter than the default address mask for that class is known as supernetting. This is introduced in Chapter 6.
[7] Unless the Extended Ping utility is used to set the source address to something different.
[8] If this exercise is being implemented in a lab, be sure to add the command ip classless to all six routers.