In VLSM – Part 1, we looked at a quick way to do VLSM. This time, we’ll look at some more VLSM exercises, as well as examples in which VLSM won’t solve the problem. Of course, we’ll need the powers-of-two chart. In case you don’t have it memorized yet, here it is:
A HQ site is connected to 20 remote sales offices in a hub and spoke topology (using point-to-point Frame Relay subinterfaces). We’re given the address space 10.100.200.0/22. We need to subnet to support a HQ LAN subnet of 100 hosts, 20 sales office LANs of 25 hosts each, and the 20 WAN links connecting HQ to the remote sites.
First, we find the total number of hosts, which is 100 + (20 x 25) + (20 x 2) = 640. Since we have a “/22” address space, we have ten bits to work with. Ten bits is off the chart, but if we extend the powers of two chart two more columns to the left, we see that two to the tenth is 1,024 (allowing for 1,022 hosts), so we’re good to proceed. Also, using the methods we developed in “Subnet Masking Shortcuts”, with a “/22” mask (255.255.252.0) the subnets increment by four in the third octet, so the next subnet up would be 10.100.204.0/22. In other words, we have the range of addresses from 10.100.200.0 to 10.100.203.255 available. Anything outside of that range is outside of our allowable address space.
We’ll start with the largest subnet, the HQ LAN, which requires 100 hosts (seven host bits), and therefore a “/25” mask:
- 100 hosts => 10.100.200.0/25
With a “/25” mask (seven host bits), the subnets increment by 128, so the next subnet begins at 10.100.200.128. The next largest subnet, a sales LAN, contains 25 hosts, and therefore requires five host bits, or a “/27”. Thus, the next subnet is 10.100.200.128/27. With a “/27” mask (five host bits), the subnets increment by 32, so the next subnet begins at 10.100.200.160. In fact, all of the sales LANs require 25 hosts, and therefore “/27” masks. Thus, the twenty sales LANs could be:
- (thirteen more subnets incrementing by 32 go here)
That takes care of the 21 LAN subnets (HQ and the 20 remote sites), so now let’s do the WAN links. Taking up where we left off at 10.100.200.224/27, with five host bits the subnets increment by 32, so the next available subnet begins at 10.100.203.0. The WAN links need two hosts each, so we can use a “/30” for each (in which case they increment by four). Therefore, the twenty WAN subnets could be:
- 10.100.203.0 (4, 8 … 72, 76) /30
The next available subnet would be 10.100.203.80, but since we’ve covered all required subnets, we don’t need it at present. We could also have used “/31” masks on the WAN links, in which case they could be:
- 10.100.203.0 (2, 4 … 36, 38) /31
In this case, the address space starting at 10.100.203.40 remains unused.
Speaking of unused address space, with VLSM it’s common to have quite a bit of flexibility. For example, let’s say that given the address space 172.30.20.0/24, we need a HQ LAN subnet with 50 hosts, ten sales office LANs with five hosts each, and leased lines (running PPP) connecting HQ to the sales offices. In this case, the largest subnet is the HQ LAN (50 hosts), which requires six host bits, or a “/26” mask:
- 50 hosts => 172.30.20.0/26
With a “/26” mask (six host bits), the subnets increment by 64, so the next subnet begins at 172.30.20.64. The next largest subnet is a sales office LAN, which contains five hosts, and there are ten of them, all requiring three host bits, or “/29” masks. Thus, the ten sales office LAN subnets could be:
- 172.30.20.64 (72, 80, 88 … 128, 136) /29
The next subnet starts at 172.30.20.144, and we still need to allocate address space for the ten WAN links. Because these are P2P links, we can use either “/30” or “/31” subnets. Let’s use “/30”, which increment by four:
- 172.30.20.144 (148, 152, 156 … 176, 180) /30
That takes care of that, with the addresses 184 and above currently unused. Now comes the “flexibility” part. Since we have quite a bit of unused address space, we could get fancy and allocate addresses below 100 for the HQ LAN, those in the range 100 to 199 for sales office LANs, and 200 and above for the WAN links, thus:
- HQ LAN => 172.30.20.0/26 (still allows for 62 hosts)
- Sales LANs => 172.30.20.104 (112, 120 … 168, 176) /29
- WANs => 172.30.20.200/30 (204, 208 … 236, 240) /30
With the scheme just outlined, the addresses in the ranges from 172.30.20.64 to 103, and 172.30.20.244 to 255 are unused.
If you’re going to be “elegant”, you also need to be careful. Because this is all using binary “behind the scenes”, there is a rule to be followed, and that rule is:
The starting address of a subnet must be evenly divisible by the increment for that subnet.
In other words, you can start a “/29” subnet (which increments by eight) at 104, but not at 100. Why? Because 104 is evenly divisible by eight, but 100 is not. If you’ve read my blog on “Address Summarization” (or if you’re a math genius), you may have already realized this. This is exactly why I recommend that you start with the largest subnet, and work your way down to the smallest. Why? Because:
- The mask must allow for the required number of hosts.
- The subnets must not overlap.
- The starting address of a subnet must be evenly divisible by the increment for that subnet.
If you start big and work down, you’ll meet all three rules (assuming that you don’t make any mistakes, that is). If you do anything else, it’s easy to mess it up.
Just to expand a little further on the flexibility aspect, another strategy is to leave some room for growth on the HQ subnet, by using a “/25” mask (which would support up to 126 hosts). Since the next subnet available for a sales office LAN would begin at 172.30.20.128, we could do this:
- Sales LANs => 172.30.20.128 (136, 140 … 188, 196) /29
The next subnet would start at 172.30.20.204, so let’s allocate the WAN links accordingly:
- WANs => 172.30.20.204/30 (208, 212 … 240, 244) /30
Note that while VLSM can be quite handy in some circumstances, it isn’t magic. For example, if the total number of hosts required exceeds that supported by the address space, VLSM won’t help (more than 254 hosts on a Class “C” doesn’t compute). Also, it’s certainly possible that even if the total number of hosts will fit within the address space, the problem still can’t be solved using VLSM. Let’s look at an example …
We’ll slightly modify the first VLSM problem that we did, using the same 192.168.1.0/24 address space, and still requiring four subnets, but with the following numbers of hosts:
- 105 hosts
- 50 hosts
- 40 hosts
- 10 hosts
The first subnet (105 hosts) is 192.168.1.0/25 (increment of 128), the second (50 hosts) is 192.168.1.128/26 (increment of 64), the third (40 hosts) is 192.168.1.192/26 (increment of 64), and the fourth (10 hosts) and last subnet is 192.168.1.256/28:
- 105 hosts => 192.168.1.0/25
- 50 hosts => 192.168.1.128/26
- 40 hosts => 192.168.1.192/26
- 10 hosts => 192.168.1.256/28
Too bad that 256 (the 192 from the third subnet, plus its increment of 64) is not a legal value for an octet (with eight bits, you can only go from zero to 255). What it comes down to is that because we were forced to waste address space on the larger subnets, we ran out of address space before we allocated it to all of the required subnets.
Having said all that, you should know that thanks to private addressing (RFC 1918) and NAT (RFC 1631), VLSM is not used as much as it used to be … but it still is used.
Well, that’s VLSM. Time to doff our beanies!
Author: Al Friebe