Detecting Lease Exhaustion and Freeing Up an Address

Solved
Jason-907
Getting noticed

Detecting Lease Exhaustion and Freeing Up an Address

Background: For reasons outside of my control, management has decided that we should reserve the entire subnet at a few of our remote sites and use reserved/fixed DHCP addresses. (I'm pushing for 802.1x to replace this, but we aren't there yet.) Meraki, in their infinite wisdom, decided that when a DHCP scope has exhausted all its leases it should send you alert every single time the PC attempts to grab an IP. Due to recent increases in business in this area, we have a several people traveling to one of these location location. Even though they should be just fine on the wireless network, they seem to always plug into the wired LAN resulting in dozens of alerts before we can create a new lease.

Proposed solution: I want to create a script that will check the log for DHCP exhaustion, grab the MAC, see if it is a known client, and create a reservation if it is a known client. I also need to clean out reservations that are no longer in use.

Issues: 

  1. The API doesn't appear to have a hook into log files. Any ideas on how to work around this? Perhaps I need a syslog server, but that seems like overkill.
  2. I haven't seen how one goes about deleting a DHCP reservation. The JSON data appears to key off of the MAC rather than the IP address. How do I delete an old reservation? I'm assuming if I create a new reservation with a unique MAC and an IP already in use, I'm going to get an error. 
1 Accepted Solution
Jason-907
Getting noticed

Thanks for all the help! Here's what I came up with. 

 

myvlans = meraki.getvlans(apikey, networkid, suppressprint=False)
vlanid = 100
myipassignments = {newmac: {'ip': myip, 'name': name}}
for vlan in myvlans:
if vlan['id'] == vlanid:
vlan['fixedIpAssignments'].pop(oldmac)
vlan['fixedIpAssignments'][newmac] ={'name': name, 'ip': myip}
meraki.updatevlan(apikey, networkid, vlanid, name=None, subnet=None, mxip=None, fixedipassignments=vlan['fixedIpAssignments'], reservedipranges=None, vpnnatsubnet=None, dnsnameservers=None, suppressprint=False)

It works great, but while I was testing I noticed a slight quirk. I was swapping old mac and new mac back and forth, but changing the name so I could be sure things were changing, but the UpdateVLAN function doesn't change the name. It will set the name if it's a new MAC, but if you are recycling a MAC it will retain the name it had originally. You have to use the dashboard to actually change the name. Shouldn't *really* be an issue, but it could be a quirk if you are trying to write a script that adds more description to reservation names. (I like to use CompName-Username, but previous admins didn't follow this method, so I wouldn't be able to write a script to normalize this naming scheme.) Also, it seems like sometimes it will change the name and other times it won't...can't really figure out what the reason is behind it.

View solution in original post

7 Replies 7
Nash
Kind of a big deal

Honestly, is there a reason why you haven't shortened your DHCP lease time? What's it set to right now?

 

Otherwise, I think I have bad news for you.

 

With regards to deleting DHCP leases: We cannot easily delete leases. 

 

You can wipe out all current DHCP leases by either rebooting the firewall, or creating a DHCP reservation for the entire VLAN, waiting for the config to apply, then removing that reservation. (Hat tip to @AlexC)

 

Haven't tested, but you might be able to clear out problem leases by using Update a VLAN to add that IP as a reservation. Wait, then remove that IP as a reservation. You'd have to make sure you replicated the entirety of your VLAN's settings tho, otherwise it's gonna mess things up.

Jason-907
Getting noticed

The lease time isn't the problem. It's a manager who doesn't want contractor machines to get onto our network. So, if they "accidently" plug into our workstation VLAN instead of their contractor VLAN, he doesn't want them to get an IP address...so they realize they are plugged into the wrong port. (Mind you, in the three years that we've had this location, the contractor has *NEVER* been the one causing the problem.) My manager's solution was to exclude all the IPs from DHCP and setup reservations for every device on the LAN.

 

We actually do have some open IP addresses. The problem is, it won't take long to fill up what we have, so I need to be able to remove the reservation.

This whole issue would go away if we could implement 802.1x. Then if the machine were allowed to be on our network, it would get the workstation VLAN and if it wasn't it would get the contractor VLAN. We just aren't ready to pull the trigger on that right now and I was hoping I could set something up with the API to automate what we are doing manually until we can implement the proper solution. 

 

Thanks, @Nash. I wonder if @AlexC knows how to remove a reservation via the API.

AlexC
Meraki Employee
Meraki Employee

@Jason-907, there is actually an API endpoint for this.

https://developer.cisco.com/meraki/api/#/rest/api-endpoints/vlans/update-network-vlan

You can modify the body of that API call to update your DHCP configuration on the VLAN accordingly (you can see example and test it out in the console yourself on that page)

If this was helpful, click the Kudos button below.
Please mark it as a solution if solved your issue so others can benefit from it 🙂
Jason-907
Getting noticed

@AlexC , thanks so much for replying. That API is what I was looking at using. I was just trying to figure out is how to remove a reservation. Say I have 22:33:44:55:66:77 assigned to 10.12.1.50, but now I want to remove that reservation or change things so 00:11:22:AA:DD:FF assigned to 10.12.1.50? I don't see a way to do this, but I admit that I'm a python novice. 

 

Would I do something like this?

  "fixedIpAssignments": {
    "22:33:44:55:66:77": {
      "ip": "",
      "name": ""
    }
  },
"fixedIpAssignments": { "00:11:22:AA:DD:FF": { "ip": "10.12.1.50", "name": "Some client name" } },

Thanks,

Jason

PhilipDAth
Kind of a big deal
Kind of a big deal

You could also consider using a Webhook.  This would allow your code to be called when a DHCP exhaustion event occurrs.

https://documentation.meraki.com/zGeneral_Administration/Other_Topics/Webhooks

Jason-907
Getting noticed

Oh, this looks very interesting--thanks! I'll start investigating next week when I get back to the office.

Jason-907
Getting noticed

Thanks for all the help! Here's what I came up with. 

 

myvlans = meraki.getvlans(apikey, networkid, suppressprint=False)
vlanid = 100
myipassignments = {newmac: {'ip': myip, 'name': name}}
for vlan in myvlans:
if vlan['id'] == vlanid:
vlan['fixedIpAssignments'].pop(oldmac)
vlan['fixedIpAssignments'][newmac] ={'name': name, 'ip': myip}
meraki.updatevlan(apikey, networkid, vlanid, name=None, subnet=None, mxip=None, fixedipassignments=vlan['fixedIpAssignments'], reservedipranges=None, vpnnatsubnet=None, dnsnameservers=None, suppressprint=False)

It works great, but while I was testing I noticed a slight quirk. I was swapping old mac and new mac back and forth, but changing the name so I could be sure things were changing, but the UpdateVLAN function doesn't change the name. It will set the name if it's a new MAC, but if you are recycling a MAC it will retain the name it had originally. You have to use the dashboard to actually change the name. Shouldn't *really* be an issue, but it could be a quirk if you are trying to write a script that adds more description to reservation names. (I like to use CompName-Username, but previous admins didn't follow this method, so I wouldn't be able to write a script to normalize this naming scheme.) Also, it seems like sometimes it will change the name and other times it won't...can't really figure out what the reason is behind it.

Get notified when there are additional replies to this discussion.