Variable-Length Subnet Masking (VLSM)

Revised May 9, 2002

If you're not proficient at standard subnet masking, I recommend you try the "Subnet
Masking" review exercises first.

Your solutions may not look exactly like mine. For some subnetting problems, there may be
multiple correct solutions, especially when future growth is considered. The important thing is
that you understand and can apply the principles involved.

EXERCISES:

1. Your company has been assigned IP network 195.39.71.0/24. Given that headquarters (60
hosts) is connected to five branch offices (12 hosts each) by 56K WAN links, and to an ISP (the
ISP owns the addresses on that link), determine an appropriate IP addressing scheme.

2. Smallco has a central office with 92 hosts, and three remote sites, with 6, 12 and 25 hosts. The
remote sites are connected to the central office by an ISDN DDR WAN running PPP. They have
been assigned a network address of 209.81.102.0/24. Please develop an appropriate subnetting
plan for their internetwork.

3. Bigco has a hierarchical internetwork topology. They have 14 regional offices, each connected
to HQ via a Frame-Relay PVC in a hub-and-spoke arrangement. Each regional office is in turn
connected (by 56K leased lines) to its 45 subordinate sales offices, also hub-and-spoke. HQ has
2300 hosts (on 23 subnets of 100 hosts each), each regional office has 150 hosts (two subnets of
75 hosts), and each sales office has 39 hosts (one subnet). They are expecting to increase the
number of regional offices and sales offices per regional office, and also the number of hosts
everywhere, including HQ. They have just changed ISPs, and have been assigned a new IP
address of 147.23.0.0/16. Assign subnet as appropriate.

4. Midco has five sites, connected in a full-mesh topology by Frame-Relay PVCs. The sites have
45, 30, 24, 11 and 3 hosts, respectively. They have been assigned network 223.70.156.0/24.
Subnet their network.

5. Each of Hugeco's 189 regional offices is connected to headquarters by an ATM OC-3, with
dual HDLC T-3's for use as backups and/or additional bandwidth. They have network
172.19.0.0/16, and the number of hosts at the various offices is as follows:

Office # subnets # hosts/subnet

-------- --------- --------------
HQ 120 35
R1-94 5 40
R95-118 3 35
R119-155 2 36
R156-189 1 41
Subnet Hugeco's network, leaving room for reasonable future expansion.

6. Word of your awesome VLSM expertise has spread, and you have just received a fax from
Richco offering a $50K cash bonus if you can correctly subnet their internetwork. The central
office has 97 hosts. They have four remote sites, each running a single subnet, with 4, 10, 27 and
60 hosts, respectively. Each remote site connects to the central office with a FT-1 (Fractional T-1)
running at 168Kbps. Their assigned IP address is 202.3.71.0/24. Scalability is not a concern, but
they are desperate for a quick solution. The bonus offer expires in fifteen minutes, and the clock
starts NOW!

7. Your friends at Microcorp have six sites: HQ, with 11 hosts, and five remotes, each with 4
hosts. Each remote site connects to HQ with a 56Kbps leased line. Their assigned IP address is
199.0.1.0/24. They need a favor ...

8. Lemon Technologies has been assigned IP network 211.69.13.0/24. Headquarters, with 49

hosts, is connected in a hub-and-spoke configuration to six remote offices, each with 19 hosts.
Determine an appropriate IP addressing scheme.

9. Kumquat Networks has IP network 220.89.98.0/24. They have seven sites, each with 28 hosts,
and desire a full-mesh Frame Relay WAN connecting all sites. Determine an appropriate IP
addressing scheme.

10. You did a fine job solving Exercise 1, but you have just been informed that your company is
limited to using only RIP (Version 1) as its routing protocol. Re-do the first exercise with this
constraint in mind.

ANSWERS:
NOTE: Some people are under the impression that we cannot use two subnets, the "all-zeroes"
and "all-ones", and that, for example, using three bits of subnetting yields only six subnets. This
is incorrect. To quote RFC 1812 (Requirements for IP Version 4 Routers):

Previous versions of this document also noted that subnet numbers

