May 072019
 
Sophos UTM with SFP Modules Picture

In the many years I’ve been providing IT Services, I’ve noticed that whenever taking over a customer from a competitor, or providing consulting services for a company that has IT staff, that I don’t see DHCP reservations being used all that frequently.

I wanted to write a post and create a video to discuss the comparison, when each should be used and the various case scenarios. I’m hoping my readers may provide their own input in the comments.

See below for the video, or read on for the blog post!

As an example: When a customer was purchasing a VoIP PBX, the PBX vendor get angry when I requested that it be configured for DHCP so that a DHCP reservation could be used, I advised I’d prefer this method so I could change the IP when needed for maintenance or network restructuring. They tried to convince me the IP will change on a DHCP Server and the port forwarding will stop working, because they simply had no idea of what a DHCP reservation was. Ultimately when the day came where I had to change the IP and firewall rules for the PBX, I had to log a support call with the vendor since I couldn’t change the IP myself (which resulted in delays, and costs). If we were using DHCP reservations, I could have simply modified the firewall rules, modified the IP address on the reservation, and restarted the device using the buttons on the front panel (I didn’t have any other access to the device).

Just to state the obvious:

  • A static IP address is an IP address that’s manually set on a NIC (Network Interface Card).
  • A DHCP Reservation is a pre-set IP that’s provided by a DHCP Server, and given to a NIC when a NIC calls out to a DHCP server for an IP address.

Static IP Addresses

It’s in my opinion that for server, network, core, and all top level infrastructure, all of these devices and services should be configured with Static IP addresses.

These devices which are almost always running, and have other services that rely on them, require a set static IP that should and will not change. Typically, these IP addresses will never change, even when major changes are being made to the core infrastructure.

These addresses should always be logged, documented, and added to network topology maps.

An example of devices commonly seen with Static IPS:

  • Servers
  • Storage (SAN, NAS)
  • Network Switches, Routers, Gateways, Load Balancers
  • Printers
  • Wireless Access Points
  • Computers/Workstations using special services (or requiring firewall exceptions)

DHCP Reservations

DHCP stands for Dynamic Host Configuration Protocol, and was created to dynamically configure hosts networking configuration on the fly for easy deployment.

In it’s most simplest explanation, when a computer (or device) that is configured to use DHCP reaches out to the network, the DHCP server will assign and provide an IP address for the computer to use.

In home networks, pretty much every computer and device will get it’s IP address from the DHCP server running on the router.

In business networks, pretty much every computer and device that isn’t hosting services will get it’s IP address from the DHCP server running on one of their servers or routers.

DHCP Servers support something called a “DHCP Reservation”, which essentially allows you to provide a pre-set IP address to a specific client based on it’s physical MAC address. This means that the device will always get the same IP address and it will never change (whereas they typically do on occasion).

I’m surprised I don’t see these used more often, as they can become quite the powerful tool on the IT tool belt when used properly. I’ve listed some pros and cons below.

The Pros:

  • Manage IP addresses (IP reservations) from a single console
  • Ability to change IP addresses on the fly easily from a single console without having to log in to the device.
  • Manage network topology for ROBO (Remote Office, Branch Office) remotely, easily, and efficiently.
  • Manage IP addresses for 3rd party devices that you don’t normally have access to modify (tell the vendor to set to DHCP), reducing support calls for external services.
  • Ability to create different PXE boot environments as each reservation can have it’s own PXE boot options assigned.

The Cons:

  • Device must support DHCP Configuration.
  • The device MUST RELY on a DHCP Server once set to use DHCP. If the DHCP Server is down, so is the device.
  • If rogue DHCP servers appear on your network, it may disrupt communication (this can also happen with static IPs and conflicts).

So with the list above, DHCP reservations look pretty powerful. The next question, is where do we use DHCP reservations. Let’s finish off with the devices we’d use them on, and what use case scenarios apply.

Devices:

  • Wireless Access Points
  • Printers
  • 2nd Level (non core) Routers and Gateways
  • IoT Devices
  • IP Phones
  • IP PBX Systems (VoIP, Traditional with IP Management, etc).
  • Thin Clients and Zero Clients

