Configuring Static Routes

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.

Case Study: Simple IPv4 Static Routes

Figure 3-2 shows a network with four routers and six data links. Notice that the subnets of network 10.0.0.0 are discontiguousthere 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 subnettedthe 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:

1.	For each data link within the network, identify all subnet or network addresses.
2.	For each router, identify all data links not directly connected to that router.
3.	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]

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

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#

^[4] The key normally seen at the top of the route table (as in Figure 3-2) has been removed for clarity.

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 appears as a route with a distance of 1, not 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.

Case Study: Simple IPv6 Static Routes

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

Example 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:1DE0

Figure 3-3 shows a simple network with IPv6 addresses.^[5]

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

Figure 3-3. Static routing also works with IPv6.

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 ::, Null0

The 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/0

One thing to notice in the route table is the administrative distance of the static route configured with an exit interface. The distance is 1, unlike IPv4 static routes configured the same way. The route does 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.

Case Study: Summary Routes

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.

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

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:f1c0

By summarizing a group of subnets or even major networks, the number of static route entries may be reduced drasticallyin 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."

Case Study: Alternative Routes

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.

Figure 3-4. A more direct path from Pooh to the 10.4.0.0 subnets is added to the network.

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.

Case Study: Floating Static Routes

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

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

For example, IPv4 static routes pointing to a next-hop address have an administrative distance of 1, and static routes referencing an exit interface have an administrative distance of 0. If two static routes point to the same destination, but one references a next-hop address and one references an exit interface, the latterwith the lower administrative distancewill be preferred.

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.

Case Study: IPv6 Floating Static Routes

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.

Case Study: Load Sharing

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:F1C0

Load sharing is also either per destination or per packet.

Load Sharing and Cisco Express Forwarding

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.

Per Destination Load Sharing and Fast Switching

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.

Per Packet Load Sharing and Process Switching

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.

Note

The debug ip packet command displays only process switched packets.

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.

Which Switching Method Will Be Used?

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.

Table 3-1. IOS switching determination is based on configuration of inbound and outbound interfaces.
Inbound Configuration	Outbound Configuration	Switching Method Used
CEF	Process	CEF
CEF	Fast	CEF
Process	CEF	Fast (or process if IPv6)
Process	Fast	Fast
Fast	CEF	Fast (or process if IPv6)
Fast	Process	Process

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.

Case Study: Recursive Table Lookups

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.

Figure 3-7. To reach network 10.1.30.0, Pooh must perform three route table lookups.

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.