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:
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 WeaknessesAssigning 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 ContextLet'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 SpaceTable 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 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. |