7.4 The 0.0.0.0 Default Route
7.4.2 Scenario
In the following scenario, assume that corporate policy dictates that users connected to router B have access only to the corporate network. One way to prevent them from accessing the rest of the world is for router B to install a gateway of last resort to 0.0.0.0 pointing to null0. Every packet that router B receives for networks and subnetworks that it has no explicit knowledge of would be routed to null0.

The partial configuration from router B shows how this is done. (see RouterB#show running-config command output).

However, router B would advertise that it had a route to the preferred RIP gateway of last resort to router A and router C (see Figure ).

In Figure , router D has the "real" connectivity to the rest of the world and should be the only router advertising the route to 0.0.0.0. However, you now have a problem because both router D and router B are telling router A and router C that they have valid routes to all unknown networks.

The partial configuration from router D shows its usage of 0.0.0.0. (see RouterD#show running-config command output).

In the routing table from router A, you can see that router A has installed two routes to 0.0.0.0. (see RouterA#show ip route 0.0.0.0 command output).

Figure shows how the routes map onto the network topology.

Both routes have the same metric, so they are treated as parallel equal-cost paths. Figure shows router A load sharing pings over the two links.

In the output from router A pinging 132.10.10.1 --- an address that lives in the rest of the world --- you can see that 40 percent of the pings are lost. These are the ones sent to router B. (see RouterA#ping 132.10.10.1 command output). 

This is a classic case of a misconfigured default route. You can prove this by configuring a static route in router A to 0.0.0.0 via one path and testing it with pings. Then do the same with the other path. The static route overrides the dynamic route to 0.0.0.0. The one that works for 100 percent of the pings is the correct path, and the one that fails completely is the broken path.

In Figure , you can see the path that router C has installed for 0.0.0.0.

The routing table from router C shows the single route to 0.0.0.0 via router B. (see RouterC#show ip route 0.0.0.0 command output).

Note that the metric is 1. The other route via router D would have a metric of 2. In Figure , you can see the path pings take for 132.10.10.1 from router C.

In the output of router C pinging 132.10.10.1, you can see that 100 percent of the pings fail. (see RouterC#ping 132.10.10.1 command output).

This proves that router C is attempting to use the incorrect route to the gateway of last resort via router B because it has a lower metric than the path advertised from router D via router A.

Having discovered that, in this case, router B is causing the problem, your fix is to stop router B from advertising the route for 0.0.0.0 to any other routers. Figure shows the places the advertisements for 0.0.0.0 need to be blocked.

The partial configuration from router B shows how to do this. (see RouterB#show running-config command output).

The access-list 1 denies the default route of 0.0.0.0 with the mask of 0.0.0.0, while allowing all other routes with the permit all statement of 0.0.0.0. Remember that all access lists have an implicit deny all at the end. If the goal is to permit some traffic that doesn't meet the test cases earlier in the access list, the final visible line of the access list must permit the traffic to flow. The implicit deny all remains as the last line. Some people add an explicit deny all of 255.255.255.255 0.0.0.0 at the end of access lists to remind themselves of the final deny all issue.

The output of debug ip rip was captured before the configuration to block 0.0.0.0 was added. (see RouterB#debug ip rip (1) command output).

The following output of debug ip rip was captured after the configuration to block 0.0.0.0 was added. (see RouterB#debug ip rip (2) command output).

As you can see, the access list worked. In the following output from router A pinging 132.10.10.1, you can see that they are now 100-percent successful. (see RouterA#ping 132.10.10.1 command output).

In the output from router C pinging 132.10.10.1, you can see that they are now 100 percent successful. (see RouterC#ping 132.10.10.1 command output).

Remember that the goal of this scenario was to create an IP network routing plan that prevented the hosts on 168.71.8.0 and 168.71.97.0 from reaching any hosts on networks that router B did not have explicit routes for.

The original problem was that router B was installing the dynamic route for 0.0.0.0 from router D and then advertising it to the rest of the network. To fix this problem, a static route to 0.0.0.0 pointing at null0 was configured in router B. This fixed the original problem but created a new problem.

The new problem was that router B started advertising its static route for 0.0.0.0 to the rest of the network. This caused some hosts to install this route instead of, or in conjunction with, their original route to 0.0.0.0, which was being advertised by router D. The routers using only the router B route to 0.0.0.0, therefore, lost all connectivity to the outside world. Routers that installed the router B route to 0.0.0.0 in conjunction with the router D route lost 50 percent of their connectivity to the rest of the world.