Socket error: TCP_MD5SIG: Cannot allocate memory

[Stefan Jakob]

Ondrej Zajicek <santiago at crfreenet.org> schrieb am Di., 25. Aug. 2015 23:11:

On Tue, Aug 25, 2015 at 03:45:47PM -0500, Michael Vallaly wrote:
>
> For context on my end; this issue was experienced on physical hardware
> (64bit) with Intel 1Gbit NICs (no offloading).
>
> We only noticed this after some length of time, (> 180 days) during
> which we likely had < 40 BGP session flaps on our end via Bird.
>
> optmem_max: Maximum ancillary buffer size allowed per socket. Ancillary
> data is a sequence of struct cmsghdr structures with appended data. The
> default size is 10240 bytes.
>
> According to Eric Dumazet back in 2012 [1]:
>
> <snip>
> There is no limit on number of MD5 keys an application can attach to a
> tcp socket.
>
> This patch adds a per tcp socket limit based
> on /proc/sys/net/core/optmem_max
>
> With current default optmem_max values, this allows about 150 keys on
> 64bit arches, and 88 keys on 32bit arches.
> </snip>
>
> Maybe we are getting multiple/duplicate MD5 keys assigned to the TCP
> session somehow?

Thanks for the info about the limit.

Note that the incoming (listening) TCP socket (AFAIK) has to be
configured with all the keys, so it is possible to hit the limit
during regular operation without any leaks.



Do I get it right?:

Without adjusting the optmem_max value you won't be able to attach more
than a 150 keys to a listening socket?

Would this basically cause trouble when you want to run f.e. a bgp
routeserver with more than 150 peers protecting there sessiibs via a unique
key?

Rgds, SJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20151118/8accf616/attachment.html>