[Kea-users] IP address conflict handling

[Klaus Steden]

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 <tomasz at isc.org> 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
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20170208/ddb8da42/attachment.htm>