You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
while deploying charrua in africa with no persistent leases, we discovered that a restart of charrua leads to it handing out ip addresses with active lease (from the previous incarnation). -- see also https://tools.ietf.org/html/rfc5227
ways to fix this include:
ask via arp before handing out an ip address
randomise (instead of linear search) which ip to hand out
IMHO we should do both.
The text was updated successfully, but these errors were encountered:
Pinging is not feasible, that would cause a state explosion. Would have to somehow tell the caller to ping it, check if it's ok and then install the lease. Can be done without touching the library.
The addresses are not given based on a linear search. A ridiculously naive hashing of the mac address is made, the rationale for this was to try to always give the same address to the same clients. But as we can see, that's kinda fucked up since we don't keep state.
Randomizing and, in case of collision, doing a linear search should be enough.
The client might fail one or two times but it would recover, the sad part is that clients would tend to grab different addresses every time they lose a lease and request a new one.
(sarcasm
"SEE SEE SEE YOU HIPSTERS WANT TO DO STATELESS THINGS !
THIS IS WHAT HAPPENS WHEN YOU HIPSTERIZE AN 80S PROTOCOL !")
while deploying charrua in africa with no persistent leases, we discovered that a restart of charrua leads to it handing out ip addresses with active lease (from the previous incarnation). -- see also https://tools.ietf.org/html/rfc5227
ways to fix this include:
IMHO we should do both.
The text was updated successfully, but these errors were encountered: