From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willy Tarreau Subject: Re: [PATCH] net: bridge: add max_fdb_count Date: Thu, 16 Nov 2017 10:58:46 +0100 Message-ID: <20171116095846.GB14616@1wt.eu> References: <1510774027-2468-1-git-send-email-srn@prgmr.com> <4f31ae8b-352e-d2ab-cd71-4b31f76e666a@cumulusnetworks.com> <4d756a43-e51d-c52d-7b4b-fce61f021a66@prgmr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nikolay Aleksandrov , netdev@vger.kernel.org, roopa To: Sarah Newman Return-path: Received: from wtarreau.pck.nerim.net ([62.212.114.60]:36080 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750814AbdKPJ6w (ORCPT ); Thu, 16 Nov 2017 04:58:52 -0500 Content-Disposition: inline In-Reply-To: <4d756a43-e51d-c52d-7b4b-fce61f021a66@prgmr.com> Sender: netdev-owner@vger.kernel.org List-ID: Hi Sarah, On Thu, Nov 16, 2017 at 01:20:18AM -0800, Sarah Newman wrote: > I note that anyone who would run up against a too-low limit on the maximum > number of fdb entries would also be savvy enough to fix it in a matter of > minutes. I disagree on this point. There's a huge difference between experiencing sudden breakage under normal conditions due to arbitrary limits being set and being down because of an attack. While the latter is not desirable, it's much more easily accepted and most often requires operations anyway. The former is never an option. And I continue to think that the default behaviour once the limit is reached must not be to prevent new entries from being learned but to purge older ones. At least it preserves normal operations. But given the high CPU impact you reported for a very low load, definitely something needs to be done. > They could also default the limit to U32_MAX in their particular > distribution if it was a configuration option. Well, I'd say that we don't have a default limit on the socket number either and that it happens to be the expected behaviour. It's almost impossible to find a suitable limit for everyone. People dealing with regular loads never read docs and get caught. People working in hostile environments are always more careful and will ensure that their limits are properly set. > At the moment there is not even a single log message if the problem doesn't > result in memory exhaustion. This probably needs to be addressed as well! Regards, Willy