I have the following situation:
My ISP gives me a /29 public routed subnet with no DHCP server.
This gives me 5 usable public IP adresses, but they must be set as static in every device i connect, and for a lab environment i want to setup, i want a DHCP server to assign these IP’s to a device, based on which port i plug the device into.
I intend to use a Mikrotik HeX PoE for this, because that is what i have laying around.
So far, not too difficult, just setup 5 pools with just 1 address, and assign each pool to its own interface in the DHCP Server.
But here is the thing, if i disconnect a device before it sends a DHCP release to the router, the lease will remain active, and the next device i plug into that port will not get an IP address, it will only get one after i manually delete the lease by logging into the mikrotik, or wait for the lease time to run out.
and since i don’t want to reduce lease time to a minute or something, i thought a script that deletes the lease for me would be the solution.
Is there a way to trigger / activate this script when a specific interface goes down? (as in, when i pull the plug?)
Something like a watchdog/netwatch doesn’t seem usable because it uses pings, and not every device i connect will respond to those pings.
Sadly there is no functionality to hook into interface events.
You could run a script via scheduler that checks link status for the ports in very short interval.
Hello !
Is there any news about this topic ?
How can we ask for this feature?
I think it would be a good thing for CPU usage to have the interface itself triggering a script instead of schedule a script every 10 seconds that check interface state.
Well, the OP request was some 5 years ago by now he will have found a solution or learned to live with the issue happily.
The thread was revived re-stating the question in much more general terms, and Josephny’s suggestion does cover one of the possible events that can happen on an interface.
If you prefer the apodictic statement by erlinden:
Sadly there is no functionality to hook into interface events.
can be “mitigated” by adding to it something like: but at least for events that create or can be made creating a distinguishable entry in log, it is possible to trigger an action.
Honestly, it doesn’t seem to me to be very far from the on-state-change / on-up / on-down requirement.
It is more logical and creates less regressions to monitor interface state/properties changes,
rather than relying on logs, which are both optional and modifiable.
Also because being notified by email is not the same as activating a script,
it still needs to be done and launched…
