[Kea-users] [kea-dev] Raw socket input buffer

[Tomek Mrugalski]

W dniu 31.07.2017 o 12:36, Francis Dupont pisze:
> kea at jack.fr.eu.org writes:
>> I have a kea4 server, version 1.1.0, I added hooks that connect
>> externally (the important information : that hook is "slow", it does TCP
>> connect)
>> That part works well
>>
>> However, when the server takes too many queries (I don't know how "too
>> many" is), a strange behavior appears: the server keep and answer
>> outdated requests (some kind of input buffer, I guess), which clients
>> timed-out in the mean time, leading to another requests etc -> broadcast
>> storm and global failure
> 
> => as your tentative fix suggested this is a kernel issue: pending
> queries are simply queued waiting Kea to read them. IMHO the best is
> to add some code in the slow hook to flush them.
> 
>> I tried to reduce /proc/sys/net/core/rmem_max to 4096, this does not fix
>> the issue (probably because 4096 is still a lot of dhcp-packets :p)
According to man 7 socket, the minimum value you can set there is 256.
This is a doubled value (see the man page for explanation), which in
principle could allow you to buffer up to 128 bytes. This is definitely
in range of a single DHCP packet. Obviously, nobody recommends setting
it to such a low value. But if you want to drop packets while previous
packet is being processed, this is one thing to possibly try.

>> Any tip, trick, configuration or whatever on that issue ?
> 
> => slow processing is incompatible with the DHCP protocol so basically
> there is no final fix, only tricks to make things less broken.
Yes. One day we will have to extend the hooks mechanism to make it
asynchronous. This is still a bit far away, because this most likely
means Kea will need to be multi-threaded or at least multi-process. Both
are non-trivial.

But before we fully embrace that, we could look whether there's a way to
get the timestamp from kernel regarding when the packet was received. If
there's a way to do that, we could reject packets that spent too much
time in a buffer and are now stale. This shouldn't be super complex to
implement, but sadly our schedule for upcoming 1.3 is pretty tight.

But as Francis said, this would be another trick. The ultimate solution
would be to implement async hooks.

Tomek