must be neither 0 nor -1, and must be at least two bits in length.
In a CIDR world, the subnet number is clearly an extension of the
network prefix and cannot be interpreted without the remainder of
the prefix. This restriction of subnet numbers is therefore
meaningless in view of CIDR and may be safely ignored.
We now turn our attention to RFC 1878 (Variable Length Subnet Table For IPv4):
" ... using calculations which exclude all-zeros and all-ones subnets ...
This practice is obsolete! Modern software will be able to utilize all
definable networks."
Note that both of these RFC's are dated 1995! The bottom line is that we lose two host addresses
per subnet ("all-zeroes" and "all-ones"), not two subnets. On a Cisco, by the way, you have to
enable "subnet-zero" in order to use it ("ip subnet-zero" from global config mode), and it is on by
default in Cisco's IOS version 12. Another change with IOS 12 is that IP directed broadcasts are
disabled by default (to enable them, use the "ip directed-broadcast" on the targeted interface).

1. First, let's see how far we get with regular subnet masking. HQ needs one subnet (60 hosts).
There are five branches, and each branch needs two subnets: one for the branch (12 hosts), and
one for the link (2 hosts) to HQ. This is a total of eleven subnets. Since HQ has 60 hosts, it
requires a "/26" mask (six host bits, which is sufficient for 62 hosts). If we use a /26 mask with a
class C ("/24") network, we have two bits available for subnetting. This only provides for four
subnets, including "subnet zero" and "subnet all-ones". Since we need eleven subnets, regular
subnetting will not work. Therefore, let us now turn to the miracle of VLSM.

Again, the 60 host HQ subnet requires a "/26" mask. Using the assigned network of
195.39.71.0/24, and subnetting with a "/26" mask, we obtain four subnets, each of which would
support 62 hosts:

network sn host
---------- -- ------
195.39.71. 00 000000 -> 195.39.71.0/26
195.39.71. 01 000000 -> 195.39.71.64/26
195.39.71. 10 000000 -> 195.39.71.128/26
195.39.71. 11 000000 -> 195.39.71.192/26

Note that I'm using dotted-decimal for the network portion, and binary for the "interesting" parts.
Suppose we decide to play it safe, and avoid using "subnet zero". Thus, the 195.39.71.0/26
subnet will be ignored, and we will choose 195.39.71.64/26 as our first legal subnet. We will
assign this to HQ. Since we only need one subnet of this size, we are free to use the other "/26
subnets" any way we like.

Let's take care of the branch offices. Each branch office has 12 hosts, and therefore requires a
"/28" mask. Therefore, we will begin with 195.39.71.128/28, and go from there:

network sn host
 ---------- ---- ----
195.39.71. 1000 0000 -> 195.39.71.128/28
195.39.71. 1001 0000 -> 195.39.71.144/28
195.39.71. 1010 0000 -> 195.39.71.160/28
195.39.71. 1011 0000 -> 195.39.71.176/28

This yields four subnets, each supporting up to 14 hosts (since there are four host bits). We need
five of these, one for each branch office, so we will need to grab an additional major ("/26")
subnet, and subnet it with the "/28" mask:

network sn host
---------- ---- ----
195.39.71. 1100 0000 -> 195.39.71.192/28
195.39.71. 1101 0000 -> 195.39.71.208/28
195.39.71. 1110 0000 -> 195.39.71.224/28
195.39.71. 1111 0000 -> 195.39.71.240/28

Since we only need one of these, let's use 195.39.71.192/28. For the branches, then, we have:

195.39.71.128/28
195.39.71.144/28
195.39.71.160/28
195.39.71.176/28
195.39.71.192/28

All we have left to do is to determine the subnets for the five links between HQ and the branches.
A point-to-point link only requires two hosts, which is a "/30" mask. Starting where we left off,
we have:

network sn host
---------- ------ ----
195.39.71. 110100 00 -> 195.39.71.208/30
195.39.71. 110101 00 -> 195.39.71.212/30
195.39.71. 110110 00 -> 195.39.71.216/30
195.39.71. 110111 00 -> 195.39.71.220/30

This give us four "/30" subnets, but we need five. Therefore, we will use the next available "/28"
as well:

network sn host
---------- ------ ----
195.39.71. 111000 00 -> 195.39.71.224/30
195.39.71. 111001 00 -> 195.39.71.228/30
195.39.71. 111010 00 -> 195.39.71.232/30
195.39.71. 111011 00 -> 195.39.71.236/30

