An example of a 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.
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 routing, the
no ip classless command, would not help. Since this network
is not a subnet of a parent network in the routing tables of RTA or RTB, the
default route would be used whether or not classful mode routing is used. Once
192.168.1.0/24 is no longer reachable, this route would be removed from the
routing tables of RTA and RTB. RTA would eventually forward all packets to ISP.
Once again, the ISP would send these packets back to RTA, causing another
blackhole.
The solution is to configure another discard route that will
only be used if the primary route fails. This can be done by modifying the
default administrative distance of the static route to a value higher than the
administrative distance of the dynamic routing protocol being used. It is even
better to use an administrative distance value greater than any IGP routing
protocol, so it will not matter which routing protocol is used. In many cases,
the networks can be summarized within a single supernet covering the entire
range of the network, without including those routes outside the network.
RTA(config)#ip route 192.168.1.0 255.255.255.0 null0
200
The discard route would only enter the routing
table for RTA, when the dynamic route to 192.168.1.0/24 is removed. Figure
shows how the
discard route is installed in the routing table, only after the dynamic route
is removed due to the link between RTB and RTC going down.