<div dir="ltr"><br><div>Hi Tomek,</div><div><br></div><div>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.)</div><div><br></div><div>cheers,</div><div>Klaus</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 8:43 AM, Tomek Mrugalski <span dir="ltr"><<a href="mailto:tomasz@isc.org" target="_blank">tomasz@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">W dniu 08.02.2017 o 00:20, Klaus Steden pisze:<br>
<span class="">><br>
> Hi there,<br>
><br>
> I realize I don't know what the expected behaviour is for Kea when<br>
> dealing with an IP conflict, e.g., an address has been assigned by "not<br>
> Kea", but it's within one of Kea's defined scopes.<br>
><br>
> Does Kea have any internal mechanisms to check if an address is already<br>
> in use?<br>
</span>You haven't mentioned whether you're asking about v4 or v6. The answers<br>
are slightly different for both. RFC2131 says that the server should<br>
send ICMP echo request to the address that is about to be assigned and<br>
assign it to the client only if there's no reply. That mechanism is not<br>
implemented in Kea. The reason for this is that ping check was a nice<br>
feature back in the days when clients could wait extra second or two and<br>
there was no rush. Nowadays the server is often expected to grant 1000s<br>
of leases per second, so the delays introduced by ping checks are out of<br>
question, especially that the likelihood of detection is very small.<br>
<br>
Fortunately, both DHCPv4 and DHCPv6 protocols have a safe guard<br>
mechanism for duplicates. If a client detects that the address assigned<br>
is already used, it can report this back to the server using DECLINE<br>
message. This is supported by Kea. By default Kea then will mark the<br>
address as used by unknown entity, log a warning about it and will start<br>
a timer. The default for that is 24 hours, but can be configured to<br>
other values. After that time the address is returned back to the pool<br>
of available addresses. This recovery mechanism is implemented this way<br>
to automatically recover without any manual intervention. If the 24h<br>
time elapses and the address is still hijacked, Kea will get another<br>
DECLINE message and put it back in the probation period.<br>
<br>
For details, see Sections 7.6 and 8.10 of Kea User's Guide:<br>
<a href="https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-decline" rel="noreferrer" target="_blank">https://jenkins.isc.org/job/<wbr>Kea_doc/guide/kea-guide.html#<wbr>dhcp4-decline</a><br>
<br>
Tomek Mrugalski<br>
ISC<br>
<br>
______________________________<wbr>_________________<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/kea-users</a><br>
</blockquote></div><br></div>