2.7 Using IP Unnumbered
2.7.7 Using a different subnet mask and a different major net
Using a different major network with no subnet masking on both routers gives similar results to a proper configuration that uses the same major network and the same subnet mask. In the case of different major networks, the routers simply advertise their summarized routes to each other. Each router installs the other's summarized route, and full connectivity is possible.

To avoid repetition, this section begins with a misconfiguration of IP unnumbered. Recall that a misconfiguration of a subnet mask using the same major net on both routers causes connectivity to be broken. In this scenario, connectivity is still possible but the misconfiguration results in some other problems.

A different major network --- 168.72.0.0 --- has been configured on RouterC's Ethernet interface; see the main figure. In addition, a subnet mask has been added --- 255.255.255.0. RouterA still has its original IP unnumbered address of 168.71.5.1 255.255.255.0. Using a subnet mask on both major nets is a violation of the IP unnumbered rule that states as follows: When using different major nets, no subnetting is allowed.

The remainder of this scenario shows how connectivity is still possible even though IP unnumbered has been misconfigured. It also further explains the problems caused by violating the no subnet mask rule.

In the show interface command from RouterC, you can see that the new major network has been configured with a subnet mask. (see RouterC#show interface ethernet 0 command output)

In the output of the show interface command from RouterA, you can see that RouterA has the same IP unnumbered configuration as before. (see RouterA#show interface serial 1 command output)

In the output of the debug ip packet commands from routers A and C, you can see the two routers sending and receiving routing updates. Note that a subnet route and a summarized route are sent in both cases. (see RouterA#debug ip rip and RouterC#debug ip rip commands outputs).

In the routing table from RouterA, note the mask on the subnet route to 168.72.8.0, which is 255.255.255.255. (see RouterA#show ip route command output). This is a host route. If RouterA received a packet destined for 168.71.8.2 on its Ethernet interface, the longest match comparison with the route to 168.71.8.0 would fail. This would occur because the mask associated with the route (255.255.255.255) indicates that in order to match this route, the last octet of the destination IP address should be a 0.

Connectivity is still possible because RouterA has installed a summarized route to 168.72.0.0. RouterA installs this route because it does not have a local connection to 168.72.0.0.

In the show ip route command from RouterA, you can see that RouterA will use the summarized major network to route packets destined for 168.72.8.1. RouterA uses this network because the mask on 168.72.8.0 is 255.255.255.255. Even though it looks like a better longest match, it isn't because it has a host mask of 32 bits. (see RouterA#show ip route 168.72.8.1 command output).

The output from RouterA, which shows it pinging 168.72.8.1, proves that it has connectivity to RouterC because the pings are successful. (see RouterA#ping 168.72.8.1 command output)

In the routing table from RouterC, note the mask on the subnet route to 168.71.5.0. (see RouterC#show ip route command output). Connectivity is still possible because RouterC has installed a summarized route to 168.71.0.0. RouterC does so because it does not have a local connection to 168.71.0.0, as discussed previously.

In the show ip route  command from RouterC, you can see that RouterC will use the summarized major network to route packets destined for 168.71.5.1. It will do so because the mask on 168.71.5.0 is 255.255.255.255. Even though it looks like a better longest match, it isn't because it has a host mask of 32 bits. (see RouterC#show ip route 168.71.5.1 command output).

The output from RouterC, which shows it pinging 168.71.5.1, proves that it has connectivity to RouterA because the pings are successful. (see RouterC#ping 168.71.5.1 command output).

Note that the previous step of pinging RouterA from RouterC to prove connectivity in this direction was redundant because the pings from RouterA had the source address 168.71.5.1 and the destination address 168.72.8.1. RouterC was able to send ping replies to 168.71.5.1, so there was little doubt that RouterC would be able to originate pings to the same address. However, it never hurts to double-check when you aren't sure.