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

Discard routes can also be useful for blocking packets with private addresses (RFC 1918 address space) from being routed out of the network.