Configuring Static Routes

 

The route table acquires information in two ways. The information may be entered manually, by means of a static route entry, or 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 to understand 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 we have over it. Although dynamic (automatic) routing requires much less human intervention, static routing allows very precise control over the routing behavior of an internetwork. The price to be paid for this precision is the necessity of manual reconfiguration any time the topology of the network changes.

Note

Discontiguous networks


Note

Variable subnetting


Case Study: Simple Static Routes

Figure 3.3 shows an internetwork with four routers and six networks. 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 internetwork. 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; static routes work fine here.

Figure 3.3. Routing protocols such as RIP and IGRP cannot easily route this discontiguous, variably subnetted internetwork, but static routing will work.

graphics/03fig03.gif

Note

The steps for creating simple static route configuration


The procedure for statically routing an internetwork has three steps:

  1. For each data link within the internetwork, identify all addresses (subnet or network).

  2. For each router, identify all data links not directly connected to that router.

  3. For each router, write a route statement for each data link 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 internetwork in Figure 3.3 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. The commands for entering Piglet's static routes are as follows: [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 . These commands are introduced in Chapter 7 and are mentioned here for readers who wish to try the configuration examples in a lab.

 
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, the route entries for the other three routers are:

 
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 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 static routes specifies the interface out of which a network is reached instead of the address of the next-hop router. For example, the route entries for Tigger could be as follows:

 
Tigger(config)# ip route 192.168.1.0 255.255.255.224 S0
Tigger(config)# ip route 10.1.0.0 255.255.0.0 E0
Tigger(config)# ip route 10.4.7.0 255.255.255.0 S1

Figure 3.4 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 networks 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.

Figure 3.4. 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]

graphics/03fig04.gif

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

A point of interest in Figure 3.4 is that the header for the 10.0.0.0 subnets indicates the variable subnet masks used in the internetwork. Variable Length Subnet Masking (VLSM) can be a useful tool and is discussed at length in Chapter 7.

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 case study uses 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.3, 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:

 
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

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 is all that is needed:

 
Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1.66
Pooh(config)# 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: [5]

[5] 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 supermetting and is introduced in Chapter 7.

 
Eeyore(config)# ip route 192.0.0.0 255.0.0.0 10.4.6.1
Eeyore(config)# ip route 10.1.0.0 255.255.0.0 10.4.6.1

By 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 8, "Enhanced Interior Gateway Routing Protocol (EIGRP)," and 9, "Open Shortest Path First."

Case Study: Alternative Routes

In Figure 3.5, 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:

 
Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1.66
Pooh(config)# ip route 10.0.0.0 255.0.0.0 192.168.1.34
Pooh(config)# ip route 10.4.7.25 255.255.255.255 192.168.1.66
Figure 3.5. A more direct path from Pooh to the 10.4.0.0 subnets is added to the internetwork.

graphics/03fig05.gif

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 (Figure 3.6) 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.

Figure 3.6. Debugging verifies that the new route entries at Pooh are working correctly.

graphics/03fig06.gif

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 may initially 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 may or may not be desired, but it does illustrate two characteristics of static routes. First, if the internetwork topology changes, the routers that are required to know about those changes must be reconfigured; and 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. A more efficient configuration is:

 
Pooh(config)# ip route 192.168.1.192 255.255.255.224 192.168.1.66
Pooh(config)# ip route 10.0.0.0 255.0.0.0 192.168.1.34
Pooh(config)# ip route 10.1.0.0 255.255.0.0 192.168.1.66
Pooh(config)# 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 not permanently entered in the route table; it appears only under the special circumstance of the failure of a more-preferred route.

In Figure 3.7, a new router (Rabbit) is connected to Piglet via their respective Serial 0 interfaces, but a new 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.7. A new router has been connected to Piglet. Two serial links are used ”one for the primary link and one for the backup link.

graphics/03fig07.gif

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 to point not only to 10.1.5.0 but also to all of the new subnets used in association with the new router.

 
ip route 10.1.0.0 255.255.0.0 192.168.1.194

To create the floating static route, Piglet's route entries are as follows:

  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.1   ip route 10.1.30.0 255.255.255.0 10.1.20.1 50  

And Rabbit's route entries are:

  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.

Note

Administrative distance


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, 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 latter ”with the lower administrative distance ”will 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. Figure 3.8 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)

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

graphics/03fig08.gif

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: 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 , also known as load balancing , 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.

  • Unequal-cost load sharing distributes packets among multiple paths with different metrics. The traffic is distributed inversely proportional 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.7 for load sharing using static routes, Piglet's route entries are:

  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.1   ip route 10.1.30.0 255.255.255.0 10.1.20.1  

and Rabbit's route entries are:

  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 preceding section for floating static routes, except both links now use the default administrative distance of 1. Rabbit's route table, shown in Figure 3.9, now has two routes to each destination.

Figure 3.9. This route table indicates that there are two paths to the same destination networks. The router will balance the load across these multiple paths.

graphics/03fig09.gif

Load sharing is also either per destination or per packet.

Per Destination Load Sharing and Fast Switching

Per destination load balancing distributes the load according to destination address. Given two paths to the same network, all packets for one destination on the network 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 type of load balancing occurs in Cisco routers when they are fast switching , the default Cisco switching mode.

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, and 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 are routed out the same interface. When a packet addressed to a different host on the same network enters 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

Per packet load sharing means that one packet to a destination is sent over one link, the next packet to the same destination is sent over the next link, and so on, given equal-cost paths. If the paths are unequal cost, the load balancing 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. Cisco routers will do per packet load balancing when they are 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 .

In Figure 3.10, 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.

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

graphics/03fig10.gif

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.

Case Study: Recursive Table Lookups

All route entries do not necessarily need to point to the next-hop router. Figure 3.11 shows a simplified version of the internetwork of Figure 3.7. In this internetwork, Pooh is configured with:

  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  
Figure 3.11. To reach network 10.1.30.0, Pooh must perform three route table lookups.

graphics/03fig11.gif

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.12 shows an example of an instance in which recursive lookups may 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.12. 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.

graphics/03fig12.gif

With this configuration, all of Sanderz's entries can be repointed through Woozle simply by changing the last static 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.



Routing TCP[s]IP (Vol. 11998)
Routing TCP[s]IP (Vol. 11998)
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 224

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