|
The output of the debug ip routing and ip
rip commands from RouterA shows what happens when RouterA adds the
subnet route to 168.71.8.16. Note the statement indicating that network
168.71.0.0 is now variably masked. This is in response to RouterA
comparing the routing update to its IP address and mask on ethernet 0.
Note also that RouterA believes that the next hop address for 168.71.8.16
255.255.255.255 is 168.71.8.17. (see "RouterA -- Viewing a routing
update" output).
RouterA has now installed a host route to
168.71.8.16 in its routing table because the advertisement received from
RouterC had bits set in what RouterA believes is the host portion of the
address.
RouterA's mask for the 168.71.0.0 network
is 255.255.255.0. The advertisement was for 168.71.8.16. The 16 in the
fourth octet should not be there for a routing advertisement of a subnet
with a 255.255.255.0 mask. Routers use the mask of the interface that
received the update to determine the appropriate mask to apply. (see RouterA#show ip route
command output).
Host Route Problem
The output of the show ip
route command and the routing table from RouterA shows that RouterA
does not have a route it can use for a packet to 168.71.8.17. Even though
it has a route to 168.71.8.16, the subnet that the host address of
168.71.8.17 should be on, RouterA does not have such a route because the
route to 168.71.8.16 is a host route. (see RouterA#show ip route 168.71.8.17
and RouterA#show ip route 168.71.0.0
command outputs).
When RouterA does a longest match lookup
for the destination IP address 168.71.8.17 in its routing table, the mask
associated with the route determines the number of bits that must match.
In the case of its route to 168.71.8.16, all 32 bits would have to match
exactly because the mask is 255.255.255.255. 168.71.8.16 and 168.71.8.17
are different at the 32nd bit and are therefore not a match.
The routing table also shows that RouterA
does not have a summarized route to 168.71.0.0, even though RouterC is
advertising it.
Lost Routes Problem
In the routing table from RouterC,
you can see that RouterC has a route to 168.71.5.0, which it uses to route
packets destined for 168.71.5.1 (see RouterC#show ip route
command output)
In the output of the debug ip
packet command from RouterC, you can see that RouterC sends the pings
destined for 168.71.5.1 out serial 1. Note that the source address of the
pings is 168.71.8.17. This is the host address that RouterA cannot reach
because the route it should use to the subnet of 168.71.8.16 has the wrong
mask/ (see "RouterC Ping Router A" output).
The output from the debug ip
packet command on RouterA shows that RouterA receives the pings from
RouterC but cannot route the responses. Configuring IP unnumbered
incorrectly by applying a different mask on RouterC's Ethernet interface
has made connectivity between the two routers impossible. (see RouterA#debug ip packet
command output).
This section has explained why IP
unnumbered requires that the same mask be used on all subnets of the same
major net. When a different mask is used, routers cannot properly derive
the masks for routes they receive. Instead, they resort to installing host
routes for these advertisements. As this section has proven, host routes
do not allow for full IP connectivity. The next section explains how IP
unnumbered works with different major networks.
|