2.7 Using IP Unnumbered
2.7.6 Examples of routing updates
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.