This gives us an additional four "/30" subnets, of which we only need one. For the point-to-point
links we have:

195.39.71.208/30
195.39.71.212/30
195.39.71.216/30
 195.39.71.220/30
195.39.71.224/30

Putting it all together, our plan is:

HQ: 195.39.71.64/26
B1: 195.39.71.128/28, 195.39.71.208/30
B2: 195.39.71.144/28, 195.39.71.212/30
B3: 195.39.71.160/28, 195.39.71.216/30
B4: 195.39.71.176/28, 195.39.71.220/30
B5: 195.39.71.192/28, 195.39.71.224/30

Note that our decision to leave 195.39.71.0/26 unused hurts our future scalability, in that it
wastes 62 host addresses (at HQ, or the equivalent at the branch offices and links). On the bright
side, if we do need more than 62 hosts at HQ in the future, we can just drop 195.39.71.0/26 in,
and have room for another 62 HQ hosts. Alternatively, we could use it for additional branches, if
required.

2. First step, let's try regular subnet masking. The Central Office needs one subnet (92 hosts).
There are three remote sites, and each remote site needs two subnets: one for the site (number of
hosts varies, but is less than 92 in all cases), and one for the link (2 hosts) to the Central Office.
This is a total of seven subnets. The Central Office, with 92 hosts, requires a "/25" mask (seven
host bits, sufficient for 126 hosts). If we use a /25 mask with a class C ("/24") network, we have
one bit available for subnetting. This only provides for two subnets, specifically "subnet zero"
and "subnet all-ones". Since we need seven subnets, regular subnetting will not work. Thus, we
now invoke VLSM.

The Central Office needs 92 host addresses, and therefore a "/25" mask. Using the assigned
network of 209.81.102.0/24, and subnetting with a "/25" mask, we obtain two subnets, each of
which would support 126 hosts:

network sn host
---------- -- -------
209.81.102. 1 0000000 -> 209.81.102.0/25
209.81.102. 1 0000000 -> 209.81.102.128/25

Again, I'm using dotted-decimal for the network portion, and binary for the "interesting" parts.
Let's use 209.81.102.0/25 for the Central Office, and since we only need one subnet of this size,
we are free to use the other "/25 subnet" as needed.

Now let's take care of the remote sites. The largest remote site has 25 hosts, and therefore
requires a "/27" mask. Therefore, we will begin with 209.81.101.128/27, and go from there:

network sn host
----------- --- -----
209.81.102. 100 00000 -> 209.81.102.128/27
209.81.102. 101 00000 -> 209.81.102.160/27
209.81.102. 110 00000 -> 209.81.102.192/27
209.81.102. 111 00000 -> 209.81.102.224/27
This yields four subnets, each supporting up to 30 hosts (since there are five host bits). Here we
reach a decision point: we can use three of them for the remote sites, which gives us the ability to
grow each remote site to 30 hosts. Alternately, we can further subnet to support the 6 and 12 host
sites. First, let's examine the "efficient" (lazy) approach, using a "/27" mask for all remote sites.
In this case, we can use the first three of the subnets (128, 160 and 192) for remote sites, and we
will subnet 209.81.102.224/27 further to provide for the point-to-point links between the remote
sites and the Central Office. In that case, we have:

network sn host
----------- ------ --
209.81.102. 111000 00 -> 209.81.102.224/30
209.81.102. 111001 00 -> 209.81.102.228/30
209.81.102. 111010 00 -> 209.81.102.232/30
209.81.102. 111011 00 -> 209.81.102.236/30
... and so on ...
209.81.102. 111110 00 -> 209.81.102.248/30
209.81.102. 111111 00 -> 209.81.102.252/30

This provides more "/30" subnets (8) than we need (3), but too many is much better than too few.
Let's grab the first three, 224, 228 and 232. Putting it all together, our proposed plan consists of:

CO: 209.81.102.0/25
R1: 209.81.102.128/27, 209.81.102.224/30
R2: 209.81.102.160/27, 209.81.102.228/30
R3: 209.81.102.192/27, 209.81.102.232/30

