Configuring IP Unnumbered on Serial Interfaces

Configuring IP unnumbered for RIP and IGRP is done in the same way as explained previously. The excerpts from the configurations of RouterA and RouterC that follow show how to configure IP unnumbered on a serial interface.

!
hostname RouterA
!
interface serial1
ip unnumbered Ethernet0
!
!
hostname RouterC
!
interface serial1
ip unnumbered TokenRing0
!

The following show interface commands from RouterA and RouterC show that IP unnumbered is now in use on both serial interfaces.

RouterA#show interface serial 1
Serial1 is up, line protocol is up
 Hardware is HD64570
 Interface is unnumbered.  Using address of Ethernet0 (168.71.5.1)
 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255

RouterC#show interface serial 1
Serial1 is up, line protocol is up
 Hardware is HD64570
 Interface is unnumbered.  Using address of TokenRing0 (168.71.8.1)
 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255

RIP and IGRP Behave the Same

The rules governing the successful configuration of IP unnumbered that were given at the start of this chapter apply to RIP V1 and IGRP equally. When properly configured, both protocols behave in the same manner. All of the material presented in the following scenario, which shows the proper configuration of IP unnumbered using RIP, applies to IGRP as well.

Improper configuration of IP unnumbered causes both RIP V1 and IGRP to lose IP connectivity for the misconfigured subnets. The failure modes for RIP and IGRP are slightly different because IGRP doesn't support host routes as well as RIP. However, this difference is not sufficient to warrant providing separate scenarios that show both routing protocols failing when IP unnumbered is misconfigured. By applying the concepts presented in this scenario, you should be able to understand what is going wrong when you are faced with a network in which IGRP has been configured with an improper use of IP unnumbered.

This section is broken into the following three scenarios:

• RIP with IP unnumbered configured properly.

  This section shows IP unnumbered working as intended and provides insights into proving that it is working as intended.

• RIP with IP unnumbered configured improperly a different subnet mask was used.

  This section shows IP unnumbered not working as intended because an improper subnet mask has been applied. It also provides some insights into proving that it is not working as intended.

• RIP with IP unnumbered configured improperly a different subnet mask and a different major net were used.

  This section combines the use of different major networks with a misconfiguration caused by using a subnet mask on one of the networks. It shows how IP unnumbered works with different major nets as well as how the use of a subnet masked major net can cause problems in some configurations.

RIP with IP Unnumbered Configured Properly

In this scenario, RIP has been properly configured with IP unnumbered. The examples show how to verify the proper configuration of IP unnumbered.

Displaying the Routes

In the following output of the show ip route command from RouterA, you can see that RouterA has a route to 168.71.8.0:

RouterA#show ip route 168.71.8.1
Routing entry for 168.71.8.0 255.255.255.0
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 168.71.8.1 on Serial1, 00:00:13 ago
 Routing Descriptor Blocks:
 * 168.71.8.1, from 168.71.8.1, 00:00:13 ago, via Serial1
   Route metric is 1, traffic share count is 1
RouterA#

In the following output of the show ip route command from RouterC, you can see that RouterC has a route to 168.71.5.0:

RouterC#show ip route 168.71.5.1
Routing entry for 168.71.5.0 255.255.255.0
 Known via "rip", distance 120, metric 1
Redistributing via rip
Advertised by rip (self originated)
Last update from 168.71.5.1 on Serial1, 00:00:13 ago
Routing Descriptor Blocks:
* 168.71.5.1, from 168.71.5.1, 00:00:13 ago, via Serial1
  Route metric is 1, traffic share count is 1

RouterC#

Notice that in both of the previous routing tables, the last update from address is the same as the actual address used in the show iproute command. Note that the routing entry indicates that this is a subnetted Class B address and not a host route because the mask is 255.255.255.0. This is the expected behavior when IP unnumbered is configured correctly. If IP unnumbered had been configured incorrectly, the routing entry would have a host route mask of 255.255.255.255.

Sending Routing Updates

The following output of debug ip rip from RouterA shows RouterA advertising the summarized major network of 168.71.0.0:

RouterA#debug ip rip
RIP: sending update to 255.255.255.255 via Serial1 (168.71.5.1)
   subnet 168.71.5.0, metric 1
   default 0.0.0.0, metric 1
   network 168.71.0.0, metric 1
RIP: received update from 168.71.8.1 on Serial1
   168.71.8.0 in 1 hops
   168.71.0.0 in 1 hops

The following output of debug ip rip from RouterC shows RouterC advertising the summarized major network of 168.71.0.0:

RouterC#deb ip rip
RIP: sending update to 255.255.255.255 via Serial1 (168.71.8.1)
   subnet 168.71.8.0, metric 1
   network 168.71.0.0, metric 1
RIP: received update from 168.71.5.1 on Serial1
   168.71.5.0 in 1 hops
   0.0.0.0 in 1 hops
168.71.0.0 in 1 hops