Use Cases:

  • Remote Offices (remote sites with limited access)
  • Remote Support environments
  • Branch Offices
  • IP Phone Networks
  • Wireless LAN Access Point VLANs

DHCP Reservation Use Cases

I use DHCP reservations frequently with customers that have remote or branch offices in remote geographical areas. When supporting these users and troubleshooting issues, it’s awesome to be able to just log in to the DHCP server to change IP addresses of printers, phones, and wireless access points.

Also, when configuring, shipping, and deploying new devices to these offices, I can simply log and write down the MAC address, configure the DHCP reservation, and the device will get the IP address I’ve chosen once it’s connected to the network and powered on.

Using DHCP reservations, you can easily make big changes to these remote networks without having to be present. If you were to use Static IPs and something was misconfigured, this might cause a physical visit to the site to resolve.

If by change a vendor directly dropships equipment to the remote site, I can simply call someone at that office to get the MAC address. Most devices with a NIC (printers, MFPs, wireless access points), all usually have their MAC addresses printed on the outside of the box. With this information provided, I can login to the remote server, create a DHCP reservation, configure drivers, and push the device config out to the network.

DHCP reservations add to the whole concept of a centrally managed environment, which further helps ease of maintaining, and supporting it.

Leave a comment and let me know your thoughts!

  16 Responses to “Static IP vs DHCP Reservation”

  1. Very good information. Thanks for sharing.

  2. Would you create a DHCP reservation for your network switches? I have about 15 –

  3. Hi Kevin,

    Typically static IPs would be used for switches, as they would generally always need to be accessible, even when a DHCP server is down.

    There might be a few odd non-standard use cases where non-backbone switches may use reservations in remote sites, but I could only see this ever being used in geographically remote sites that aren’t easy to visit.

    Stephen

  4. Hi Kevin,

    Your explanations are so easy to follow.

    Thank you for not assuming that we’re all IT professionals!

    Regards,

    Jerry

  5. Hi Stephen,

    So sorry to address you as “Kevin”…my bad. I had just read your reply to Kevin.

    Jerry

  6. No problem Jerry! Cheers!

  7. I’m trying to set up parental controls via a dns server. I realized that it was possible to get around the dns server by changing the dns server on each device. I’m trying to figure out how to force all devices on my network to go through the dns server I have chosen. I’ve come across port forwarding a few times but am struggling to nail down the steps to make it work. Could you possibly help me with this? Thanks in advance!

    In Christ,
    Kenny Sparks

  8. Thank you for the thorough, easily understandable explanation, Kevin.

  9. I agree whole heatedly. It’s astonishing to think that any vendor supplying network equipment wouldn’t know DHCP. I’ve known about reservations for a long while, but it’s never really been showcased as a solution. Whatever makes our lives easier I always say.

  10. This is fantastic info, but when you are a 3rd party vendor that has the only remote access to a device, static is best. It allows for NAT IP configs as well as other VPN server options the hospitals (in my case) use. In other cases, when a reservation or reservations aren’t documented properly, remote access becomes a problem when DNS and anything else is changed. Obviously this can happen with static as well, if the hospital doesn’t notify the 3rd party of the changes, however, this is generally, at least in my teams experience not the case. Hope that improves things.

  11. I follow basic rules for when to use static IPs and DHCP reservations:
    1) Router or Core switch – Static IP
    2) Server – Static IP
    3) All other infrastructure is DHCP w/reservations (switches, APs, printers, cameras, DVRs, time clocks, appliances, etc)

    I contemplated using DHCP for most servers, but since DHCP servers have to be static and some applications might have problems if an IP changes unexpectedly (like due to a DHCP server failure or even a bad switch vLAN change), I decided to keep all servers static.

    I’ve had many vendors tell me they don’t support DHCP, but 100% of the time they don’t understand DHCP w/reservations is effectively the same as a static IP. I’ve never come across a device connected to the network that doesn’t support DHCP even though I’ve been told by a vendor on multiple occasions their equipment doesn’t support it. I do not budge on this, and force them to learn their equipment better. I’m sure something exists out there that doesn’t support DHCP, but do I really want to use something with that bad of a network implementation? What else can’t it do?

    The cons are minimal and can mostly be mitigated via a robust DHCP server infrastructure.
    1) DHCP server must be available – Redundant DHCP Servers make this robust
    2) Nothing can interfere with requests between client and server
    This one is obvious, but the only problem I’ve had in the past 15 years using DHCP reservations was our MPLS provider all of a sudden stopped passing DHCP requests from one site to our data center. The work-around was to install a local DHCP server with the reservations defined until the problem was resolved. Once the provider fixed the problem, I just re-pointed the routers to the data center DHCP servers again.
    3) A rogue DHCP server can cause problems. It’s pretty quick to identify this is happening and doesn’t take long to find it. If you disable or isolate unused switch ports, then this has very little chance of happening.

    It’s important your lease times are long enough to give you time to respond to DHCP server problems.

    The pros are massive:
    1) All IPs are authoritatively documented in DHCP (minus routers and servers). This makes managing the IP space so much easier. I put in dummy reservations for servers just so DHCP includes those as well.
    2) There is almost no chance of an IP conflict
    3) Infrastructure setup can be done in one location (like corporate) and moved to its final destination without any reconfiguration required. It’s convenient to setup switches, APs, and printers at corporate while on the network, and as soon as you plug them in at the remote location they just work (setup the IP reservation ahead of time).
    4) Reconfiguration of IP scheme is trivial. I’ve done this many times to correct poor IP schemes I’ve inherited, and by setting the lease time to 5 minutes before the change, all devices pull new IP information almost immediately. If there’s a mistake on vLANing, the correct IP will be pulled in only a few minutes once fixed. When the project is complete, set the lease times back to normal values.
    5) It’s trivial to replace a device because there will never be an IP conflict. Modify the IP reservation when it’s time for the new device to be installed, and the new device will take over the IP and the old device can still be connected if necessary as it will just pull a random IP at this point (or a set IP if you want to setup another reservation).
    6) The IP scope range can be used more efficiently because IPs are managed centrally on the back-end, and it’s not reliant on devices being configured with the correct IP. I never have to guess what device has what IP and wonder if something was set to the wrong IP. I can look at my DHCP server to know what’s what.
    7) If you need to make a default gateway change (either temporary or permanent), it’s trivial. This has come up before because we needed to change the destination of traffic outgoing from a location temporarily while service was being performed on the primary equipment. It’s an unusual event because normal redundancy usually addresses problems like this, but I’ve had larger failures to deal with that required temporary installations to cover until repairs to utility infrastructure is completed. Once the repair is done, updating the default gateway again gets everything flowing properly.

    I’m an adamant supporter/enthusiast for DHCP reservations. 🙂

  12. Ben, you’re awesome! Thanks for contributing to the discussion! Excellent advice!

  13. Hi Steven,
    If a device has a static IP address should that address be included in the DHCP Scope, and then ‘dummy reserved’ out, or should the static IP address be outside the DHCP Server Scope?
    Say the network is not too big – can I set a scope of 192.168.1.2 to 192.168.1.99, then Fix the IP addresses of my Printers, Accesspoints etc into the 192.168.1.100 to 192.168.1.150 range, say, which won’t require any reservations as the fixed IP devices wont request IP addresses anyway, or should I Fix the IP addresses inside the scope, and just give them reservations, so no other device is accidentally given the address belonging to a fixed device. The advantage I see for the second method is that the connected devices all exist within the DHCP scope, and can be documented.
    Thanks for your article – just wondering about best practice – pros and cons of the two methods.

  14. Hi Robin,

    For best practice, I wouldn’t recommend using Static IPs inside of the DHCP pool range. For example, you’d want to have your DHCP range from .100 to .199 and then have your servers in .10 to .19 and printers from .20 to .30, etc… It just avoids problems…

    As for DHCP reservations, you can have those within or outside of your DHCP scope.

    Cheers,
    Stephen

  15. This exercise asks you to create a DHCP reservation on the current scope, to ensure one of our servers will have the same IP assigned to it.
    Create a reservation on your DHCP server to ensure that one of your servers (for instance SRV02) will always have the same IP assigned to it. We want to assign ip 10.1.1.200, for instance
    Once you create the reservation print the output of the command:
    Get-DhcpServerv4Reservation -ComputerName “dhcp01” -IPAddress 10.1.1.200 | fl *, (the IP is merely for illustration purposes)
    kindly answer me asap.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)