This gives us great scalability as far as number of hosts at the existing Central Office and remote
sites, but does not allow for any additional remotes. If we opt to be a little more creative with our
subnetting (which translates to mean "work harder"), we could provide for some additional sites
beyond our current allotment. Beginning again with 209.81.102.0/25 for the Central Office, and
209.81.102.128/27 for the 25-host remote site, we could then split the 209.81.102.160/27 subnet
between the 6 and 12 host sites, producing two subnets, each with a "/28" mask:

network sn host
----------- ---- ----
209.81.102. 1010 0000 -> 209.81.102.128/28
209.81.102. 1011 0000 -> 209.81.102.144/28
We are now subnetting our subnetted subnet! This frees up 209.81.102.160/27 for one or more
additional remote sites, and still leaves us with 209.81.102.224/30 and so on for the point-to-
point links. Of course, we could use 209.81.102.160/27 for the 12-host remote site (room to grow
to 30 hosts), and use part of 209.81.102.192/27 for the 6-host remote site (say,
209.81.102.192/29, which allows exactly six hosts) ... anyway, you get the idea. Remember:
When it comes to VLSM, flexibility is the key to indecision!

3. We'll follow our usual approach: try fixed-length subnet masking (FLSM?) first. HQ needs 23
subnets, each supporting 100 hosts. This implies a "/25" mask, which allows for 126 hosts per
subnet, and 512 subnets (remember, it's a class "B" network, so with a "/25" mask, we have 9
subnet bits). Speaking of subnets, we need 28 more for the regional offices (one inside the office,
and one to connect the office to HQ), and 1260 more for the 630 sales offices (again, one inside,
and one to connect the sales office to its regional office). Since the total of 1311 far exceeds 512,
regular subnet masking won't get the job done. On to another VLSM adventure ...

Using a "/25" mask at HQ will support their 100-host subnets, and even leave room for
expansion on each. Let's calculate the subnets:

network sn host
------- ---------- -------
147.23. 00000000.0 0000000 -> 147.23.0.0/25
147.23. 00000000.1 0000000 -> 147.23.0.128/25
147.23. 00000001.0 0000000 -> 147.23.1.0/25
147.23. 00000001.1 0000000 -> 147.23.1.128/25
147.23. 00000010.0 0000000 -> 147.23.2.0/25
... and so on ...
147.23. 11111111.0 0000000 -> 147.23.255.0/25
147.23. 11111111.1 0000000 -> 147.23.255.128/25

