none
DHCP scope filled with bad requests from virtual services hosts RRS feed

  • Question

  • Sorry for the wall of text, but I wanted to include as many relevant details as I could think of, as this is a very bizarre issue (possibly bug?).

    I have a 2012R2 DCHP server with a scope that is getting filled up with strange IP address leases. The leases' Names are the same as their IP addresses. Also, the Unique ID (MAC address) field has a hex string beginning with 31320e and is much longer than 12 characters. It appears that this string is just an ASCII representation of the IP address, and NOT a valid MAC address.

    I ran a packet capture on the DHCP server and found that these bad DHCP requests follow a pattern: they all originate from the IP addresses of servers hosting some kind of virtual services. Specifically, they came from addresses associated with a Hyper-V failover cluster (but not addresses associated with the hosted VMs), a single non-clustered Hyper-V host, and a file services failover cluster. The requests would also sometimes come from the IP addresses on the Access Points on the file services failover cluster.

    These bad DHCP discover requests also would come from MAC addresses that don't follow any pattern. All my VMs, for example, have MACs starting with 00-15-..., but these MACs would start with something random completely random like E9-EB or E1-6C. And I haven't seen any two of these random MAC addresses start with the same string, to my knowledge.

    I ran packet captures on both the DHCP server and the physical hosts in question. I saw that the DHCP server receives these discover requests and dutifully responds with a DHCP offer. I see this offer in the packet capture on only one of my 4 nodes in my Hyper-V cluster. But the Hyper-V server never sends a DHCP ACK after it receives the offer.

    These requests never get fully resolved, and are being sent at least every 5 minutes. They are completely filling up the small DHCP distribution range (about 35 addresses) with junk. I know I could work around this by deleting the junk when I need space, but I would really rather pin down the source.

    Also, to save time, please be aware that I have already read that this is sometimes caused by VOIP equipment, and ruled that out as extremely unlikely. All I have is an AudioCodes Mediant Gateway on this subnet, but none of these requests are coming from its MAC address. I also have Skype for Business VMs, but none of the requests are coming from their MAC addresses either. Beyond that, that is all the VOIP stuff on that subnet.

    My guess is that for some reason or another, these physical servers that host virtual services are making requests from some MAC whose origin I cannot trace. And these servers never send back an ACK even when they get an offer. However, DHCP works as expected for the known interfaces of all VMs, file services, and hosts. It just seems to be failing on these requests of unidentified origin. Please help!

    Friday, October 27, 2017 8:15 PM

All replies

  • Hi,

    Since the issue is more related with hyper-v, please have this asked in hyper-v Forum for better answers.

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverhyperv

    MAC address filtering may help you.

    Distribute DHCP Leases Based on MAC Address

    More information about  MAC address filtering  ,   please refer to the following article:

    https://technet.microsoft.com/en-us/library/dd759190(v=ws.11).aspx

    Best Regards,

    Frank



    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, October 30, 2017 7:16 AM
  • Thanks, I posted the question on the Hyper-V forum, per your suggestion: https://social.technet.microsoft.com/Forums/windowsserver/en-US/d316edf8-e492-4745-9ede-0688cbaf5edc/hyperv-and-file-servers-filling-dhcp-scope-with-invalid-leases?forum=winserverhyperv#d316edf8-e492-4745-9ede-0688cbaf5edc.
    Monday, October 30, 2017 3:26 PM
  • Not sure if this is relevant info, but after looking at my packet captures, I noticed that concurrent with these servers sending out their DHCP requests from unknown MAC addresses, they were also sending out DHCP requests on several other interfaces on migration/heartbeat/iSCSI subnets. These subnets do not have any route to any DHCP servers. And none of these other NICs' MAC addresses match the random ones from the bizarre requests.
    Monday, October 30, 2017 10:58 PM
  • Hi, 

    According to the content of the question, the purpose should be to know where these strange records are generated.

    In order to solve the problem, please collect the following information.
    1. After deleting the strange records, whether it occur again?
    2.If the DHCP server continues to generate these strange records, please screenshot or copy the records to us for reference.

    Best Regards,

    Frank


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, October 31, 2017 9:10 AM
  • Hi Frank,

    1) When I delete the records, they show up shortly thereafter, usually in about 1-15 minutes.

    2) I have included a screenshot of the reservations, but have obscured the 2nd and 3rd octets of the private IPs for privacy/security (This includes blocking out the corresponding hex in the Unique ID as well).

    Screencap of strange DHCP reservations

    Sincerely,

    Michael

    Thursday, November 2, 2017 11:56 PM
  • Hi,

    I have seen the screenshot of the reservations, and each Unique ID looks like an ASCII representation of the IP address. This may be due to problems caused by other services.

    In my view, you could use the following ways to solve the problem.

    1. Shorten DHCP lease duration.

    2. On the DHCP server, bind the IP address to the MAC address.

    Best Regards,

    Frank


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 3, 2017 7:07 AM
  • Hi,
    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

    Best Regards,

    Frank

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 8, 2017 8:55 AM
  • Hi,

    Was your issue resolved? 

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.
    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.
    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,
    Frank

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 17, 2017 9:53 AM