interfaces can only have an administrative
distance of 0.
Content 5.2
Troubleshooting Static Routes 5.2.4 Static
route optimization with Ethernet networks Configuring
static routes without recursive lookups can also be done over
multi-access networks like Ethernet. In this instance, using
only an exit-interface instead of an intermediate address
causes a problem. Because the network is multiaccess, there
most likely are multiple devices, receivers, and so on, sharing
this network. Figure shows a network between RouterA and
RouterB that is a multiaccess, Fast Ethernet link. A static
route using only an intermediate address could be configured.
However, this will cause a recursive routing table lookup.
Figure shows both the static route command and its installment
in the routing table. When packets need to be routed for
172.16.1.0/14, the recursive route lookup happens first for the
172.16.1.0 network, and then for the intermediate address, with
the lookup of 172.16.2.0 network. In order to avoid the
recursive route lookup, the solution is to use both an
intermediate address and an exit interface. Figure shows the
recommended way to configure a static route in this case, and
the routing table entry. When using both the intermediate
address and the exit interface, only a single lookup is needed
in the routing table lookup process. The standard rule-of-thumb
when configuring static routes is to use an exit interface over
point-to-point and exit interfaces with the intermediate
address over multiaccess networks. This will avoid the
recursive route lookups caused by static routing entries that
only contain an intermediate address.
Content
5.2 Troubleshooting Static Routes
5.2.5 Recurring static route installation and
deletion The static routing process will check the routing
table every minute to install or remove any static routes.
There are circumstances where this can lead to a recurrence of
route installation and deletion. An interesting but problematic
condition can occur when the installation of a new static route
affects the resolvability of its own intermediate address. At
first, the 20.1.0.0/16 route is installed in the routing table
and the intermediate address of 20.2.0.2 is resolved using the
default route. However, the classful routing table lookup
process does not allow a default route to resolve intermediate
addresses. After 60 seconds, the next time the static route
process is scheduled to run, it will remove this route. In
another 60 seconds, the static route process will install the
static route back into the routing table, again using the
default route to resolve the intermediate address of 20.2.0.2.
This process of adding and deleting this static route is
repeated every 60 seconds. Notice the times in the
debug output. This is also a demonstration of how the
static route process is implemented every 60 seconds. This
situation can create even more instability if there are other
static routes resolved by this route. One solution is to always
configure static routes to use exit interfaces instead of
intermediate addresses wherever possible.
Content
5.2 Troubleshooting Static Routes
5.2.6 Using discard routes An example of a
typical customer network is shown in Figure . The Customer
Network is using a dynamic routing protocol to route the
172.16.0.0/24 and 192.168.1.0/24 traffic within its own
network. The Customer Network also includes the Remote Office
with the 172.16.4.0/24 and 192.168.1.0/24 networks. On RTA
there is a 0.0.0.0/0 default route configured, sending all
default traffic to ISP. RTA propagates this default route to
all other routers in the Customer Network via a dynamic routing
protocol. There is no dynamic routing protocol being used
between RTA, the Customer Network entrance router, and the ISP
router. The ISP router has two static routes pointing to RTA
for 172.16.0.0/16 and 192.168.1.0/24 networks. All of the
networks are up, and there is complete reachability throughout
the network and with the ISP. However, there is the potential
for a routing loop problem. Figure shows that the network
between RTB and RTC fails. The Remote Office networks of
172.16.4.0/24 and 192.168.1.0/24, are no longer reachable from
the Central Office. After the routing tables are updated, where
would RTA or RTB forward packets destined for the 172.16.4.0
network? If the routers are configured for classless routing
behavior, ip classless, RTB will forward all packets
destined for 172.16.4.0/24 and 192.168.1.0/24 to RTA using the
default 0.0.0.0/0 route. RTA will also use the default route to
forward those packets onto the ISP router. Figure shows an
example of pings being rerouted from RTA to ISP, once RTA has
removed the 172.16.4.0/24 network from its routing table. What
does the ISP router do with these packets for 172.16.4.1? Since
the ISP router has a static route for the 172.16.0.0/16
network, forwarding traffic to RTA, ISP will send those packets
destined for the 172.16.4.0/24 network back to RTA. RTA will
receive the packets from ISP and forward them back to ISP,
still using its default route. Figure shows the effect of this
routing loop on RTA serial interface as it sends and receives
these packets (pings in this example) on the link it shares
with the ISP. This problem has now created a blackhole in the
network, with a routing loop between RTA and ISP. The packets
will eventually be dropped once the time-to-live (TTL) field in
the IP headers gets decremented to 0. Solution 1: Classful
Mode Routing (no ip classless)
One solution is to
change the routing behavior from classless to classful using
the command, no ip classless on all of the Customer
Network routers. Classful routing would cause a router
searching its routing table for a best match for 172.16.4.0 to
drop the packets if there are routes for other 172.16.0.0/24
subnets, but not for 172.16.4.0/24. With the no ip
classless command, the router does not use any supernet or
default routes when the there is at least one known subnet. The
packets for 172.16.4.0 would be dropped by RTA and RTB. This is
usually not the preferred solution because it changes the
routing table lookup behavior for all packets. Packets destined
for a discontiguous subnet that rely on a supernet or default
route to be forwarded would also be dropped, unless that route
is specifically in the routing table. In addition, this does
not solve the problem for packets destined for
the192.168.1.0/24 network. Even with using the no ip
classless command, all packets destined for 192.168.1.0/24
will still be caught in a routing loop between RTA and ISP. In
any case, modifying the route lookup process with no ip
classless is not always an ideal solution as it might have
unforeseen affects on the routing behavior in the network.
Solution 2: Using a Discard Route
A more elegant and
scalable solution is to use a discard route. A discard route is
a route that sends packets to null0, the bit-bucket, when there
is no specific match in the routing table and it is undesirable
to have those packets forwarded using a supernet or default
route. Figure shows an example of a discard route for RTA. This
route will cause RTA to drop all packets for subnets in the
172.16.0.0 network, that do not have a specific route in the
routing table. Using the failed route example and still using
classless routing (ip classless), any 172.16.0.0 packets not
matching 172.16.1.0/24 or 172.16.2.0/24 or 172.16.3.0/24 or
172.16.4.0/24, would be routed to null0, using the discard
route. RTA would drop these packets instead of forwarding them
to ISP. The discard route will also keep traffic with wrong IP
addresses from finding this blackhole in the network. Any
packets that are incorrectly sent to nonexistent 172.16.0.0/16
subnets, such as the 172.16.5.0/24 subnet will also be dropped
by the RTA discard route. Packets destined for
192.168.1.0/24
For any packets destined for the
192.168.1.0/24 network from RTA or RTB, using classful mode