Although both routers are advertising the summarized major net of 168.71.0.0 to each other, neither router will install the route while using RIP because they have local connections to the 168.71.0.0 major net. This was explained in Chapter 3 in the section on summarization.

Pinging the Interfaces

In the following output, which is from RouterA pinging 168.71.8.1, you can see that the pings are successful:

RouterA#ping 168.71.8.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.71.8.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
RouterA#

In the following output, which is from RouterC pinging 168.71.5.1, you can see that the pings are successful:

RouterC#ping 168.71.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.71.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms
RouterC#

The fact that the pings are successful is the final proof that IP unnumbered has been configured correctly. Strictly speaking, this step is unnecessary as long as the results from the show ip route command indicate that proper routes have been installed. However, it is always better to double-check proper configuration by pinging the addresses.

The next section is a scenario about what happens when IP unnumbered has been misconfigured.

RIP with IP Unnumbered Configured Improperly

This scenario shows what happens when the rule is violated that requires the same mask to be used on all occurrences of the same major network's subnets. In Figure 4-4, RouterC's Token Ring interface now has a mask of 255.255.255.240. This is an example of variable length subnet masking (VLSM). In this case, major network 168.71.0.0 now has two masks: 255.255.255.0 and 255.255.255.240. VLSM is discussed in more detail in the next section.

In the following output of the show interface commands from RouterC, you can see the new mask in use. Note that no reference to the mask used on Token Ring 0 is in the output from serial 1. You must always check the interface that the address is being derived from to determine which subnet mask is in use.

RouterC#show interface tokenring 0
TokenRing0 is up, line protocol is up
 Hardware is TMS380, address is 0000.30c8.ab75 (bia 0000.30c8.ab75)
 Internet address is 168.71.8.17 255.255.255.240

RouterC#show interface serial 1
Serial1 is up, line protocol is up
 Hardware is HD64570
 Interface is unnumbered.  Using address of TokenRing0 (168.71.8.17)
 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255

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.

RouterA#debug ip routing
RouterA#debug ip rip
RouterA# clear ip route 168.71.8.16
RT: del 168.71.8.16 255.255.255.255 via 168.71.8.17, rip metric [120/1]
RT: delete subnet route to 168.71.8.16 255.255.255.255
RIP: received update from 168.71.8.17 on Serial1
   168.71.8.16 in 1 hops
   168.71.0.0 in 1 hops
RT: network 168.71.0.0 is now variably masked
RT: add 168.71.8.16 255.255.255.255 via 168.71.8.17, rip metric [120/1]
RouterA#

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.

RouterA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
   i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

Gateway of last resort is 171.68.207.129 to network 10.0.0.0

S*   10.0.0.0 [1/0] via 171.68.207.129
168.71.0.0 is variably subnetted, 2 subnets, 2 masks
C       168.71.5.0 255.255.255.0 is directly connected, Ethernet0
R       168.71.8.16 255.255.255.255 [120/1] via 168.71.8.17, 00:00:13, Serial1
S*   0.0.0.0 0.0.0.0 [1/0] via 171.68.207.129
RouterA#

Host Route Problem

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

RouterA#show ip route 168.71.8.17
% Subnet not in table
RouterA#

RouterA#show ip route 168.71.0.0
Routing entry for 168.71.0.0 255.255.0.0, 2 known subnets
 Attached (1 connections)
 Variably subnetted with 2 masks
 Redistributing via rip
 Advertised by rip

C   168.71.5.0 255.255.255.0 is directly connected, Ethernet0
R   168.71.8.16 255.255.255.255 [120/1] via 168.71.8.17, 00:00:01, Serial1
RouterA# 

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 following 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:

RouterC#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
   i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

Gateway of last resort is 168.71.5.1 to network 0.0.0.0

R  10.0.0.0 [120/1] via 168.71.5.1, 00:00:14, Serial1
168.71.0.0 255.255.255.240 is subnetted, 2 subnets
R    168.71.5.0 [120/1] via 168.71.5.1, 00:00:15, Serial1
C    168.71.8.16 is directly connected, TokenRing0
R*   0.0.0.0 0.0.0.0 [120/1] via 168.71.5.1, 00:00:15, Serial1
RouterC#

In the following 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.

RouterC#deb ip packet
RouterC#ping 168.71.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.71.5.1, timeout is 2 seconds:

IP: s=168.71.8.17 (local), d=168.71.5.1 (Serial1), len 100, sending.
IP: s=168.71.8.17 (local), d=168.71.5.1 (Serial1), len 100, sending.
IP: s=168.71.8.17 (local), d=168.71.5.1 (Serial1), len 100, sending.
IP: s=168.71.8.17 (local), d=168.71.5.1 (Serial1), len 100, sending
IP: s=168.71.8.17 (local), d=168.71.5.1 (Serial1), len 100, sending.
Success rate is 0 percent (0/5)
RouterC#

The following 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 Token Ring interface has made connectivity between the two routers impossible.

