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