For HQ, we need 23 of these subnets (we'll use the 32 subnets 147.23.0.0/25 through
147.23.15.128/25, giving them 9 subnets for future expansion.

Now let's take care of the regional offices. There are 14, and each has two 75-host subnets, and
they require "/25" masks, as well. We will begin with 147.23.16.0/25, and go from there:

network sn host
------- ---------- -------
147.23. 00001000.0 0000000 -> 147.23.16.0/25
147.23. 00001000.1 0000000 -> 147.23.16.128/25
147.23. 00001001.0 0000000 -> 147.23.17.0/25
147.23. 00001001.1 0000000 -> 147.23.17.128/25
147.23. 00001010.0 0000000 -> 147.23.18.0/25
... and so on ...
147.23. 11111111.0 0000000 -> 147.23.255.0/25
147.23. 11111111.1 0000000 -> 147.23.255.128/25

Of these 224 remaining subnets, the regional offices require 28 (two per office). Since we need
some room for expansion, let's reserve the 48 subnets from 147.23.16.0/25 through
147.23.39.128/25 for the regional offices.

Now for the sales offices. Each currently supports 39 hosts, which indicates a "/26" mask. We
will begin at 147.23.40.0/26:

network sn host
------- ----------- ------
147.23. 00101000.00 000000 -> 147.23.40.0/26
147.23. 00101000.01 000000 -> 147.23.40.64/26
147.23. 00101000.10 000000 -> 147.23.40.128/26
147.23. 00101000.11 000000 -> 147.23.40.192/26
147.23. 00101001.00 000000 -> 147.23.41.0/26
... and so on ...
147.23. 11111111.10 000000 -> 147.23.255.128/26
147.23. 11111111.11 000000 -> 147.23.255.192/26
We need 630 of these, so let's plan for expansion, and reserve the 800 subnets from
147.23.40.0/26 through 147.23.239.192/26 for branch offices.

This leaves us only to calculate the serial links, of which there are currently 644 (14 between HQ
and the regional offices, and the 630 between the sales offices and their regional offices). As
always, we need a "/30" mask, so starting at 147.21.240.0/30, we have:

network sn host
------- --------------- ----
147.23. 11110000.000000 00 -> 147.23.240.0/30
147.23. 11110000.000001 00 -> 147.23.240.4/30
147.23. 11110000.000010 00 -> 147.23.240.8/30
147.23. 11110000.000011 00 -> 147.23.240.12/30
147.23. 11110000.000100 00 -> 147.23.240.16/30
... and so on ...
147.23. 11111111.111110 00 -> 147.23.255.248/30
147.23. 11111111.111111 00 -> 147.23.255.252/30

This gives us 1024 "/30" subnets, which is more than the 644 we need, so we are in good shape.
Our proposed plan consists of:

HQ: 147.23.0.0/25 - 147.23.15.128/25 (32 subnets: 23 in use)

RO: 147.23.16.0/25 - 147.23.39.128/25 (48 subnets: 28 in use)
SO: 147.23.40.0/26 - 147.23.239.192/26 (800 subnets: 630 in use)
P2P links: 147.23.240.0/30 - 147.23.255.252/30 (1024 subnets: 644 in use)

Note that we have quite a bit of flexibility (indecision!) in our configuration. We can tune for
greater growth at HQ, or in the numbers and/or sizes of regional and sales offices.

4. We have five sites, and the largest supports 45 hosts, requiring a "/26" mask. With a class "C"
network and a "/26" mask, we can only have four subnets ... and we need 15 (five for the sites,
and ten for the mesh-connected links). Onward to VLSM ...

Using a "/26" mask will support the 45-host site, and would probably be a good idea for the 30-
host site, as well (growth happens). Let's calculate the subnets:

network sn host
----------- -- ------
223.70.156. 00 000000 -> 223.70.156.0/26
223.70.156. 01 000000 -> 223.70.156.64/26
223.70.156. 10 000000 -> 223.70.156.128/26
223.70.156. 11 000000 -> 223.70.156.192/26

We'll use 223.70.156.0/26 and 223.70.156.64/26 for the 45 and 30-host sites, respectively (not
that it matters which one gets which).

For the 24-host site, we can use a "/27" mask:

network sn host
----------- --- -----
 223.70.156. 100 00000 -> 223.70.156.128/27
223.70.156. 101 00000 -> 223.70.156.160/27
223.70.156. 110 00000 -> 223.70.156.192/27
223.70.156. 111 00000 -> 223.70.156.224/27

So let's pick 223.70.156.128/27, and move on to the 11-host site, which requires a "/28" mask,
and begins at 223.70.156.160/28:

network sn host
----------- ---- ----
223.70.156. 1010 0000 -> 223.70.156.160/28
223.70.156. 1011 0000 -> 223.70.156.176/28
223.70.156. 1100 0000 -> 223.70.156.192/28
... and so on ...

We'll select 223.70.156.160/28, and move on to the 3-host site. Strictly speaking, a 3-host site
only requires a "/29" mask (supporting 6 hosts), but we might want to give them some more
room for expansion. Let's use the next "/28" subnet, which is 223.70.156.176/28.

As always, we need to calculate the subnets for the serial links, of which there are ten. Using a
"/30" mask, and starting at 223.70.156.192/30, we have:

network sn host
----------- ------ ----
223.70.156. 110000 00 -> 223.70.156.192/30
223.70.156. 110001 00 -> 223.70.156.196/30
223.70.156. 110010 00 -> 223.70.156.200/30
223.70.156. 110011 00 -> 223.70.156.204/30
... and so on ...
223.70.156. 111110 00 -> 223.70.156.248/30
223.70.156. 111111 00 -> 223.70.156.252/30

As usual, we have more "/30" subnets (16) than we need (10), so we're all set. Our scheme is:

S1 (45 hosts): 223.70.156.0/26

S2 (30 hosts): 223.70.156.64/26
S3 (24 hosts): 223.70.156.128/27
S4 (11 hosts): 223.70.156.160/28
S5 (3+ hosts): 223.70.156.176/28
P2P (10 links): 223.70.156.192/30 - 223.70.156.228/30

