7.3 Static Routes and Gateways of Last Resort
7.3.3
Dealing with too much default routing information
One of the problems designers of IP networks face is too much default information. By using a route --- in this scenario, 10.0.0.0 --- as both a gateway of last resort for nonlocal domain routes and a route for unknown subnets of the local domain, packets for networks that do not exist will end up at the router that is advertising this route.

This router can forward the packets to its own gateway of last resort --- assuming it has one --- or drop the packet as unroutable. The problem with dropping the packet is that the router may want to send an Internet Control Message Protocol (ICMP) host or network-unreachable message for each unroutable packet. This can cause significant overhead if several network users are creating packets for routes that do not exist. That is why Cisco routers send only one ICMP host-unreachable message back to the original host for each group of packets that arrive within a short time period.

The following problems can lead to packets arriving for unreachable destinations:

  • Incorrectly typed IP addresses in connection attempts for applications, such as Telnet and File Transfer Protocol (FTP); routers forward these via their default routes until their Time To Live (TTL) expires or a router drops them as unroutable
  • Bookmarks in Web browsers for sites that no longer exist
  • Traffic to Domain Name Systems (DNSs) that no longer exist. DNS servers are specified by an IP address, not a name; any change in their IP address can affect the many users who have been using this address to resolve names

In networks with thousands of users, these kinds of packets happen all the time. One solution is to configure a route to the null0 interface. This is similar to /dev/null in UNIX. It is a legitimate interface that accepts the packets and then throws them away. No ICMP host or network-unreachable messages are sent for packets forwarded to null0.

In the scenario shown in the main figure, the routing policy for the network containing routers A, B, C, and D states that no other routers can advertise dynamic routes into this network. This creates a problem because 168.71.29.0 exists outside of this network, even though it is from the local domain address space of this network.

The situation shown in the main figure can happen when a branch of a company has been moved to another region and has to use a third-party network, such as the Internet, to reach the original corporate site. Ideally, the hosts on this network would have been readdressed, but sometimes connectivity must be provided because there is not enough time to readdress. This situation is resolved by configuring a redistributed static route to 168.71.29.0 in router D.

In the main figure, router D has a redistributed static route to 168.71.29.0 pointing at 179.12.8.2. Routers A, B, and C will use this route, which they learned via IGRP, to forward packets for hosts on 168.71.29.0 in the direction of router D.

Router D has a redistributed static route to 10.0.0.0 that points at 179.12.8.2. This route is also tagged as a candidate default. Routers A, B, and C use this route, which they learned via IGRP, to forward packets for hosts on subnets in other major network domains in the direction of router D. All packets arriving at router D for subnets of 168.71.0.0 that router D doesn't know about are sent to null0 because of the static route of 168.71.0.0 255.255.0.0 null0 that router D has configured.

One consequence of using static routes is that routers forward packets toward the next-hop router, even when the physical network that the static route points to is not operational. In the main figure, router D forwards packets for hosts on 168.71.29.0 to the next hop of 179.12.8.2, even if the physical network that 168.71.29.0 is assigned to is down. As long as they have a route, these packets continue to be forwarded from router to router until they reach a router that has learned via a dynamic routing protocol (not a static route) that subnet 168.71.29.0 is no longer reachable.

If all the WAN links between router D and the router with 168.71.29.0 attached to it in the main figure were high-speed connections, there would be little or no point in attempting to prevent these packets from being forwarded.

On the other hand, if the link between router D and the rest of the world were only 56 kilobits and usually running at 95–99 percent, it would be useful to prevent these unnecessary packets from flowing across the link. That way, other packets could use the extra bandwidth. However, as previously stated, the policy in this network indicates that no dynamic routes are allowed in from the rest of the world; therefore, nothing can be done. This is a common trade-off network administrators have to face every day.

This scenario brings up an interesting issue. If a router receives a packet for a subnet it has a connection to and that connection is inactive, the router could forward the packet to a gateway of last resort or a local domain static route. In order for the router to use the gateway of last resort, the subnet on the inactive interface must not be part of the router local domain. If the subnet in question were part of the local domain, the router would forward the packet only if it had a valid local domain default route configured.

Consider what would happen if the router with the inactive interface had the only connection to the LAN that 168.71.29.0 was assigned to. The packets to hosts on 168.71.29.0 (which the router would be forwarding to its gateway of last resort or local domain default route) would still be forwarded by every other router that they encountered with the same default routes until their TTL values expired.

In other words, packets with no chance of reaching their destinations would travel aimlessly around the network until they die. To make matters worse, if the inactive LAN has a lot of popular Web servers or other IP hosts on it, thousands of packets could be roaming around the network wasting bandwidth.

A solution to this issue is to configure a static route to null0 for every subnet a router has an attachment to. This static route must have an administrative distance greater than the distance value associated with any dynamic IP routing protocol that might provide a viable alternative route. In this scenario, the following command would fix the problem: ip route 168.71.29.0 255.255.255.0 null0 200.