none
DHCP leases not showing in GUI RRS feed

  • Question

  • We have a client with a 2012 R2 DHCP server on a network we inherited when we took over.  They were set up as a Class A network (10.0.0.0 / 8) and we'll redo that at some point to something more sensible.  They could live as a /24.

    But DHCP keeps filling up.  I've even tried widening the scope which was originally 10.0.0.50 through 10.0.0.250.  Should be plenty enough, even with their new VOIP phones needing reservations.

    A few months ago we started getting DHCP full messages, although the GUI would show only maybe 50 to 60 percent of the lease range was even used.  Superscan verified the same.

    Nowhere in the GUI does it show too many leases in use.

    But this morning I did:

    netsh dhcp server scope 10.0.0.0 show clients

    And it shows things from as far back as more than a year ago.  This shows addresses used that the GUI doesn't display at all.  All of the weird ones in the netsh command list won't ping, but they've got addresses leased.

    Most of them also are bogus MAC addresses - like it started at an arbitrary spot and just incremented only the first octet.  So for example, at 9:38:00 I see unique ID 30-00-00-0a got .48, then 10 seconds later unique ID 31-00-00-0a got .49

    This continues.  Here is an example:

    10.0.0.205      - 255.0.0.0      - 40-a8-f0-60-3d-66   -5/15/2017 7:59:28 AM   -D
    10.0.0.206      - 255.0.0.0      - ce-00-00-0a         -5/8/2017 7:26:33 AM    -D
    10.0.0.207      - 255.0.0.0      - d4-be-d9-9d-a6-15   -5/15/2017 7:59:17 AM   -D
    10.0.0.208      - 255.0.0.0      - d0-00-00-0a         -5/8/2017 7:26:46 AM    -D
    10.0.0.209      - 255.0.0.0      - d1-00-00-0a         -5/8/2017 7:26:59 AM    -D
    10.0.0.210      - 255.0.0.0      -00-07-4d-5c-04-65   - NEVER EXPIRES        -U
    10.0.0.211      - 255.0.0.0      - d3-00-00-0a         -5/8/2017 7:27:12 AM    -D
    10.0.0.212      - 255.0.0.0      - d4-00-00-0a         -5/8/2017 7:27:25 AM    -D
    10.0.0.213      - 255.0.0.0      - d5-00-00-0a         -5/8/2017 7:27:38 AM    -D
    10.0.0.214      - 255.0.0.0      - d6-00-00-0a         -5/8/2017 7:27:51 AM    -D
    10.0.0.215      - 255.0.0.0      - d7-00-00-0a         -5/8/2017 7:28:04 AM    -D
    10.0.0.216      - 255.0.0.0      - d8-00-00-0a         -5/8/2017 7:28:17 AM    -D
    10.0.0.217      - 255.0.0.0      - d9-00-00-0a         -5/8/2017 7:28:30 AM    -D
    10.0.0.218      - 255.0.0.0      - da-00-00-0a         -5/8/2017 7:28:43 AM    -D
    10.0.0.219      - 255.0.0.0      - db-00-00-0a         -5/8/2017 7:28:56 AM    -D

    I've exported the scope, deleted it from the GUI, then imported, but of course the bogus leases came as well.

    When I try to reconcile the scope, and click "verify" it shows just 5 addresses (0.45 through 0.49) and if I click "reconcile" the dialog box empties until I click "Verify" again and they show back up.  Inconsistencies are not getting fixed.

    About the only thing I can find online is that a post a couple years ago mentioned that someone had something similar from a bad printer.  I've got someone on site trying to track down who came in when this morning so we can see if we can narrow things down, but meanwhile, why are there so many things that don't show up at all in the DHCP GUI?  For now I'd settle for being able to delete these bogus entries but since they're not in the GUI I can't, and I've been unable to find any netsh commands yet that would allow me to delete leases that way, but I'm still looking.  I also found a thread about 3 years old from a version of kaspersky that would cause issues, and clients kept requesting DHCP addresses thus filling up the scope.

    One other tech went as far as to set the lease for 2 seconds, but nothing ever gets released that's in my list from netsh.  I changed that as well, didn't need the server to be THAT burdened...

    Anyone have any suggestions?  They have a lot of reservations for PC's that they used to remote into from outside (reserved IP so they could have the consistent IP for the firewall rule allowing the inbound traffic) but we've since put in a terminal server, so I'm trying to get a list of any that still require something specific on their PC's, rather than the terminal server, so I can delete the rest of the reservations and make this a bit more manageable.  That way I can just delete the entire scope, create it from scratch without having so many reservations to recreate.

    I just would like to figure out what the bogus requests are. 

    Thanks

    John


    John

    Monday, May 8, 2017 2:27 PM

