All the information you need... in one place.

Our Founder's Book

Advanced IP Routing in Cisco Networks

Chapter 3 - Static Routes

Static routes are special routes that the network administrator manually enters into the router configuration. You could build an entire network based on static routes. The problem with doing this is that when (not if!) a network failure occurs, the static route will not change without you performing the change. This isn’t a good thing if the failure occurs during the middle of the night, or while you are on vacation.

This is why we’ve all heard the chant "Don’t use static routes!" However, there are many places where static routes are essential to a smoothly operating network. Careful use and placement of static routes may actually improve the performance of your network, allowing you to conserve bandwidth for important business applications. We’ll be covering the places where you would normally want to use static routes and where you shouldn’t.

Stub Networks

Stub networks are the ideal candidate for static routes. A stub network is like a dead-end street – there is only one link to the network. In Figure 3-1 there are two branches, each of which are stub networks. There is a LAN at each site, but there is only one link connecting them to headquarters.

**T165 Figure 3-1 Stub network.**

There is no need to run a routing protocol over the WAN links between NewYork and the branches. Static routes on NewYork direct traffic to the LANs at the branches (we’ll discuss redistribution of these static routes to other headquarters routers in a later chapter). Similarly, the branch routers at Tokyo and London don’t need to know about all the routes in the corporate intranet. The only thing a branch router needs to know is that if the packet isn’t for a network at the branch, the packet should be forwarded to NewYork, which has more complete routing information.

Figure 3-2 shows the static route configuration of NewYork and Tokyo. Lines 10 and 11 are the static routes in NewYork that reference the LAN at each branch. Line 19 is a default route in Tokyo (a route to network 0.0.0.0, which we will discuss in the next section) that points back to NewYork. London’s configuration is very similar to Tokyo’s, except for the hostname and the addresses assigned to the interfaces.

**T166 Figure 3-2 Static route configuration.**

There is another type of static route, called the interface static route. It is used when you want the destination network to look like it is attached to one of the router’s interfaces. The administrative distance for an interface static route is 0, which makes it equivalent to a directly connected network route.

Figure 3-3 shows changing the static routes in R1 to interface static routes. The interface static routes appear as if they were directly connected.

**T167 Figure 3-3 Interface static routes.**

Default Route

Simply stated, a default route is one that is used when no matching routing table entry is found. It appears in the routing table as a route to network 0.0.0.0 and you know it is set when the output of sho ip route contains an entry similar to the following entry at the top of the routing table:

Gateway of last resort is 192.168.4.1 to network 0.0.0.0

Any packet whose destination address is not matched by any specific routing table entry will take the path to the gateway of last resort. The gateway of last resort is a router that has more complete routing information and can hopefully forward the packet to its destination. If there is no default route and the packet’s destination address is not found in the routing table, then the packet is dropped and an ICMP ‘Destination or Network Unreachable’ is returned to the source IP address.

FYI: The term ‘gateway’ originated in the early 1980s, when the world of networking equipment consisted of bridges and gateways. Bridges connect media that use the same (or nearly the same) data-link protocols, such as Ethernet to Ethernet. ‘Gateway’ is the older term for a router and originated because it was the gateway through which one was able to send packets to a network that used different media and incompatible data-link protocols. In the late 1980s, the term ‘router’ was coined to reflect the function of routing packets to the proper destination. Today, the term ‘gateway’ refers to a networking component that converts a higher level protocol into a different higher level protocol. An example of this is a mail gateway that converts the OSI X.400 mail protocol into the Internet’s RFC822 protocol format. The older use of the term exists in a variety of places, including older RFCs, networking texts, and software. A review of RFC1009 [BRADEN and POSTEL 1987] clearly defines the terms ‘router’ and ‘gateway’.

We’ll see in later chapters how default routes can be propagated throughout an intranet via an interior routing protocol such as RIP, IGRP, OSPF, or EIGRP.

When It Is Used

