netdev - Re: [PATCH] net: bridge: add max_fdb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171116162718.3c252ff1@xeon-e3>
Date:   Thu, 16 Nov 2017 16:27:18 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Vincent Bernat <bernat@...fy.cx>
Cc:     Andrew Lunn <andrew@...n.ch>, Sarah Newman <srn@...mr.com>,
        Willy Tarreau <w@....eu>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        netdev@...r.kernel.org, roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH] net: bridge: add max_fdb_count

On Thu, 16 Nov 2017 21:21:55 +0100
Vincent Bernat <bernat@...fy.cx> wrote:

>  ❦ 16 novembre 2017 20:23 +0100, Andrew Lunn <andrew@...n.ch> :
> 
> > struct net_bridge_fdb_entry is 40 bytes.
> >
> > My WiFi access point which is also a 5 port bridge, currently has 97MB
> > free RAM. That is space for about 2.5M FDB entries. So even Roopa's
> > 128K is not really a problem, in terms of memory.  
> 
> I am also interested in Sarah's patch because we can now have bridge
> with many ports through VXLAN. The FDB can be replicated to an external
> daemon with BGP and the cost of each additional MAC address is therefore
> higher than just a few bytes. It seems simpler to implement a limiting
> policy early (at the port or bridge level).
> 
> Also, this is a pretty standard limit to have for a bridge (switchport
> port-security maximum on Cisco, set interface X mac-limit on
> Juniper). And it's not something easy to do with ebtables.

I want an optional limit per port, it makes a lot of sense.
If for no other reason that huge hash tables are a performance problems.

There is a bigger question about which fdb to evict but just dropping the
new one seems to be easiest and as good as any other solution.