Answers

  • Hi jdthird,

    1. According to your description, it seems the DHCP database has been crashed, and I would agree with you that recreating the DHCP server from scratch;

    2. As for the IP address assignment, it's recommended to configure static IP addresses for important servers, and exclude these IP addresses in the DHCP scope. Configure reservation IP addresses for those who need a stable IP address, such as printers and other function devices. As for the remote users who need to remote into the internal network from outside, it's recommended to configure VPN for them, and use NPS to authenticate for the VPN connection, so that the firewall settings may be simple and we do not need to reserve IP addresses for them.

    3. If you are still troubleshooting the bad lease of the original DHCP server, you may use network monitor to help check if the DHCP server actually receive the discover packet from these "bogus" mac addresses. If not, also check if there are any third-party software running on the DHCP server, and run anti-virus scan to check if the health of the DHCP server.

    Best Regards,

    Anne


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

    • Marked as answer by jdthird Friday, May 19, 2017 5:01 PM
    Tuesday, May 9, 2017 6:54 AM
    Moderator
  • Hi jdthird,

    >I can't believe there's not some way outside of the GUI to delete the reservations?

    Check if the powershell command could be of help:

    https://technet.microsoft.com/en-us/library/jj590711(v=wps.630).aspx

    Best Regards,

    Anne


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

    • Marked as answer by jdthird Friday, May 19, 2017 4:59 PM
    Tuesday, May 16, 2017 7:28 AM
    Moderator

All replies

  • Hi jdthird,

    1. According to your description, it seems the DHCP database has been crashed, and I would agree with you that recreating the DHCP server from scratch;

    2. As for the IP address assignment, it's recommended to configure static IP addresses for important servers, and exclude these IP addresses in the DHCP scope. Configure reservation IP addresses for those who need a stable IP address, such as printers and other function devices. As for the remote users who need to remote into the internal network from outside, it's recommended to configure VPN for them, and use NPS to authenticate for the VPN connection, so that the firewall settings may be simple and we do not need to reserve IP addresses for them.

    3. If you are still troubleshooting the bad lease of the original DHCP server, you may use network monitor to help check if the DHCP server actually receive the discover packet from these "bogus" mac addresses. If not, also check if there are any third-party software running on the DHCP server, and run anti-virus scan to check if the health of the DHCP server.

    Best Regards,

    Anne


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

    • Marked as answer by jdthird Friday, May 19, 2017 5:01 PM
    Tuesday, May 9, 2017 6:54 AM
    Moderator
  • Reservations are only for the few PC's that need RDP access, and printers and a few hardware devices for their plant.  Easier to manage with reservations than having to edit directly the devices anytime something changes.

    I will see if I can track down any details with network monitor.  There's no third party software at all on the server, it's nothing but a DC / file server.

    Thanks

    John


    John

    Tuesday, May 9, 2017 1:46 PM
  • May have a lead with the packet capture - an access point is requesting DHCP nearly nonstop, but shows "down" and isn't pingable, so may be in a bad state.   Meanwhile, anyone have any way to delete all those reservations that do NOT show up in the GUI?  I'd like to test to see if this is doing it without having to delete the scope just to get rid of those "hidden" reservations, and have to rebuild it again. 

    I can't believe there's not some way outside of the GUI to delete the reservations?

    Thanks

    J


    John

    Tuesday, May 9, 2017 2:35 PM
  • Hi jdthird,

    >I can't believe there's not some way outside of the GUI to delete the reservations?

    Check if the powershell command could be of help:

    https://technet.microsoft.com/en-us/library/jj590711(v=wps.630).aspx

    Best Regards,

    Anne


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

    • Marked as answer by jdthird Friday, May 19, 2017 4:59 PM
    Tuesday, May 16, 2017 7:28 AM
    Moderator
  • Can't believe I couldn't find this with my google searches.

    Thanks!  This seems to have done the trick.  Since we found the bad port on the switch the access point was on, the DHCP requests are finished, but the scope was still full.  This helped me get the syntax needed to delete all the bogus address leases and get it down from almost 400 leases to the valid 125 leases.  I can finally get the scope range back to what it should be.


    John

    Friday, May 19, 2017 5:01 PM
  • I have this exact same issue. It came from nowhere. I used the PS command to remove the leases but what did you do to find the bad switch port?!
    Monday, June 18, 2018 6:07 PM
  • Simply a matter of trial and error.   This was a large, multi-building site, so we had to move around closet to closet in the buildings, kill the uplink on a switch, see if the problem persisted, and work through everything until the problem went away after one was unplugged.  Then it was a matter of the tech unplugging one plug at a time there to see what made the problem go away, and what made it return.  Not all the switches were managed switches and the ones that were showed nothing abnormal.

    John

    Monday, June 18, 2018 6:52 PM