As we’ve seen, default routes are very useful in stub networks. It is a way to eliminate the use of a routing protocol to stub networks where there is no other reason to run a routing protocol. Eliminating the use of a routing protocol saves WAN link bandwidth, router CPU processing, and router memory. In a large network containing hundreds of routes, a dynamic routing protocol may consume a significant amount of link bandwidth. Using the default route can mean using a link sized for the amount of user traffic instead of a link of much higher bandwidth. The monetary savings in using properly sized link bandwidths can be significant.

There isn’t much difference in the amount of work needed to configure a stub network using a dynamic routing protocol and a configuration using static and default routes. There is very little difference between using default and static routes for the stub network configuration and using a dynamic routing protocol. A dynamic routing protocol will require the listing of the network number to enable the protocol on the networks to which the router is attached. Similarly, the default and static routes require entering similar network numbers. Since a manual configuration of some part of the routing system is needed in each case, why not use the one that results in less link traffic and better performance? In both cases, the configuration and design justification need to be documented so that other members of the networking team know why one of the methods was chosen over the other and what to change if the network numbers on either end are changed.

How to Configure It

Configuring the default route only requires one statement:

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.4.2

The routing table will now include a static route to network 0.0.0.0 using a subnet mask of 0.0.0.0. The subnet mask is zero, because none of the bits in the IP address are used to identify the network number. Remember, it is the route to use (i.e. to match) when there is no specific route.

FYI: The entry for a default route looks strange in that both the network number and the mask are zero. Let’s see how this works within the router.

For a packet destined for 192.168.5.2, the router is going to look through its routing table to try to find a route that matches the network portion of this address. Since it is a class C network number, the mask that will be used is 255.255.255.0. There is no match in the routing table, so the router finally checks the last entry, the default route.

This route has a mask (set by the static route command) of 0.0.0.0. Recall, that the router uses the mask to determine how many destination IP address bits are network number and how many bits are ‘local’ (i.e. subnet and host). A ‘1’ is used in the mask for every bit to be used for network number and a ‘0’ is used for the ‘local’ portion of the address. Since the mask here is all zeros, the entire destination address is considered ‘local’.

The binary AND operation of the destination address turns all the bits of the destination address into ‘0’s. The comparison is then made against the network number of this static route, which is 0.0.0.0. A match occurs and the router uses the information in this routing table entry to forward the packet.

When the default route is properly configured, the router will have two important routing table entries. The first one appears before the routing table (Figure 3-4, line 9), where the gateway of last resort (another name for the default gateway) is reported. Looking at the routing table, we find the static route to the default network on line 13.

**T168 Figure 3-4 Default routing table entry.**

Lab Exercise

Configure each router in the pod with IP addresses. Make NewYork the headquarters router and Tokyo and London the branch routers. See Figure 3-5 for the network diagram. Either use the network addresses from the figure or select your own network numbers and assign IP addresses to each interface shown. Shutdown the other interfaces on each router.

**T169 Figure 3-5 Static and default route exercise network.**

Using ‘ping’ from NewYork, make sure you have connectivity to the serial interfaces on Tokyo and London. Try to ping their Ethernet interfaces. What happens? Issue the exec command debug ip packet and retry the ping. What do you see?

Add a static route to NewYork for Tokyo’s Ethernet via Tokyo’s serial interface IP address. Try to ping the Tokyo’s Ethernet IP address. Does ping now work? What is the debug output? On Tokyo, issue the exec command debug ip packet and rerun the ping test. What is reported? What kind of route is this?

On Tokyo, add a default route to NewYork and rerun the ping test. What does debug report? Does the ping work? Add the static route to NewYork and default route to London and test a ping from NewYork to London’s Ethernet.

Check that Tokyo and London can ping NewYork’s Ethernet interface. Look at the routing tables of each router to see the static and default routes.

Try the same experiment with interface static routes on NewYork. Check the routing table. Does the ping test work? Use debug to see what the router is doing while the ping is running.

Can Tokyo ping London’s interfaces and vice versa? If not, adjust your static and default routes in all three routers until they can.

Floating Static Routes

