P addresses that are not right- fully owned or just a designer's lack of understanding of the benefits of proper IP allocation, a poorly designed IP network can cause daily headaches and increased trou- bleshooting time. And because a poorly designed IP scheme can take months to rectify, the problem usually gets worse over time because no one wants to take on the task of renumbering the entire network. There are some simple rules that can help when you're designing a network using IP address space. Here is the first one: When allocating IP address space, endeavor to allocate a block that can be referenced with a single access list entry. Following this simple rule will make everything from server allocations to global net- work design much simpler. Assume for a minute that you've been asked 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 is in order, as it provides 32 host addresses. Two of these are used for network 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 until you get to binary boundaries (16, 32, 64, etc.) makes this rule pretty easy to implement. Chapter 36: IP Design To make things even more interesting, let's say there is already a server farm in your network. The 