Sequential Assignment with Gaps


A variation on the sequential assignment of addresses is formed by intentionally leaving a gap between blocks. This approach is potentially more practical than a straight sequential assignment. For example, it leaves more room for growth, and it can accommodate growth within any of its component networks without necessarily forcing you to renumber devices. This is particularly beneficial if you know your user communities are likely to grow in the future or if they have demonstrated a tendency to grow either unexpectedly or rapidly in the past.

Here are two key questions you need to answer before implementing this approach to address space management:

  • What size gaps should you provide between assigned address blocks? The gap would likely vary across the communities in your user base rather than being a constant size.

  • What is the best way to create those gaps? Remember, there are three different ways to create spare capacity: architectural, bitmask rounding, and explicit gaps. Using a sequential approach with gaps means that you will automatically use at least two of these tactics (gaps plus the architectural surplus).

The right answer to the second question might hinge on your answer to the first question. If only a small gap is needed, either architectural surplus or bitmask rounding might well suffice. If a larger margin for expansion is required, an explicitly defined gap is required.

Strengths and Weaknesses

Assigning address spaces sequentially, with intentional gaps between assignments, builds on the strengths of a sequential approach. It lets you see fairly quickly how much address space remains unused at the high end of your address block. More importantly, it does so while avoiding the primary weakness of the strictly sequential assignment method. This weakness is the inflexibility of that approach, which makes it absolutely crucial that you size the network blocks well the first time.

The explicitly defined gaps between assigned network address spaces supplement the natural margin for growth found within each assigned block with a buffer zone between assigned blocks. This free space could be used to satisfy growth within any network that is numerically contiguous to it. Thus, unlike the scenario we discussed earlier, you shouldn't have to renumber subnets except in extreme cases.

The obvious drawback of this approach is that it has the potential to waste address spaces. The larger the explicit gaps, the greater the waste of address spaces. This gets back to the original quandary of having to strike the right balance between current addressing needs and future expected needs. Of course, this approach offers an improvement over just sequential addressing with surpluses built into each network assigned, in that the free space can be shared between either of its two bordering address spaces. That explanation probably still sounds a bit nebulous, so let's look at how explicitly defined gaps in an address space can be beneficial in a realistic context.

Realistic Context

Let's take another look at how you could parse network addresses from within the example illustrated in Figure 14-1. This time, we'll assign our network addresses sequentially but leave gaps explicitly defined between them. This presents a great opportunity to see how a lack of planning can break a network assignment scheme. Table 14-3 maintained some semblance of binary symmetry. The first three network blocks assigned balanced each other out. We started out with two /28 networks (which equals one /27) and a /27 (which, together with the pair of /28s, accounts for a /26 taken out of the top of the address space). So far, the scheme was symmetrical. The last address space carved out for VLAN #3 was a /29. Because it was the last space and is followed only by an unformatted free space, this doesn't pose any problems whatsoever.

This scheme's symmetry can either be extended or broken through the insertion of free spaces. Although those spaces were intended to provide room for growth, they might not be usable, as you shall soon see. More importantly, such spurious blocks can impinge on neighboring blocks. That's not at all obvious when you look at decimal addresses, but it becomes remarkably clear when viewed in binary form. The next two sections show you both the wrong and right ways to manage an address space.

How Not to Manage an Address Space

Table 14-4 deviates from the norm by showing you how not to manage an address space. More specifically, it demonstrates the folly of improper planning. In this example, the network and address space used for the previous example remain the same, but I've opted to partition the network assignments with some buffer space. This space, in theory, affords room to grow. That's a good thingif it is implemented properly.

Take a look a Table 14-4, and then we'll cover the problems inherent within it.

Table 14-4. How Not to Assign Addresses with Gaps
 

Binary Network Plus Subnet Address

Decimal Translation

Base

11000000.10101000.01111101.00000000

192.168.125.0 /24

LAN management ports

11000000.10101000.01111101.00000000

192.168.125.0 /28

LAN management ports

LAN management ports

11000000.10101000.01111101.00001111

192.168.125.15

Intentional gap

11000000.10101000.01111101.00010000

192.168.125.16 /30

Intentional gap

Intentional gap

11000000.10101000.01111101.00010011

192.168.125.19

VLAN 0

11000000.10101000.01111101.00010100

192.168.125.20 /28

VLAN 0

VLAN 0

11000000.10101000.01111101.00011111