RouterA#debug ip packet
IP: s=168.71.8.17 (Serial1), d=168.71.5.1, len 104, rcvd 4
IP: s=168.71.5.1 (local), d=168.71.8.17, len 104, unroutable
IP: s=168.71.8.17 (Serial1), d=168.71.5.1, len 104, rcvd 4
IP: s=168.71.5.1 (local), d=168.71.8.17, len 104, unroutable
IP: s=168.71.8.17 (Serial1), d=168.71.5.1, len 104, rcvd 4
IP: s=168.71.5.1 (local), d=168.71.8.17, len 104, unroutable
IP: s=168.71.8.17 (Serial1), d=168.71.5.1, len 104, rcvd 4
IP: s=168.71.5.1 (local), d=168.71.8.17, len 104, unroutable
IP: s=168.71.8.17 (Serial1), d=168.71.5.1, len 104, rcvd 4
IP: s=168.71.5.1 (local), d=168.71.8.17, len 104, unroutable
IP: s=168.71.8.17 (Serial1), d=255.255.255.255, len 76, rcvd 2
RouterA#

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.

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 Token Ring interface; see Figure 4-5. 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 following show interface command from RouterC, you can see that the new major network has been configured with a subnet mask.

RouterC#show interface tokenring 0
TokenRing0 is up, line protocol is up
 Hardware is TMS380, address is 0000.30c8.ab75 (bia 0000.30c8.ab75)
 Internet address is 168.72.8.1 255.255.255.0
 MTU 4464 bytes, BW 16000 Kbit, DLY 630 usec, rely 255/255, load 1/255

RouterC#show interface serial 1
Serial1 is up, line protocol is up
 Hardware is HD64570
 Interface is unnumbered. Using address of TokenRing0 (168.72.8.1)

In the following output of the show interface command from RouterA, you can see that RouterA has the same IP unnumbered configuration as before:

RouterA#show interface serial 1
Serial1 is up, line protocol is up
 Hardware is HD64570
 Interface is unnumbered. Using address of Ethernet0 (168.71.5.1)
 MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255

In the following 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.

RouterA#debug ip rip
RIP: received update from 168.72.8.1 on Serial1
   168.72.8.0 in 1 hops
   168.72.0.0 in 1 hops
RIP: sending update to 255.255.255.255 via Serial1 (168.71.5.1)
   subnet 168.71.5.0, metric 1
   network 168.71.0.0, metric 1

RouterC#debug ip rip
RIP: received update from 168.71.5.1 on Serial1
   168.71.5.0 in 1 hops
   168.71.0.0 in 1 hops
RIP: sending update to 255.255.255.255 via Serial1 (168.72.8.1)
   subnet 168.72.8.0, metric 1
   network 168.72.0.0, metric 1

In the following routing table from RouterA, note the mask on the subnet route to 168.72.8.0, which is 255.255.255.255. 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.

RouterA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
   i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

Gateway of last resort is not set

   168.72.0.0 is variably subnetted, 2 subnets, 2 masks
R    168.72.0.0 255.255.0.0 [120/1] via 168.72.8.1, 00:00:20, Serial1
R    168.72.8.0 255.255.255.255 [120/1] via 168.72.8.1, 00:00:21, Serial1
  168.71.0.0 255.255.255.0 is subnetted, 1 subnets
C  168.71.5.0 is directly connected, Ethernet0
RouterA#

In the following 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.

RouterA#show ip route 168.72.8.1
Routing entry for 168.72.0.0 255.255.0.0
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 168.72.8.1 on Serial1, 00:00:00 ago
 Routing Descriptor Blocks:
 * 168.72.8.1, from 168.72.8.1, 00:00:00 ago, via Serial1
   Route metric is 1, traffic share count is 1

RouterA#

The following output from RouterA, which shows it pinging 168.72.8.1, proves that it has connectivity to RouterC because the pings are successful:

RouterA#ping 168.72.8.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.72.8.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms
RouterA#

In the following routing table from RouterC, note the mask on the subnet route to 168.71.5.0. 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.

RouterC#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
   i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set

   168.72.0.0 255.255.255.0 is subnetted, 1 subnets
C    168.72.8.0 is directly connected, TokenRing0
   168.71.0.0 is variably subnetted, 2 subnets, 2 masks
R    168.71.5.0 255.255.255.255 [120/1] via 168.71.5.1, 00:00:02, Serial1
R    168.71.0.0 255.255.0.0 [120/1] via 168.71.5.1, 00:00:02, Serial1
RouterC#

In the following 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.

RouterC#show ip route 168.71.5.1
Routing entry for 168.71.0.0 255.255.0.0
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 168.71.5.1 on Serial1, 00:00:16 ago
 Routing Descriptor Blocks:
 * 168.71.5.1, from 168.71.5.1, 00:00:16 ago, via Serial1
   Route metric is 1, traffic share count is 1

RouterC#

The following output from RouterC, which shows it pinging 168.71.5.1, proves that it has connectivity to RouterA because the pings are successful.

RouterC#ping 168.71.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 168.71.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms
RouterC#

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.