2

None of the Nagios DHCP check plugins can actually take an IP from the DHCP server as a real test. All they do is ask which IP it would give to a certain mac address.

Our DHCP server failed, where Nagios didn't alert, because it could pass the Nagios test, but not actually give the IP to clients.

Question

Is there a way for a script request an IP and have the DHCP server deliver it? The script would run every 5 minutes, so it would throw away the IP at every run.

Update

Ideally what the script should do is

# dhclient -r ; dhclient ; ip a|grep valid_lft
Killed old client process
       valid_lft forever preferred_lft forever
       valid_lft forever preferred_lft forever
       valid_lft 86459sec preferred_lft 86459sec
       valid_lft forever preferred_lft forever

and if preferred_lft isn't renewed, then alert.

The problem which this method is requires a dedicated NIC for for this. So it would be really good, if this could be simulated somehow?

Louise Hoffman
  • 476
  • 2
  • 6
  • 12
  • 1
    Please look here: https://serverfault.com/questions/171744/command-line-program-to-test-dhcp-service – mariaczi Mar 07 '18 at 11:56

1 Answers1

2

In order to test what would happen if a completely new device request your DHCP server for an IP address your Nagios script would need to send DHCP Discover packets with spoofed MAC addresses. You would need to be able to send raw DHCP packets, but before even trying that you should revise what this arrangement would actually require.

Let's assume we have a DHCP lease time of 24 hours. If you send a DHCP Discover packet with a new MAC address every 5 minutes and get an DHCP offer from the pool, your Nagios test alone will occupy 288 IP addresses from your pool. If your lease time is even longer, for example a week, you will have up to 2016 dummy reserver IP addresses. You would need to have a /20 DHCP pool in order to have this amount of spare addresses + space for the actual devices.

That's why I suggest using the regular test and rely on that for over 99,9% of the cases. The rare condition of pool exhaustion every now and then is worth taking care manually instead of actually causing the situation while testing it.

Secondary approach. Do not test by sending additional DHCP Discover packets, but instead monitor the actual traffic. Create an alert whenever you see:

  • a DHCP Discovery packet without a corresponding DHCP Offer packet.
  • a DHCP Request packet without a corresponding DHCP Ack packet.

You should be able to recognize any problems pretty fast.

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122