I have a Hyper-V server that I think the networking components are misconfigured. Even when I've set a static IP address, the server sends a constant stream of DHCP Discover broadcasts (the physical address in the broadcasts matches the Hyper-V host NIC). The DHCP server is responding with Offer responses, but the Hyper-V server just ignores it and sends another request.

This Hyper-V host has 3 NICs, one of which is dedicated to management of the host, the other provides an external network for several VMs. The third (integrated on the motherboard) is not used. There is also a Hamachi VPN adapter although that is not a virtual NIC. Here's wht it looks like: enter image description here

GTi LAN NIC is the one that matches the physical address in the offending DHCP packets. However, DHCP is disabled on that NIC, as you can see here: enter image description here

So I'm at a bit of a loss as to where these DHCP requests are coming from and why. Any ideas?

  • What's the physical NIC chipset? Latest firmware on it? – Chris S Jan 10 '13 at 15:43
  • Which Hyper-V NIC do the DHCP broadcasts originate from? Is it the NIC that the virtual switch is bound to? If so, do you have any Hyper-V guests that are configured to use DHCP? – joeqwerty Jan 10 '13 at 15:47
  • 1
    Wanted to say the same - totally funny to think it is the server, I Would seriously think more it is one of the virtual machines. – TomTom Jan 10 '13 at 15:49
  • If it was one of the VMs, wouldn't the physical address in the DHCP broadcast be that of the VM, rather than the host? – Tim Long Jan 10 '13 at 15:56
  • THe3oretically, but if it is not you can as well remove hyper-v from the tags and descriptions and talk of a serious issue in the networking stack. Eithr driver totally crappy or some SERIOUS issue, and I Can not imagine a scenario where this would go through quality control. BUt you an try - isolate the nic from hyper-v (change the network to not be connected or connect to another nic) and see whether the behavior continues. – TomTom Jan 10 '13 at 16:01

Problem solved. There was a rogue virtual NIC, which had no business being there, since the management LAN is on a dedicated physical NIC and is not shared with any virtual networks. This rogue virtual NIC was configured to use DHCP and had the same MAC address as the physical NIC.

Goodness knows what it was doing there - my best guess is that at some time in the past the management was switch over to the other NIC which meant everything was on one NIC, thus requiring the host OS to use a virtual NIC. Who knows? Anyway, deleting the rogue virtual NIC has solved the problem.

  • Good to know ;) – TomTom Jan 10 '13 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.