How many times do we as network engineers get frustrated when one of our DHCP scope ranges gets dangerously close to running out of available lease addresses, or worse yet, actually runs out of available DHCP addresses, and we start getting calls from the helpdesk asking why people can no longer connect to the network?
Unfortunately, this situation has happened to most of us (perhaps because the prior network engineer didn’t anticipate future growth on the network, or he/she just incorrectly undersized the network ranges/scope at the time they set things up). Typically, when these situations occur, we are awaiting a properly scheduled change-window where we can expand the DHCP scope address range accordingly. But, as many of us will attest, this isn’t always a simple task, especially for already established network infrastructures. Finding time to manually adjust the IP addresses, subnet masks, gateway addresses, etc. on all those statically assigned devices/nodes in the environment can be extremely time-consuming and often has to be done on the weekends or off-hours. As a result, projects like expanding your subnets to allow for the inclusion of more host addresses can often be pushed off until they become critical or until there’s an opportunity to make the changes without severely impacting the network.
One of our engineers, Matt Granzow, recently found a neat way with PRTG monitoring software to report on the number of DHCP addresses still available for lease in an organization’s DHCP scope. This information can be used for graphing, trending, and email alert notification purposes as necessary.
Here’s an example of what we can set up in PRTG when this is properly configured:
Looking at the above screenshot, we can view the available DHCP leases for each of the (5) DHCP scopes we have in use at that site. Furthermore, we can also set up email alerts to be sent via PRTG whenever a particular value falls below a certain threshold (for example, less than 25 leases being currently available) so we are notified of a potential problem before a problem actually occurs (this is easily done using PRTG “notifications” feature. With PRTG, we also get graphing and long-term historical data to reference as well to determine trending patterns, etc.
Monitoring DHCP leases
Setting this up is pretty simple if you already have PRTG installed.
Here are the steps to monitor the DHCP scopes on a Windows 2012 R2 server:
- Make sure your Windows server has the SNMP service enabled along with the proper SNMP community string necessary.
- For the server you’re monitoring in PRTG, right-click on that device and select Add Sensor.
- Select the “SNMP Custom” sensor option.
- Provide a sensor name such as “DHCP Leases available for 10.12.32.0/0”
- Enter an OID value of 220.127.116.11.4.1.318.104.22.168.22.214.171.124.12.32.0 (the last 4 octets being your Network ID)
- Click on the Continue button
That’s pretty much all that is needed to monitor the DHCP scopes in PRTG, simple as that!
You can also use SNMPWALK as a tool to figure out what OIDs to use for this, as well as other cool things. SNMPWALK can be downloaded here: http://www.snmpsoft.com/freetools/snmpwalk.html. You can use it in the following way, as an example, or any variation to provide you with the information you need:
.SnmpWalk.exe -r:host-c:community -os:126.96.36.199.4.1.3188.8.131.52.1.1.3 -op:184.108.40.206.4.1.3220.127.116.11.1.1.4
Please note that if you may have some trouble running SNMPWALK if the Windows Firewall is enabled on the machine you’re running the tool against. In that case, you can either open up the Windows Firewall appropriately, or you can also use the –r:127.0.0.1 to get the information you need, provided you’re running the tool against the local host machine and not a machine elsewhere on the network.
Please note the following issue on Windows 2012 R2 servers: The SNMP service seems a bit buggy See here. If you cannot read the proper OID values using SNMPWALK, you -may- have to uninstall the SNMP service, reboot, and reinstall the SNMP service (which requires you to reset your community strings, restart the service, etc.).
Hopefully, this provides some useful information! In the next blog, we’re going to show you how to monitor Windows Server Backup success/failures using PRTG and a custom Powershell script. Very handy when you have countless individual machines (at remote branches for example) that use Windows Server Backup and need a quick and easy way to determine whether the backups are running successfully or not, without having to remotely login to each individual server to check the status.