If you have any amount of test or development infrastructure, a rogue DHCP server has surely shown up. While I’ve been lucky to never have it show up on a production segment, I’ve seen many a network administrator track one down and shut down a port to try to find the offending virtual machine.
As it turns out, virtual machines can be hard to find as they have different MAC address formats and may move around to different segments if on a laptop or host with migration technology enabled.
With Hyper-V R3, Hyper-V administrators can make their virtual machine libraries disallow DHCP server packets to be sent from the host by default. The DHCP guard feature sets this property at the virtual machine network configuration. This step is shown in Figure A:
The selected area has the DHCP Guard option selected.
There are a number of ways to tackle this problem, including switch configuration and possibly arcane server administrative practices. However, with any test or development capacity, the rules seem to lighten as requirements in these environments differ from their production counterparts.
One of Active Directory’s keystone features is authorization for DHCP servers. Given that Hyper-V is quite aware of Active Directory and other Windows environments, this works well in the grand scheme of things to protect against the unauthorized DHCP advertisements.
DHCP Guard is an example of a granular setting that should be set as part of the virtual machine library creation process. This is for both server and client operating systems. Should a user install something like VMware Workstation, Oracle VM VirtualBox, or another type II hypervisor, additional operating systems (including a DHCP server) could be added within.
Do you see value in this configuration option? I do! Would you configure your library virtual machine to use this setting? Share your comments below.