In mission critical networks (is anyone running a network that isn’t mission critical these days?), it is often important to have redundancy. This can be obtained with static and default routes too. The tool to use here is the administrative distance. With the configuration we just finished, let’s bring up the redundant serial link between Tokyo and London as shown in Figure 3-6 (assume that it could be an on-demand link, which we’ll cover later). Conceptually, the floating static route ‘attracts’ traffic to itself, but only if the primary path has failed. As long as a better route exists, the floating static route remains in the background, ready to take over if the primary path fails.

**T170 Figure 3-6 Floating static route network.**

Figure 3-7 shows the configurations we used on the test network to implement this. There are several important things to learn in this configuration. NewYork has two routes to Tokyo’s Ethernet. The first is via the direct link (line 11) and the second is a floating static route via London (line 12). The second route will only be used if the primary information disappears (most likely because the link went down.)

**T171 Figure 3-7 Implementing floating static routes.**

Tokyo has two default routes: one via the direct link to NewYork (line 26) and a floating default route via London (line 27). Finally, London has a default route to NewYork (line 42), demonstrating that the target of a default route may itself have a default route. Line 43 of London’s configuration has a floating static route to Tokyo’s Ethernet.

Configuration of floating static routes is most often seen in conjunction with an interior routing protocol. In our test network, we would likely be running a dynamic routing protocol in NewYork and London, with the floating static routes used to force the backup link to be used if a network failure occurs on the primary path between NewYork and Tokyo. In this scenario, the Tokyo to London link is normally down. London and NewYork both use the primary path (NewYork to Tokyo) to reach Tokyo’s Ethernet. If a failure occurs on the NewYork to Tokyo path, Tokyo becomes unreachable. A backup link is brought up between Tokyo and London, and traffic then takes this backup path.

Floating static routes are even simpler if the primary and secondary paths are on the same routers (NewYork and Tokyo in this case.) An example of this might be an ISDN backup link that is brought up if the primary link fails. The neat thing about floating static routes is that they can be implemented on different routers (i.e. a different router can be the backup path) as we see in using London to establish the backup path.

Lab Exercise

You can experiment with floating static routes by starting with the configurations from Figure 3-7. Try shutting down the primary path between NewYork and Tokyo. Enable debug ip packet debugging on all three routers and perform ping tests between NewYork and Tokyo with different combinations of up or down state of the links between NewYork and Tokyo and between Tokyo and London. Be sure to check the contents of the routing tables after shutting down the NewYork to Tokyo link.

Use trace to verify the path that the packets are taking. What happens to the routing tables when the NewYork to Tokyo link is shutdown? What happens to the routing tables when the Tokyo to London link is shutdown?

Default Network

Cisco routers have another command, ip default-network, that works along with the default route. This command tells the router to propagate the default route to other routers via IGRP or EIGRP. This allows other routers in the IGRP and EIGRP networks to learn the default route without manual configuration. The network specified in this command must be one that is being propagated via the routing protocol. Warning: if you forget to include the default-network target network in your routing updates, it will never be propagated via the routing protocol to other routers and you’ll never see it selected as the default route in them.

The syntax of the command suggests that it could be used instead of setting a default route as we did above. However, that’s not the case. The default-network command causes IGRP and EIGRP to advertise the default route to neighboring routers.

Other routing protocols, like RIP and OSPF, use different mechanisms to propagate the default route. We’ll cover how each protocol propagates default routes in later chapters.

Lab Exercise

Let’s see how static routes and default network work in the lab. The scenario is that an existing company has two sites connected via a 56K link. Each site has one Ethernet. The two sites are running IGRP between them, which is overkill for the two sites, but they are the test sites for an extensive company-wide rollout. You work for the local ISP and must help them with their router configuration modifications. The link to your ISP is 56K and you’ve recommended that they not run a routing protocol over the link.

The network is shown in Figure 3-8. NewYork and Tokyo are the two company routers. The starting configurations for all three routers are shown in Figure 3-9. We’ll test the configuration by pinging from NewYork and Tokyo to ISP’s E0, which is an external network number. If you’d like to make this a challenge lab, stop reading now and configure the routers on your own.

**T172 Figure 3-8 Default route lab.**

**T173 Figure 3-9 Initial default route lab configurations.**

The first step is to install the starting configuration (from Figure 3-9) in each router. Verify the routing tables to make sure that Tokyo and NewYork show their connected networks and IGRP routes to the Ethernets.

