From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolay Aleksandrov Subject: Re: [PATCH] net: bridge: add max_fdb_count Date: Thu, 16 Nov 2017 21:36:20 +0200 Message-ID: <9125CC0D-4B56-4797-8416-DA70DEF2914F@cumulusnetworks.com> References: <1510774027-2468-1-git-send-email-srn@prgmr.com> <4f31ae8b-352e-d2ab-cd71-4b31f76e666a@cumulusnetworks.com> <4d756a43-e51d-c52d-7b4b-fce61f021a66@prgmr.com> <20171116095846.GB14616@1wt.eu> <3d08c77f-8d71-e302-d3f7-24acc6df9414@prgmr.com> <20171116192325.GA16122@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Willy Tarreau , netdev@vger.kernel.org, roopa To: Andrew Lunn , Sarah Newman Return-path: Received: from mail-wm0-f52.google.com ([74.125.82.52]:36617 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933803AbdKPTgY (ORCPT ); Thu, 16 Nov 2017 14:36:24 -0500 Received: by mail-wm0-f52.google.com with SMTP id r68so2401181wmr.1 for ; Thu, 16 Nov 2017 11:36:24 -0800 (PST) In-Reply-To: <20171116192325.GA16122@lunn.ch> Sender: netdev-owner@vger.kernel.org List-ID: On 16 November 2017 21:23:25 EET, Andrew Lunn wrote: >> Linux bridges can also be used in small embedded devices=2E With no >limit, >> the likely result from those devices being attacked is the device >gets >> thrown away for being unreliable=2E > >Hi Sarah > >Just to get a gut feeling=2E=2E=2E > >struct net_bridge_fdb_entry is 40 bytes=2E > >My WiFi access point which is also a 5 port bridge, currently has 97MB >free RAM=2E That is space for about 2=2E5M FDB entries=2E So even Roopa's >128K is not really a problem, in terms of memory=2E > >> Maybe what's needed is two thresholds, one for warning and one for >enforcement=2E >> The warning limit would need to be low enough that the information >had a good chance >> of being logged before the system was under too much load to be able >to convey >> that information=2E The enforcement limit could be left as default >inactive until >> shown that it needed to be otherwise=2E > >What exactly is the problem here? Does the DoS exhaust memory, or does >the hashing algorithm not scale? Just a note - when net-next opens I'll send patches which move the fdb to a resizeable hashtable that scales nicely even with = hundreds of thousands of entries so only the memory issue will remain=2E > >It is more work, but the table could be more closely tied to the >memory management code=2E When memory is getting low, callbacks are made >asking to free up memory=2E Register such a callback and throw away part >of the table when memory is getting low=2E There is then no need to >limit the size, but print a rate limited warning when asked to reduce >the size=2E > > Andrew --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E