Ondrej Zajicek <santiago@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