I'm wondering what the behavior of 'static' is supposed to do.
I'd like it to replace a static lease on match, for instance using it as an option82 solution, client changes their router I'd like the static lease assigned to their option82 data to update with the new client mac etc.
my testing shows that this doesn't work. if the MAC address changes, it just doesn't work against a static lease. Not sure how this is supposed to work.
DHCP Option 82 is used by DHCP relay (called DHCP Relay Agent Option) and contains metadata added by relay to DHCP lease request being forwarded towards DHCP server.
So do you use DHCP relay(s) in your network? If not, then Option 82 is useless.
You may want to explain the issue you want to fix and you may get a suggestion or two.
I'm using the option 82 injection on various mikrotik switches (np16, 7r, etc) as well as on various radios. I then set relay=255.255.255.255 on my mikrotik DHCP server so that it will accept the option82 data and populate the fields. I have to do this because some radios (ui...) relay the dhcp request to the mikrotik. an np16 or 7r don't do this so I don't need the relay=255.255.255.255 but I don't think this is pertinent to the 'static' option matcher request, just saying it to give a more complete picture.
this works greats. however, in order to use option matcher, I have to add an IP pool for each 'sticky' IP address and then assign that to a matcher entry with the 'substring' including the agent-remote-id or agent-circuit-id.
I had hoped that 'static' would allow me to avoid adding the pool. however, this doesn't appear to work. lets say a customer has a router with mac aa:bb:cc:dd:ee:ff and I set a static lease there and 'static' for option matcher with the customers circuit-id from opt82. Then the customer swaps their router and new mac is ff:ee:dd:cc:bb:aa. The sticky lease and the option matcher don't get along, the new device cannot get the IP address, the static lease effectively blocks it and the option matcher doesn't update the sticky lease for the new mac address.
in the same scenario but with an IP pool containing a single address and leaving the lease as dynamic it DOES work. The new ff:: mac address takes over that dynamic lease.
the purpose here is a radius-free option82 solution with no external services. This is working right now perfectly w/o 'static' but I'd like to simplify further.
Does this mean the same can be achieved without a complex setup like this:
Can you please post the relevant config lines?
I don't think that one can set up DHCP server without any pool for addresses what so ever. But OTOH one can set static leases which are part of the pool and there won't be any problem with it (static leases will be part of same leases list, consulted by DHCP server when determining which address to offer to client, they only won't ever expire).
And the main metadata, definining DHCP client, is either DHCP client ID (if client provides this information, they mostly do) or client MAC address. Option 82 metadata are not defining client, they are there to aide DHCP server when selecting an appropriate address (e.g. if you have multiple LAN subnets with corresponding DHCP relays running). And AFAIK for the most metadata one has to construct a DHCP lease script to appropriately evaluate those metadata, ROS's DHCP server doesn't do it all by itself.
Or use a full-featured DHCP server like @damadmai suggested.
But the default value of the address-pool field is static-only and you can create DHCP server instances with that without problem.
Right, and so you have to think the 'static' means something, but I dont' know what.
from the help page
"Clients with a static lease will continue to receive their static address, even when matched by the option matcher."
and
" IP pool, from which to take IP addresses for the clients. If set to static-only , then only clients that have a static lease (added in the lease submenu) will be allowed."
however, this doesn't seem to do anything because if you create a static lease, it trumps the option matcher and the option matcher doesn't update the static lease.
You can now specify Option 82 parameters in static leases