5. At HQ, we need 120 subnets. In addition, we have 94 sites needing 5 subnets each (470
subnets), 24 sites needing 3 subnets each (72 subnets), 37 sites needing 2 subnets each (74
subnets), and 34 sites needing one subnet each. We also need three subnets per regional office to
support the OC-3 and T-3 links to HQ (567 subnets). This is a total of 1337 subnets. The largest
of these subnets supports 41 hosts, and thus requires a "/26" mask. With standard subnet
masking, our class "B" network will support 1024 "/26" subnets (10 subnet bits). Not enough.

To cover HQ and the regional offices, we need 770 subnets that each support 35-41 hosts. This
calls for a "/26" mask (which leaves room for substantial growth, up to 62 total hosts per subnet),
so let's calculate those subnets first:
 network sn host
------- ----------- ------
172.19. 00000000.00 000000 -> 172.19.0.0/26
172.19. 00000000.01 000000 -> 172.19.0.64/26
172.19. 00000000.10 000000 -> 172.19.0.128/26
172.19. 00000000.11 000000 -> 172.19.0.192/26
172.19. 00000001.00 000000 -> 172.19.1.0/26
172.19. 00000001.01 000000 -> 172.19.0.64/26
... and so on ...
172.19. 11111111.10 000000 -> 172.19.255.128/26
172.19. 11111111.11 000000 -> 172.19.255.192/26

There are 4096 "/26" subnets available, but we only need 770. Let's reserve another 130 or so for
additional regional offices and/or growth at HQ, and take the first 896, which would be
172.19.0.0/26 through 172.19.223.192/26.

Finally,we need to calculate the subnets for the serial links, of which there are 567. Using a "/30"
mask, and starting at 172.19.224.0/30, we have:

network sn host
------- --------------- ----
172.19. 11100000.000000 00 -> 172.19.224.0/30
172.19. 11100000.000001 00 -> 172.19.224.4/30
172.19. 11100000.000010 00 -> 172.19.224.8/30
172.19. 11100000.000011 00 -> 172.19.224.12/30
... and so on ...
172.19. 11111111.111110 00 -> 172.19.255.248/30
172.19. 11111111.111111 00 -> 172.19.255.252/30

As usual, we have more "/30" subnets (2048) than we need (567), so we're all set. Our scheme is:

HQ: 172.19.0.0/26 - 172.19.39.192/26 (160 subnets, 120 in use)

Regionals: 172.19.40.0/26 - 172.19.224.192/26 (736 subnets, 650 in use)
P2P: 172.19.224.0/30 - 172.19.255.248/30 (2048 subnets, 567 in use)

6. We have five sites, with the largest supporting 97 hosts, and requiring a "/25" mask. With a
class "C" network and a "/25" mask, we can only have two subnets ... and we need 9 (five for the
sites, and four for the links). It's VLSM to the rescue (we hope) ...

Using a "/25" mask for the 97-host site, we get:

network sn host
-------- -- -------
199.0.1. 0 0000000 -> 191.0.1.0/25

Next up is the 60-host site, which requires a "/26" mask:

network sn host
-------- -- ------
199.0.1. 10 000000 -> 191.0.1.128/26
Now for the 27-host site, which requires a "/27" mask:

network sn host
-------- --- -----
199.0.1. 110 00000 -> 191.0.1.192/27

And the 10-host site, which requires a "/28" mask:

network sn host
-------- ---- ----
199.0.1. 1110 0000 -> 191.0.1.224/28

Next the 4-host site, which requires a "/29" mask:

network sn host
-------- ----- ----
199.0.1. 11110 000 -> 191.0.1.240/29

And finally, the 4 point-to-point links, which require "/30" masks:

network sn host
-------- ------ ----
199.0.1. 111110 00 -> 191.0.1.248/30
199.0.1. 111111 00 -> 191.0.1.252/30

We have four point-to-point links, but we only have two "/30" subnets available! This means that
not even VLSM can solve our problem. There goes the $50K ... but wait! A possible solution!
Let's use "ip unnumbered" on the serial links. If we do, the serial interfaces do not require
addresses, and therefore the links do not require subnets. Disadvantage: we can't ping, telnet or
otherwise directly interact with the "ip unnumbered" interfaces. Advantage: $50K!!! Here's our
plan:

HQ (97 hosts): 191.0.1.0/25

