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