I placed a feature request in for mikrotik update the DHCP server to look at the agent circuit and remote id for leases. essentially, if a new lease is requested, look in the leases list and see if one or both of those fields match and then replace the old lease while keeping the old IP.
Many people use radius servers to handle this but that is complex and requries a software stack in addition to the option 82 support. having the mikrotik DHCP server be able to handle this directly would radically simplify many setups. Simply set a customer with a sticky DHCP address when you install with option 82 features on their last mile connection, and never have to worry about them changing devices.
Also, it would be incredibly helpful if we could get option-82 support for DHCP leases processed by RADIUS. IE, look at the option-82 field from the DHCP packet and then use that for the RADIUS username instead of the CHADDR field.
also note that this shouldn’t break anything for devices that don’t support option 82, they just wouldn’t have those fields.
Most of the new gear I’m deploying that is ‘bridge only’ supports option 82 well. I still run some ubiquiti gear that either doesn’t support it at all, or is flakey, but I have other solutions for those.
That’s why I’ve asked people to come here and upvote if they want it. Mikrotik isn’t stuck behind cisco or juniper for features, they’ve implemented lots of things those vendors dont.
DHCP server lease scripts receive all necessary information (including the DHCP options sent by the client) to do such things as pseudo global variables.
The problem is the script is called after the lease is created and the offer is sent to the client.
A more flexible way to would be a script hook which is called if an DHCP request is received, but before the lease is created/renewed and an offer is sent.
This would allow for uses cases as the one you described and also everything else that can be done with scripting.
The scripts do NOT receive any of the agent id information, the list of variables is very short. And indeed they are called after the lease is created.
At least you can use the framed-ip-address variable to identify the recently granted lease for scripting purposes but you really have to rely on a short lease so the client will request again after your script has run and updated static leases.
I’ve actually requested the agent information be added as variables and that they be processed before the lease is sent to the client for the same purposes but that was not interesting because I was the only person to have requested it.
This request is generic enough to have wide appeal in my opinion. This is a problem many many wisps are up against.
The scripts do NOT receive any of the agent id information
I never tried using DHCP options in lease scripts so far, but my understanding of the documentation
“lease-options - array of received options”
always was lease-options provides an array of DHCP options sent by the client and would also contain option 82 (if sent by the client or inserted by a relay agent).
Hello, I found this post because that's exactly what I need, and then I saw the changelogs for version 7.21.
So I want to inform you that this feature is now implemented.
dhcpv4-server - added setting allowing to select client-id, MAC address and opt82 parameters for dynamic lease addition;
yes, and this is tested and working for us. If you put an all zero’s mac address in and the option82 data it allows for customers to swap routers cleanly.