S1 (60 hosts): 191.0.1.128/26
S2 (27 hosts): 191.0.1.192/27
S3 (10 hosts): 191.0.1.224/28
S4 (4 hosts): 191.0.1.240/29
P2P (4 links): "ip unnumbered"

We're cashin' that check! We're buyin' that Ferrari! We're lovin' VLSM! Note that Richco doesn't
have much room for growth on several of its subnets, and that it can't add any more locations.
Possible long-term fixes include an additional class "C" network, or a privately-addressed class
"B" (with NAT for Internet connectivity). For an additional $50K, we'll be glad to explain it to
them.

7. With the largest site having 11 hosts (and therefore wanting a "/28" mask), and only needing a
total of 13 subnets, we don't even have to use VLSM to solve this problem. All we have to do is
use our "/28" mask everywhere:

network sn host
 -------- ---- ----
199.0.1. 0000 0000 -> 199.0.1.0/28
199.0.1. 0001 0000 -> 199.0.1.16/28
199.0.1. 0010 0000 -> 199.0.1.32/28
199.0.1. 0011 0000 -> 199.0.1.48/28
... and so on ...
199.0.1. 1110 0000 -> 199.0.1.224/28
199.0.1. 1111 0000 -> 199.0.1.240/28

Granted, we are wasting addresses on the point-to-point links (as well as at the remote sites), but
so what? With this few hosts, we can re-address them pretty quickly if we need to (especially if
we are running DHCP). Of course, we could get fancy ... for example:

HQ: 199.0.1.0/28 (one subnet)

Remotes: 199.0.1.16/29 - 199.0.1.56/29 (6 subnets)
P2P links: 199.0.1.64/30 - 199.0.1.84/30 (6 subnets)

8. First, let's see how far we get with regular subnet masking. HQ needs one subnet (49 hosts).
There are six remotes, and each remote needs two subnets: one for the remote LAN (19 hosts),
and one for the link (2 hosts) to HQ. This is a total of thirteen subnets. Since HQ has 49 hosts, it
requires a "/25" mask (six host bits, which is sufficient for 62 hosts). If we use a /26 mask with a
class C ("/24") network, we have two bits available for subnetting. This only provides for four
subnets (including "subnet zero" and "subnet all-ones"). Since we need seven subnets for the
offices alone (not counting the WAN links), regular subnetting will not work. Let's try VLSM.

The 49-host HQ subnet requires a "/26" mask. Using the assigned network of 211.69.13.0/24,
and subnetting with a "/26" mask, we obtain the following four subnets:

network sn host
---------- -- ------
211.69.13. 00 000000 -> 211.69.13.0/26
211.69.13. 01 000000 -> 211.69.13.64/26
211.69.13. 10 000000 -> 211.69.13.128/26
211.69.13. 11 000000 -> 211.69.13.192/26

Let's use 211.69.13.0/26 for HQ. Now, let's take care of the six remote offices. Each remote has
19 hosts, and therefore requires a "/27" mask. Therefore, we will begin with 211.69.13.64/27,
and go from there:

network sn host
---------- --- -----
211.69.13. 010 00000 -> 195.39.71.64/27
211.69.13. 011 00000 -> 195.39.71.96/27
211.69.13. 100 00000 -> 195.39.71.128/27
211.69.13. 101 00000 -> 195.39.71.160/27
211.69.13. 110 00000 -> 195.39.71.192/27
211.69.13. 111 00000 -> 195.39.71.224/27

Now all we have to do is to determine the subnets for the six links between HQ and the remotes.
Too bad that we are out of available subnets! We have two choices, the first being to use "ip
unnumbered" on the WAN links. Remember that if we do this, we can't "Ping" (or otherwise
remotely manage) the WAN interfaces. The second possible solution is to use private addressing.
This would give us the option of using a Class "B" address space (lots of room for future
growth), but requires NAT for connection to the public Internet. The choice is up to you.

9. Full-mesh Frame Relay WANs are configured using a "point-to-multipoint" topology. This
means that all WAN interfaces are on the same subnet. Therefore, we need seven subnets
supporting 28 hosts each, and one subnet supporting seven hosts (the WAN interfaces). We can
solve this problem using standard subnet masking with a "/27" mask, and VLSM is not required.

10. We have the following options:

a. VLSM.

b. Regular subnet masking.

