Ditching Static IP for DHCP assigned addresses

We took the decisions to make all devices in our country offices other than the internet gateway automatically get their IP settings via DHCP, including servers, printers and wireless access points.  This goes against the grain for a lot of people, where static IP addresses are the rule for anything other than client PCs, but I think we managed to get a few benefits from doing this, which I shall outline in this post.

What was the main driver for going for this change?  Deploying printers – we’d often find that local contractors would just assign a local IP address to new printers that they connected to the network, sometimes conflicting with other devices on our network, and often failing to leave any record of the address they had used, meaning we could deploy equipment with addresses that conflicted.  Those basic problems created more work than we wanted to be spending troubleshooting such things, so I wanted to find a way to bring it under control.

The key – a feature rich DHCP server

What really enabled this for us was updating our core network infrastructure in all offices with Meraki Security appliances. These had more DHCP features than the previous Cisco ASA 5505.  The main thing that was missing from DHCP on the ASA 5505 was being able to assign fixed IP addresses by MAC address.

This has made it easy to take control of IP address assignment in our remote offices.

Designing the subnet

Some people don’t really care about which IP addresses are used for what, but since we occasionally want to share printers with other organisations, but don’t want their devices accessing everything on our subnet (or VPN) having a well thought out subnet helps write access rules.  If you put all your printers in a part of your subnet that can be defined by CIDR notation, then you can write a routing rule that allows access to and from this portion of your subnet very easily.

All our country office subnets are /24.  We subdivide those into a bunch of smaller /27 groups that can be addresses using CIDR. These aren’t strictly speaking subnets – you can use the first and last address – but they can be used in routing tables the same way.

  • 10.0.0.0/27 – Unused (a buffer for future use) – addresses 10.0.0.1 – 10.0.0.31 (the first address in this case isn’t usable since it is the start of the 10.0.0.0/24 subnet)
  • 10.0.0.160/27 – Servers – addresses 10.0.0.160 – 10.0.0.191
  • 10.0.0.192/27 – Printers – addresses 10.0.0.192 – 223
  • 10.0.0.224/27 – Network devices – addresses 10.0.0.224 – 10.0.0.254 (the last address can’t be used as it is the broadcast address for the 10.0.0.0/24 subnet.

So by assigning printers with addresses between 10.0.0.192 and 223 it is possible to write an access rule allowing traffic only to and from printers to devices in a connected subnet using 10.0.0.192/27.

Enforcing the subnet organisations

By creating reserved ranges in the DHCP page, it is possible to both record the organistation of your subnet, and ensure that the DHCP server doesn’t allocate any PC clients an address in the ranges you’ve specified:

Meraki DHCP Reserved Range

Anything addresses haven’t specified (10.0.0.32 – 10.0.0.159 here) is available for allocation to any client added to the network.

Collecting the MAC addresses

Some devices have the MAC address printed on a label on the device, which makes it easy to pre-assign the address.  That isn’t always the case.  However, if you can identify a newly connected device in the Meraki dashboard client list, you can get its MAC address – or even faster, assign it an address from the client page:

Meraki Address Assignment

Super easy.

Config is the documentation

Now if we want to find out what address was assigned, we can just look in the DHCP config page to get a list of Fixed IP assignments:

Meraki DHCP Fixed Assignments

That is always up to date, compared to the spreadsheets we maintained before (or didn’t – they were often out of date).

Assigning and Changing IP addresses

Most devices are shipped configured to get their IP settings via DHCP, so it is easy to deploy new devices in remote locations – local staff don’t need to do much more than plug the device into the network.

If we want to change an IP address (or assign the same IP address to replacement hardware) we can just connect the device to the network, change the DHCP settings, then power cycle the device to pick up the settings.  That is very easy to communicate to local staff than walking them through configuring IP settings on a printer.

Everything is configured to use DHCP (apart from the DHCP server itself of course) and life is a little bit simpler.

Bonus tip – Option 15

If you need to enable “naked” internal hostname resolution for clients, don’t forget to set DHCP option 15 to add your domain suffix – e.g. example.local.  If you have multiple internal domains that need to be resolved you can also use option 119 to list a comma delimited list for clients to search through.

Leave a comment