and you can address them using one-fifth the number of ACL entries. When you allocate groups of similar servers into what I like to call subnettable ranges, another benefit comes to light. When servers are grouped like this, you can remove them from the network and place them on their own physical networks without chang- ing the IP scheme. This takes some planning, but when it pays off, it pays off in a big way. Figure 36-5 shows how this idea might be applied. Even though the network in place is 10.100.100.0/24, if you apply your servers within logical groups of IP addresses cor- responding to subnet boundaries, later on you can actually subnet the network without changing the IP addresses of any servers. You'll only need to change the subnet masks and default gateways. Allocating IP Network Space Before After Server farm 10.100.100.0/26 10.100.100.64/26 Server farm 10.100.100.0/24 10.100.100.128/26 10.100.100.192/26 Figure 36-5. Subnetting an existing range This kind of thing happens more often than you might think. Perhaps the boss will decide that all of the Oracle servers should be on their own physical network for security reasons. No problem! Because you were smart enough to allocate their IP space along subnet boundaries, the entire range can easily be pulled out and moved to another interface. All the IP addresses will stay the same; only the subnet masks will change. The catch (isn't there always a catch?) is that you must be vigilant! If even one IP address is allocated in violation of these rules, you will have to renumber something to move a section of the existing network. Allocating IP Subnets When allocating IP subnets within a network, take care to allocate them in a logical fashion. You should strive for two goals: Allow for the largest possible remaining addressable space (i.e., the largest subnets possible in the remaining space). Allow as many subnets as possible to be expanded into the surrounding available space. As you will see, achieving both of these goals is a balancing act. I've encoun