c. Get another Class "C" network.

d. Get a Class "B" or "A" network.

e. Use private addressing on WAN links.

f. Use "ip-unnumbered" on the WAN links.

g. Use private addressing on every subnet.

h. Share a subnet between multiple WAN links.

i. Sub-divide the large subnet into smaller subnets.

Let's look at them:

The first option, VLSM, is out, because we can't use VLSM with RIP v1 (it's a "classful" routing
protocol).

Back in Exercise 1, we showed that option "b" won't work.

As far as options "c" and "d" go, our ISP is not going to give us more address space if we only
have to support about 125 hosts, which easily fit on a Class "C" (unless we lie convincingly
about our needs).

Option "e" is not allowed, because using private addressing only on the WAN links would result
in a discontiguous network (one classful network on the LANs, another on the WANs), and
discontiguous networks are not allowed when using classful routing protocols.
That leaves us with the last four options. Option "f" is "ip-unnumbered", which the numbers (!)
may not support (we'll see). Option "g" might be an easy fix. Options "h" and "i", like option "f",
are possible if the numbers support them. Having narrowed it down to four possibilities, let's
examine those in more detail ...

First, we'll look at "ip-unnumbered" (option "f"). This would save us five subnets, so we would
still need six. Since our HQ subnet has 60 hosts, it requires six host bits. Oh-oh ... trouble! We
only have two subnet bits at our disposal (remember, we are using a Class "C" address space),
which will support only four subnets. Well, we didn't like this option anyway, because if we used
it, we lose the ability to ping and telnet directly to the WAN interfaces (both of which are which
are very useful for troubleshooting).

That brings us to option "g", private addressing all around. While easy to implement (we use
network 10.0.0.0/8, something in the 172.16-31.0.0/16 range, or several networks in the
192.168.0.0/24 range, and do normal subnet masking), it will require that we use NAT to
facilitate our Internet connectivity. This is not a problem if our border-router/firewall supports it
(IOS 11.2 or higher in the case of a Cisco), and if it doesn't break our apps (which is a possibility,
depending on what apps we use). This one might be a winner!

Option "h", sharing a subnet over WAN links, requires that the HQ router be a Cisco (the routers
at the remote sites do not need to be). Also, since we can share a subnet over up to a maximum of
four point-to-point WAN links, it only saves us three subnets. Therefore, we still need a total of
eight subnets. Unfortunately, as with option "f", we only have two subnet bits to play with (darn
those 60 users at HQ!), so we are short by four subnets. Nice try ...

Lastly, option "i", sub-division of the large subnet. We currently require one subnet with 60
hosts, five branches that each need 12 hosts, and five WAN links that require two hosts apiece,
which is a total of 11 subnets. If we were to divide the large subnet into five subnets of 12 hosts
each, we could then get away with using four host bits (a "/28" mask, which actually allows 14
hosts per subnet). This means that we would need five subnets (12 hosts each) at HQ, plus five
remote sites, plus five WAN links. Since we need a total of 15 subnets, we can do this with four
subnets bits. Eureka! We can do it! A "/28" mask on a Class "C" network is four bits of host, and
four bits of subnet, giving us up to 16 subnets, each with up to 14 hosts.

Note that this option is certainly sub-optimal, since either:

1. We need five router ports at HQ (which requires money, always in short supply), or

2. We need to use secondary addressing on the HQ LAN (which wastes HQ router CPU,
as well as LAN bandwidth resources, which also tend to be in short supply).

You have two workable options, private addressing all around, or sub-dividing the large subnet.
Think about current costs and future growth, then choose wisely, Network Designer!
Remember, there are several possible solutions to the problem of address space exhaustion (all of
them with potential drawbacks). These techniques can be mixed and matched, and include:

1. VLSM (requires a classless routing protocol).

2. Private addressing on WAN links only (probably results in a discontiguous network).

3. Private addressing on all subnets (requires NAT to Internet).

4. Obtain additional public address space (hard to justify).

5. Split one or more subnets (possibly requires secondary addressing).

6. The Cisco shared-subnet "kludge" (introduces some connectivity glitches).

7. IP Unnumbered (can't access the unnumbered interfaces via IP tools).

8. Bridge instead of route (makes it one big broadcast domain).

Waste not, want not!