IP network for the server farm is 10.100.100.0/24. There are already 10 servers in place, as well as a router port that connects the network to the rest of the company. Assume the IP addresses in use are 1-11 (people like to allocate numbers in order). When asked for 30 more IP addresses, why not just provide the addresses 12-42? You could do this, and everyone would be fat, dumb, and happy. But here's where you can be smarter than the average admin. Instead of allocating a random list of IP addresses based on the last number used, allocate a block that agrees with our first rule: when allocating IP address space, endeavor to allocate a block that can be referenced with a single access list entry. If you allocate 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 originally requested. Because 30 IP addresses were requested, you should think ahead and 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 36-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 pre- viously existed. By comparison if you'd used 12-42, you would have needed the fol- lowing 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, 