ocate the range of 32-63, not only have you allocated enough IP addresses, but you can reference the range like this: Access-list 101 permit ip any 10.100.100.32 255.255.255.224 eq web But what about our second rule? Always allocate more IP address space than is origi- nally requested. Because 30 IP addresses were requested, you should think ahead, and Chapter 34: IP Design allocate 64. This changes things a bit, because according to the rules of subnetting, you can't allocate 64 contiguous IP addresses starting at 32. Looking back at Figure 34-3, you can see that you'll need to start at a multiple of 64. So, allocate 64-127: Access-list 101 permit ip any 10.100.100.64 255.255.255.192 eq web Still only one ACL entry! Now, you can create security rules based on logical groups of devices where none previously existed. To compare, if you'd used 12-42, you would have needed the following lines to achieve the same thing as the single line above: Access-list 101 permit ip and 10.100.100.12 255.255.255.252 eq web Access-list 101 permit ip and 10.100.100.16 255.255.255.248 eq web Access-list 101 permit ip and 10.100.100.32 255.255.255.250 eq web Access-list 101 permit ip and 10.100.100.40 255.255.255.254 eq web Access-list 101 permit ip and 10.100.100.42 255.255.255.255 eq web You've allocated twice the requested number of IP addresses, 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 with- out changing the IP scheme. This takes some planning, but when it pays off, it pays off in a big way. Figure 34-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 corresponding to subnet boundaries, later on you can actually subnet the network without changing the IP addresses