The first step in rolling out any solution is to plan it properly. Planning out your network layout is one of the most important decisions you'll ever make in your organization. Even if as an administrator you're not responsible for the layout and just go along with what your network administrator provides, understanding this layout and being able to deploy your solutions to fit within it is also very important.

Planning an IP address scheme involves estimating how many devices will need to connect to your network and being able to support them. In addition, a good plan will account for potential growth and allow expansion as well. The main thing that factors into this is the size of your user base. Perhaps you're a small office with only a handful of people, or a large corporation with thousands of users and hundreds of virtual machines. Even if your organization is only a small office, there's always room for growth if your organization is doing well, which is another thing to take into consideration.

Typically, most off-the-shelf routers and network equipment come with an integrated Dynamic Host Control Protocol (DHCP) server, with a default class C (/24) network. Essentially, this means that if you do not perform any configuration at all, you're limited to 254 addresses. For a small office, this may seem like plenty. After all, if you don't even have 254 users on your network, you may think that you're all set. As I mentioned before, potential growth is always something to keep in mind. But even if we remove that from the equation, IP addresses are used up quite quickly nowadays—even when it comes to internal addressing. An average user may consume three IP addresses each, and sometimes more. For example, perhaps a user not only has a laptop (which itself can have both a wired and wireless interface, both consuming an IP), but perhaps they also have a mobile phone (which likely features Wi-Fi), and a Voice over IP (VoIP) phone (there goes another address). If that user somehow manages to convince their supervisor that they also need a desktop computer as well as their laptop, there will be a total of five IP addresses for that one user. Suddenly, 254 addresses doesn't seem like all that many.

The obvious answer to this problem is splitting up your network into subnets. Although I won't go into the details of how to subnet your network (this book is primarily about servers and not a course on network administration), I mentioned it here because it's definitely something you should take into consideration. In the next section, I'll explain how to set up your own DHCP server with a single network. However, if you need to expand your address space, you can easily do so by updating your DHCP configuration. When coming up with an IP address layout, always assume the worst and plan ahead. While it may be a cinch to expand your DHCP server, planning a new IP scheme rollout is very time consuming, and to be honest, annoying.

When I set up a new network, I like to divide the address space into several categories. First, I'll usually set aside a group of IP addresses specifically for DHCP. These addresses will get assigned to clients as they connect, and I'll usually have them expire and need to be renewed in about one day. Then, I'll set aside a block of IP addresses for network appliances, another block for servers, and so on. In the case of a typical 24-bit network, I might decide on a scheme such as the following (assuming it's a small office with no growth planned):

Network: 192.168.1.0/24 
Network equipment: 192.168.1.1 - 192.168.1.10 
Servers: 192.168.1.11 - 192.168.1.99 
DHCP: 192.168.1.100 - 192.168.1.240 
Reservations: 192.168.1.241 - 192.168.1.254 

Of course, no IP address scheme is right for everyone. The one I provided is simply a hypothetical example, so you shouldn't copy mine and use it on your network unless it matches your needs. I'll use this scheme for the remainder of this chapter, since it works fine as an example. To explain my sample rollout, we start off with a 24-bit network, 192.168.1.0. If you're accustomed to the classful model, this is the same as a class C network. The address 192.168.1.0 refers to the network itself, and that IP is not assignable to clients. In fact, the last IP address in this block (192.168.1.255) is not assignable either, since that is known as the Broadcast Address. Anything that's sent to the broadcast address is effectively sent to every IP in the block, so we can't really use it for anything but broadcasts.

Next, I set aside a group of IP addresses starting with 192.168.1.1 through 192.168.1.10 for use by network appliances. Typical devices that would fit into this category would be managed switches, routers, wireless access points, and so on. These devices typically have an integrated web console for remote management, so it would be best to have a static IP address assignment. That way, I'll have an IP address available which I can use to access these devices. I like to set up network appliances as the first devices so that they all get the lowest numbers when it comes to the last number (octet) of each IP. This is just personal preference.

Next, we have a block of IP addresses for servers, 192.168.1.11 through 192.168.1.99. This may seem like quite a few addresses for servers, and it is. However, with the rise of virtualization and how simple it has become to spin up a server, this block could get used up faster than you'd think. Feel free to adjust accordingly.

Now we have our DHCP pool, which consists of addresses 192.168.1.101 through 192.168.1.240. These IP addresses are assignable to any devices that connect to our network. As I mentioned, I typically have these assignments expire in one day to prevent one-off devices from claiming and holding onto an IP address for too long, which can lead to devices fighting over a DHCP lease. In this situation, you'd have to clear your DHCP leases to reset everything, and I find that to be too much of a hassle. When we get to the section on setting up a DHCP server, I'll show you how to set the expiration time.

Finally, we have addresses 192.168.1.241 through 192.168.1.254 for the purposes of DHCP reservations. I call these static leases, but both terms mean the same thing. These addresses will be assigned by DHCP, but each device with a static lease will be given the same IP address each time. You don't have to separate these into their own pool, since DHCP will not assign the same address twice. It may be a good idea to separate them, if only to be able to tell from looking at an IP address that it's a static lease, due to it being within a particular hypothetical block. Static leases are good for devices that aren't necessarily a server, but still need a predictable IP address. An example of this may be an administrator's desktop PC. Perhaps they want to be able to connect to the office via VPN and be able to easily find their computer on the network and connect to it. If the IP was dynamically assigned instead of statically assigned, it would be harder for them to find it.

After you carve up your IP addresses, the next thing is creating a spreadsheet to keep track of your static IP assignments. It doesn't have to be anything fancy, but it will certainly help you later. Ideally, your IP layout and the devices that populate it would be best placed within an internal wiki or knowledge-base solution that you may already be using. But if you don't have anything like that set up yet, a spreadsheet can serve a similar purpose. In my example IP spreadsheet, I include a designation of (R) if the IP address is a reservation or (S) if the IP address is a manually assigned static address. I also include the MAC address of each device, which will come in handy when we set up our DHCP server in the next section:

Although subnetting is beyond the scope of this book, it's definitely something you should look into if you're not already familiar with it. As you can see from my example layout, our number of available addresses is rather limited with a 24-bit network. However, this layout will serve as an example we can follow that's good enough for the remainder of the chapter.