192.168.125.31

Intentional gap

11000000.10101000.01111101.00100000

192.168.125.32 /29

Intentional gap

Intentional gap

11000000.10101000.01111101.00100111

192.168.125.39

VLAN 1

11000000.10101000.01111101.00101000

192.168.125.40 /29

VLAN 1

VLAN 1

11000000.10101000.01111101.00101111

192.168.125.47

Intentional gap

11000000.10101000.01111101.00110000

192.168.125.48 /30

Intentional gap

Intentional gap

11000000.10101000.01111101.00110011

192.168.125.51

VLAN 2

11000000.10101000.01111101.00110100

192.168.125.52 /27

VLAN 2

VLAN 2

11000000.10101000.01111101.00111111

192.168.125.63

Intentional gap

11000000.10101000.01111101.01000000

192.168.125.64 /28

Intentional gap

Intentional gap

11000000.10101000.01111101.01001111

192.168.125.79

VLAN 3

11000000.10101000.01111101.01010000

192.168.125.80 /29

VLAN 3

VLAN 3

11000000.10101000.01111101.01100111

192.168.125.103

Unassigned

11000000.10101000.01111101.01101000

192.168.125.104

Unassigned

Unassigned

11000000.10101000.01111101.11111111

192.168.125.255


Table 14-4 shows the interblock gap effect. These gaps are based solely on the sizes of the blocks that are assigned to VLANs. However, the hostmaster responsible for this mess created the explicit gaps with only superficial thought about the future. If you consider the usability of each of those gaps, you might shake your head and wonder just what the explicit gaps do for you.

The problems begin almost immediately, because a /30 is inserted between a pair of /28s that were assigned to LAN management ports and VLAN 0. This causes VLAN 0 to start at the rather odd host address of .20. As a result, you can see that there are only 12 host addresses in that /28, whereas there should be 16.

NOTE

There's an easy way to avoid having subnets spill over boundaries and into another subnet's range. Simply make sure that the base address of each subnet assigned correlates mathematically to a CIDR boundary. Those boundaries are identified by the decimal value of each bit in the IPv4 address space. Those values1, 2, 4, 8, 16, 32, 64, and 128are powers of 2. Any other value is not a power of 2 and requires a mixed pattern of 1s and 0s. That's your clue that you are not starting your subnet on a CIDR boundary. A quick survey of the base IP addresses of the subnets in Table 14-4 vis-à-vis these powers of 2 should quickly identify the problem subnets.


VLAN 2 has the same problem. That is a /27, and its first host address should be 00000. Instead, because a /30 free space was inserted in front of it, it starts at 10100. This has the obvious effect of directly reducing the number of possible host addresses within that subnet. In this particular case, the number of definable host addresses remaining is insufficient for the number of hosts that require addresses in VLAN 2. A /27 should provide 32 possible host addresses; VLAN 2 requires 13, but only 12 are available. This wouldn't make users happy.

A more subtle problem with the way room for growth is provided in this example lies in the arbitrary sizes selected vis-à-vis the architectural limitations of the binary address space. To better illustrate this point, let's look at how we can grow VLAN 2 within the confines of this addressing scheme. VLAN 2 is a /27; it should have 32 total host addresses, but only 12 are available due to the preceding gap cutting into its space. If we increase its bitmask to a /26, we are essentially supernetting it with the next /27. Unfortunately, we didn't think this VLAN would grow much, so we left only a /28 unassigned as a buffer. In other words, we don't have enough room to supernet VLAN 2 with its neighboring free space.

I hope you realize that this is an extreme case designed solely to reinforce the importance of proper planning. This case demonstrates some of the ways an address space can be broken through mismanagement, even if it is well-intentioned. Although I won't go so far as to say that there is any one correct way to manage an address space, there is certainly a lot of room for improvement relative to the last example. The next section looks at one of the possible ways to correctly manage an address space.

In my opinion, this approach is at its best when used in conjunction with RFC 1918 addresses. That way, you have the luxury of up to 16 million IP addresses to play with, and your interblock gaps can be quite generouspreferably even symmetrical. The next section helps you better appreciate the concept of intentional gaps between assigned blocks by showing you the right way to implement this approach.




IP Addressing Fundamentals
IP Addressing Fundamentals
ISBN: 1587050676
EAN: 2147483647
Year: 2002
Pages: 118
Authors: Mark Sportack

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net