ocations to global network design much simpler. Assume for a minute that you've been requested to create a network for a new server farm. The powers that be insist there will only ever be 30 servers in the farm. You, being the bright admin, ask what kind of servers they will be. The response is that they will all be Oracle servers. The average admin might be quick to say that a /27 (255.255.255.224) network would be in order, as it provides 32 host addresses. Two of these are used for net- work and broadcast addresses, however, leaving no room for growth. This leads us to our next rule: Always allocate more IP address space than is originally requested. If your boss requests 30 IP addresses, give her a block of 64; if she requests 60, give her 128. While this may seem wasteful on the surface, you are always better off with excess IP addresses within a subnet. You must learn to balance the need for growth with the overall availability of addresses. Allocating 256 addresses when only 30 are requested is usually foolish, given normal growth patterns. Allowing for 30 percent growth is a good rule of thumb. Rounding up when you get to binary boundaries (16, 32, 64, etc.) makes this rule pretty easy to implement. To make things even more interesting, let's say there is already a server farm in your network. The IP network for the server farm is 10.100.100.0/24. There are already 10 servers in place, as well as the 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 refer- enced with a single access-list entry. If you all