Hi Tomek, Thanks! That was a terrific explanation. Where does Kea store the record for the "hijacked" address? Does it live in the existing lease table, or somewhere else (we're using MySQL as the backend, so I don't know if it will be visible in the DB, or if it gets stored locally in another lease-file-like file.)
cheers, Klaus On Wed, Feb 8, 2017 at 8:43 AM, Tomek Mrugalski <[email protected]> wrote: > W dniu 08.02.2017 o 00:20, Klaus Steden pisze: > > > > Hi there, > > > > I realize I don't know what the expected behaviour is for Kea when > > dealing with an IP conflict, e.g., an address has been assigned by "not > > Kea", but it's within one of Kea's defined scopes. > > > > Does Kea have any internal mechanisms to check if an address is already > > in use? > You haven't mentioned whether you're asking about v4 or v6. The answers > are slightly different for both. RFC2131 says that the server should > send ICMP echo request to the address that is about to be assigned and > assign it to the client only if there's no reply. That mechanism is not > implemented in Kea. The reason for this is that ping check was a nice > feature back in the days when clients could wait extra second or two and > there was no rush. Nowadays the server is often expected to grant 1000s > of leases per second, so the delays introduced by ping checks are out of > question, especially that the likelihood of detection is very small. > > Fortunately, both DHCPv4 and DHCPv6 protocols have a safe guard > mechanism for duplicates. If a client detects that the address assigned > is already used, it can report this back to the server using DECLINE > message. This is supported by Kea. By default Kea then will mark the > address as used by unknown entity, log a warning about it and will start > a timer. The default for that is 24 hours, but can be configured to > other values. After that time the address is returned back to the pool > of available addresses. This recovery mechanism is implemented this way > to automatically recover without any manual intervention. If the 24h > time elapses and the address is still hijacked, Kea will get another > DECLINE message and put it back in the probation period. > > For details, see Sections 7.6 and 8.10 of Kea User's Guide: > https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-decline > > Tomek Mrugalski > ISC > > _______________________________________________ > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users >
_______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
