Understanding VLSM
This section provides scenarios on using VLSM and indicates the issues it can cause. Remember that VLSM refers to using different masks on the same major net. In Figure 4-6, the major net of 168.71.0.0 has two different masks— 255.255.255.0 and 255.255.255.252.
Figure 4-6. 168.71.0.0 has two masks.
VLSM Using RIP and IGRP
In general, RIP V1 and IGRP do not support VLSM because they do not include the subnet masks associated with routes in their routing advertisements. This forces routers to derive the correct masks from the interfaces the routes are received over. Using different masks creates the mask ambiguity problem presented in Chapter 3.
Note
Recall that mask ambiguity is the inability to derive the correct mask for a routing update because it has bits set outside of the range covered by the mask on the interface the route is received over.
It is possible to configure VLSM addresses on routers running RIP or IGRP in some instances. Keep in mind this rule: If the mask for a route in the routing table is different than the mask on the interface the route would be advertised over and they are both part of the same major network, the route will not be advertised. Because of this rule, the routers in this case do not have full IP connectivity.
To make this section more interesting, a configuration that would not normally occur in real life was created. For this configuration, one end of a serial link has a different mask than the other. This allows one router to advertise an unexpected subnet to the other router. This subnet is unexpected because it doesn't match the subnets on the interface the second router is receiving it over (see Figures 4-7 and 4-8).
This section presents two scenarios—one with two routers and another with three routers. Because VLSM behaves in exactly the same manner with RIP and IGRP, only RIP is presented in this section.
VLSM Experiment Using Two Routers
RouterB in Figure 4-7 has been mistakenly configured with the wrong mask on its serial 0 interface in order to clarify the role that the mask on an interface plays when a router is deriving the masks for routing advertisements it receives.
RouterB applies this mask to the routing advertisement for subnet 168.71.5.0 that is received from RouterA. 255.255.255.252 is not an illegal mask for 168.71.5.0. Routing may still work in this situation, and the problem may go unnoticed. However, in a more complicated network, this situation would cause a problem.
The following show interface commands from routers A and B show that the mask is not the same on each side of the link. This is not a configuration that would occur normally. However, it is useful for demonstrating how routers derive masks for network addresses and for indicating the problems that can occur when the derived mask is not appropriate. The primary problem in this situation is that incorrect subnet masks are associated with received route advertisements.
Figure 4-7. RouterB has the wrong mask on serial 0.
RouterA#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.1 255.255.255.0
RouterB#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.252
In the following output of the show ip routecommand from routers A and B, you can see that each router believes 168.71.5.0 has a different mask. In this scenario, the routers' masks will still be inconsistent, but connectivity will still be possible.
RouterA#show ip route 168.71.5.0
Routing entry for 168.71.5.0 255.255.255.0
Known via "connected", distance 0, metric 0 (connected)
RouterB#show ip route 168.71.5.0
Routing entry for 168.71.5.0 255.255.255.252
Known via "rip", distance 120, metric 1
In the following output from RouterB pinging 168.71.5.1 you can see that routing is working for 168.71.5.1:
RouterB#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 = 4/4/8 ms
RouterB#
In this scenario, connectivity was still possible from one router to the other using the assigned IP addresses. However, routing would not work if RouterB received a packet for 168.71.5.10. RouterB could not forward this packet because a longest match lookup for 168.71.5.10 in the routing table would not match against the routing entry for 168.71.5.0 255.255.255.252.
The .10 in the last octet of the IP address 168.71.5.10 has bits set that fall under the range of the mask for the last octet in the routing table entry: .252. This indicates that the host address 168.71.5.10 is not on the subnet covered by 168.71.5.0 255.255.255.252.
See the section in Chapter 8 on determining which subnet a host address falls under if you need more information on this issue.
The following output of the show ip route 168.71.5.10 command from RouterB shows that RouterB doesn't have a route to 168.71.5.10.
RouterB#show ip route 168.71.5.10
% Subnet not in table
RouterB#
Note that as far as RouterA is concerned, 168.71.5.1 and 168.71.5.10 are on the same subnet. RouterB, on the other hand, thinks they are on different subnets because of the mask it derived for 168.71.5.0 when it was received from RouterA. The incorrect mask was derived because RouterB has the wrong mask on its serial0 interface—255.255.255.252 instead of 255.255.255.0.
Remember that the correct mask for subnet 168.71.5.0 is 255.255.255.0. RouterB would have been able to match 168.71.5.10 to this route and mask combination. The .10 in the final octet of the IP address (0.0.0.10) falls outside of the range of the bits covered by the subnet mask (255.255.255.0). Therefore, it would have been ignored when RouterB did the longest match lookup.
The next scenario, which uses three routers, shows how an incorrect entry in a routing table can cause the routing table to become corrupted and demonstrates how this can affect network performance.
VLSM Experiment Using Three Routers
This scenario builds on the previous one by bringing RouterC back into the picture. RouterB's serial 0 interface still has the incorrect mask 255.255.255.252, as shown in Figure 4-7. All other masks are 255.255.255.0 (see Figure 4-8).
Figure 4-8. Return to the router topology.
In the following routing table from RouterB, you can see that there are two connected interfaces to major net 168.71.0.0: serial 0 and serial 1. You can also see that every other RIP-derived route now has two entries—one with a mask of 255.255.255.0 and another with a mask of 255.255.255.252:
RouterB#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.71.0.0 is variably subnetted, 10 subnets, 2 masks
R 168.71.9.0 255.255.255.252 [120/1] via 168.71.6.1, 00:00:00, Serial0
R 168.71.9.0 255.255.255.0 [120/1] via 168.71.7.1, 00:00:26, Serial1
R 168.71.8.0 255.255.255.252 [120/2] via 168.71.6.1, 00:00:00, Serial0
R 168.71.8.0 255.255.255.0 [120/1] via 168.71.7.1, 00:00:26, Serial1
R 168.71.7.0 255.255.255.252 [120/2] via 168.71.6.1, 00:00:00, Serial0
C 168.71.7.0 255.255.255.0 is directly connected, Serial1
R 168.71.6.0 255.255.255.0 [120/2] via 168.71.7.1, 00:00:26, Serial1
C 168.71.6.0 255.255.255.252 is directly connected, Serial0
R 168.71.5.0 255.255.255.0 [120/2] via 168.71.7.1, 00:00:26, Serial1
R 168.71.5.0 255.255.255.252 [120/1] via 168.71.6.1, 00:00:00, Serial0
RouterB#
You can see that the entries for the following routing tables from routers A and C are as expected because they both have the correct masks on each interface:
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.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
R 168.71.8.0 [120/1] via 168.71.9.2, 00:00:03, Serial1
R 168.71.7.0 [120/1] via 168.71.9.2, 00:00:03, Serial1
C 168.71.6.0 is directly connected, Serial0
C 168.71.5.0 is directly connected, Ethernet0
RouterA#
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.71.0.0 255.255.255.0 is subnetted, 5 subnets
C 168.71.9.0 is directly connected, Serial1
C 168.71.8.0 is directly connected, TokenRing0
C 168.71.7.0 is directly connected, Serial0
R 168.71.6.0 [120/1] via 168.71.9.1, 00:00:07, Serial1
R 168.71.5.0 [120/1] via 168.71.9.1, 00:00:07, Serial1
RouterC#
In this example, if RouterB attempted to ping 168.71.8.1, it would do a longest match lookup and determine that its route to 168.71.8.0 255.255.255.252 via RouterA was the best path to reach this IP address.
The following output of the show ip route 168.71.8.1 command from RouterB shows that RouterB believes its best route to 168.71.8.0 is via RouterA, not RouterC.
RouterB#show ip route 168.71.8.1
Routing entry for 168.71.8.0 255.255.255.252
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 168.71.6.1 on Serial0, 00:00:24 ago
Routing Descriptor Blocks:
* 168.71.6.1, from 168.71.6.1, 00:00:24 ago, via Serial0
Route metric is 2, traffic share count is 1
RouterB#
RouterB sends the pings to 168.71.8.1 via RouterA. The IP address of the outbound interface is used by default when a router sends a ping, so the IP source addresses in this scenario are all 168.71.6.2, not 168.71.7.2—the IP address on RouterB closest to RouterC. RouterA, which has the correct route and mask for 168.71.8.0, forwards the pings via its serial 1 interface to RouterC. RouterC sends its replies via its serial 0 interface to RouterB, resulting in what is commonly called asymmetric routing—two hosts using different paths when sending IP packets to each other.
These last two sections have further explained the function of deriving masks for routes from the interfaces the routes are learned over. They have also shown some interesting situations that can arise when a misconfiguration occurs.
The following section explains what happens when VLSM is properly configured and routing advertisements are blocked entirely.
Correctly Configuring VLSM Blocked Routes
A blocked route is a route that is not advertised by a router because it doesn't fit the mask of the outbound interface. In the example in Figure 4-9, the masks and addresses on RouterA's serial 0 have been changed. The new mask is 255.255.255.252. Both routers now have the same mask on this link.
Figure 4-9. VLSM is configured correctly.
In the following output of the show interface command from routers A and B, you can see that both ends of the link have the same mask:
RouterA#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.1 255.255.255.252
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
RouterB#show interface serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 168.71.6.2 255.255.255.252
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255
In the following routing tables from routers A and B, you can see that there are no RIP-derived routes:
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.71.0.0 is variably subnetted, 2 subnets, 2 masks
C 168.71.6.0 255.255.255.252 is directly connected, Serial0
C 168.71.5.0 255.255.255.0 is directly connected, Ethernet0
RouterA#
RouterB#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.71.0.0 is variably subnetted, 2 subnets, 2 masks
C 168.71.8.0 255.255.255.0 is directly connected, TokenRing0
C 168.71.6.0 255.255.255.252 is directly connected, Serial0
RouterB#
In this example, 255.255.255.252 and 255.255.255.0 are both legitimate masks for 168.71.5.0, 168.71.8.0, and 168.71.6.0. However, the routers will still not advertise their local LAN interface subnets to each other. It is not sufficient for a mask on an outward bound interface to be legitimate for a particular route. It must be an exact match for the mask the router has stored in its table.
The following output from the debug ip rip command on routers A and B shows the RIP process suppressing the updates because they are empty:
RouterA#debug ip rip
Oct 30 23:21:46: RIP: sending update to 255.255.255.255 via Serial0 (168.71.6.1)
- suppressing null update
RouterB# debug ip rip
Oct 30 23:21:46: RIP: sending update to 255.255.255.255 via Serial0 (168.71.6.2)
- suppressing null update
Proper configuration of VLSM results in routers failing to send any routes in their advertisements, which leads to a total loss of connectivity in many cases.
VLSM Summary
This section has shown the reason RIP and IGRP do not support VLSM (no masks carried in advertisements) and the method used for preventing its use at all (updates over interfaces in the same major net with different masks are suppressed).