Next, let’s establish connectivity between NewYork and ISP. Add a default route in NewYork with ISP’s S1 interface as its target.

NewYork(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.34

Check the routing table (show ip route) to verify that the gateway of last resort is set. Use the command debug ip packet to enable debugging on NewYork and ISP and try a ping from NewYork to ISP’s E0. What do you see? To perform a better test, ping using NewYork’s S0 interface address as the source address (Figure 3-10).

**T177 Figure 3-10 NewYork to ISP ping output.**

This requires that the packet get to ISP and that ISP knows how to get back to NewYork’s internal address. What does the ping output show you?

On line 3 we set the IP address of ISP’s Ethernet interface. Using the extended ping function, on line 8 we specify the address of NewYork’s Ethernet interface. Line 18 – 21 shows the debug output of the packet being sent, so we know that the packet is not failing within NewYork. However, the period at the end of each of these lines indicates that the echo reply packet was not received. Since NewYork has a correct route to ISP, the problem must be in ISP’s configuration. As an experiment, turn on debug ip packet in ISP and repeat the ping test. How is its output different? What does it tell you? Use the command show ip route in ISP to see if it has a route back to NewYork.

Next, in ISP, add a static route to the three networks in our small company (192.168.1.0, 192.168.2.0, and 192.168.4.0). This should allow NewYork to ping ISP and get a reply, even when using the S0 interface address as the source address.

ISP(config)#ip route 192.168.1.0 255.255.255.0 172.16.1.33

Now, it is time to try the ping from Tokyo to ISP. What do you see? Is there a route in Tokyo to ISP’s E0? Why not? Should there be one? Use debug ip igrp transactions and examine the debug output (you’ll have to wait for updates to be generated, which are up to 90 seconds for IGRP.)

Hmmm, more work is needed. How about the default-network command? Add that to NewYork (telling it to identify 172.16.0.0 as the default network.

NewYork(config)#ip default-network 172.16.0.0

How does that change the routing updates? Does Tokyo now have a gateway of last resort set?

Checking the documentation, we find that the network specified in the default-network command must exist in the routing table, and Tokyo doesn’t have it there. Add network 172.16.0.0 to NewYork’s IGRP configuration. Don’t forget to add the passive interface s 0 command to IGRP to prevent it from consuming valuable link bandwidth on the NewYork to ISP link (ISP isn’t running IGRP, so any updates would be wasting bandwidth.)

NewYork(config)#router igrp 1NewYork(config-router)#network 172.16.0.0NewYork(config-router)#passive-interface s 0

Now, go back and check Tokyo’s routing table. Check the operation with ping. Make sure you also do a test ping with Tokyo’s E0 address as a source address. Since IGRP has a 90 second update timer, you may have to wait for several minutes for the proper routing information to appear in Tokyo’s routing table. This configuration only adds one route to your internal routing protocol, yet allows all the routers within the IGRP domain to route packets to any destination.

The final configuration for all three routers appears in Figure 3-11. Note that the only routers that had any configuration change were NewYork and ISP. In these routers NewYork has four additional commands and ISP has one additional command. No changes were needed in Tokyo, showing that the routers at the border to the network are the only ones that need to have configuration changes.

**T177 Figure 3-11 Final ISP routing configurations.**

For additional experience, remove the default route from NewYork and see what happens. Also try using a subnetted network on the NewYork and Tokyo networks (which is the more normal case – ISP would then only have a single static route.)

There are many other experiments you can do with this configuration. Check out distribution of the default route when you configure NewYork’s default route as an interface route:

ip route 0.0.0.0 0.0.0.0 int s 0

Is there any change when 172.16.0.0 is omitted from the IGRP configuration in this scenario? What happens when you use another routing protocol?

Multiple Default Routes

Regardless of the protocol, if more than one router is advertising a default network, then the metric and administrative distance from the neighboring routers to the advertising routers are used to determine which route is the best default. An example of this configuration is shown in Figure 3-12, in which NewYork and London are both connected to an ISP and are both advertising a default route (the use of Ethernets for these connections is irrelevant.) Tokyo will receive routing updates from both NewYork and London, but with different metrics (assuming that either the OSPF, IGRP, or EIGRP routing protocol is being used. RIP uses hop-count, which results in equal cost routes via either NewYork or London.)

**T174 Figure 3-12 Best default route.**

IGRP’s configuration for all three routers in this scenario is shown in Figure 3-13. The ISP "owns" the links connecting NewYork to ISP-NewYork and London to ISP-London. Configuration lines 16 and 49 are the default route in NewYork and London. Line 15 and 48 are the default network command in each. Both routers include the ISP’s network in their routing protocol configuration and use the passive interface command (which we’ll cover later) to eliminate the broadcast of IGRP routing information over the ISP links.

**T175 Figure 3-13 IGRP multiple default route configuration.**

Tokyo’s configuration only includes IGRP, through which it learns the default route. Since the link from Tokyo to NewYork is of higher bandwidth, IGRP will give it a better (lower) metric, as seen in Figure 3-14. Tokyo will use this route in its routing table and keep the path via London as a backup.

**T178 Figure 3-14 Multiple default routing tables.**

Debugging

Debugging static routes is relatively simple. The output of show ip route is the first step. But if floating static routes are in use, you will have to also examine the router’s configuration (show running-config is best, just in case the configuration hasn’t been written to NVRAM.)

Running ping and trace can give you valuable information in determining which routers have invalid routing information. If ping’s output includes several ‘U’s, then it is likely that some router along the path does not know how to forward the echo request packet. The best bet is to run a trace to the same destination. A likely culprit is a router that is sourcing a default route, but has no static default route itself.

Sometimes, running debug on a router and watching the packet processing is useful. However, don’t do this on a busy router – the CPU requirements for debugging high volumes of traffic will not leave any time left over to process your commands. Many a network manager (including ourselves) have done this at least once. It’s quite embarrassing to have to reset a router to regain control after enabling debugging on a very busy protocol. It is better to enable debugging on just the routing protocol. A good example of this is in the CCIE Tips section of Chapter 1.

CCIE Tips

The CCIE candidate should have a good understanding of static routes and their configuration and use in large networks. Besides handling stub networks, they are useful for tying together several large networks. In this case, just duplicate the configuration we used with the network of Figure 3-10. Each regional network connects to a backbone network that has routes back to each region. Therefore, the backbone has more complete routing information than the regions. The regions, in turn, have reduced routing tables, which reduces CPU and link utilization.

If you’re configuring dial-backup between the same routers that host the primary link, you should examine the Cisco documentation for its configuration. It doesn’t use routing techniques to activate the backup link, so the configuration is different than dial-on-demand. But if you need the backup link to be on a different router, you’ll have to use dial-on-demand techniques and floating static routes to implement it.

As we’ve done here, you should be able to eliminate routing updates over links to stub networks. Make sure you know how to configure the default network and how to propagate this network to other routers within the stub area. Learn how RIP, IGRP, EIGRP, and OSPF propagate the default route and how they react to having a default route sourced from a router in their area.

Summary

The biggest problem of static routing is that it requires manual configuration when the network changes. For some network topologies, this isn’t a problem, because a router’s configuration must be changed in any case.

The biggest mistake we’ve seen in operational networks is trying to fix dynamic routing problems by adding static routes. This is the road to major network failure and network staff overload. As the number of static routes increases, the effort to handle a single network link failure becomes larger and larger.

However, static routes applied in a knowledgeable way, at good places in the network, can reduce routing problems and routing traffic overhead. For example, use static routes in stub networks, where there is only one path available. Two paths can sometimes be accommodated, but the network topology must be examined to make sure that it will operate correctly when a network link or router fails.

Another place that static routes are valuable is in building very large networks in which large regions are connected via one or two major links. The isolation characteristics of static routes can help reduce the load of routing protocols over the entire network and limit the scope of routing changes and problems. We’ll discuss how to integrate static routes with dynamic routing protocols in the chapters on dynamic protocols.

Back to First Editon

 

• Legal Notice
• Privacy Policy
• Site Map
• Contact Us