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
