<p dir="ltr"><br>
</p>
<p dir="ltr"></p>
<p dir="ltr">Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>> schrieb am Di., 25. Aug. 2015 23:11:</p>
<blockquote><p dir="ltr">On Tue, Aug 25, 2015 at 03:45:47PM -0500, Michael Vallaly wrote:<br>
><br>
> For context on my end; this issue was experienced on physical hardware<br>
> (64bit) with Intel 1Gbit NICs (no offloading).<br>
><br>
> We only noticed this after some length of time, (> 180 days) during<br>
> which we likely had < 40 BGP session flaps on our end via Bird.<br>
><br>
> optmem_max: Maximum ancillary buffer size allowed per socket. Ancillary<br>
> data is a sequence of struct cmsghdr structures with appended data. The<br>
> default size is 10240 bytes.<br>
><br>
> According to Eric Dumazet back in 2012 [1]:<br>
><br>
> <snip><br>
> There is no limit on number of MD5 keys an application can attach to a<br>
> tcp socket.<br>
><br>
> This patch adds a per tcp socket limit based<br>
> on /proc/sys/net/core/optmem_max<br>
><br>
> With current default optmem_max values, this allows about 150 keys on<br>
> 64bit arches, and 88 keys on 32bit arches.<br>
> </snip><br>
><br>
> Maybe we are getting multiple/duplicate MD5 keys assigned to the TCP<br>
> session somehow?</p>
<p dir="ltr">Thanks for the info about the limit.</p>
<p dir="ltr">Note that the incoming (listening) TCP socket (AFAIK) has to be<br>
configured with all the keys, so it is possible to hit the limit<br>
during regular operation without any leaks.</p>
</blockquote>
<blockquote><p dir="ltr"><br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>
<p dir="ltr">Do I get it right?:</p>
<p dir="ltr">Without adjusting the optmem_max value you won't be able to attach more than a 150 keys to a listening socket?</p>
<p dir="ltr">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?</p>
<p dir="ltr">Rgds, SJ</p>