netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Sarah Newman <srn@prgmr.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] net: bridge: add max_fdb_count
Date: Wed, 15 Nov 2017 12:04:52 -0800	[thread overview]
Message-ID: <20171115120452.3b426442@xeon-e3> (raw)
In-Reply-To: <1510774027-2468-1-git-send-email-srn@prgmr.com>

On Wed, 15 Nov 2017 11:27:07 -0800
Sarah Newman <srn@prgmr.com> wrote:

> Current memory and CPU usage for managing bridge fdb entries is unbounded.
> Add a parameter max_fdb_count, controlled from sysfs, which places an upper
> limit on the number of entries. Defaults to 1024.
> 
> When max_fdb_count is met or exceeded, whether traffic is sent out a
> given port should depend on its flooding behavior.
> 
> This may instead be mitigated by filtering mac address entries in the
> PREROUTING chain of the ebtables nat table, but this is only practical
> when mac addresses are known in advance.
> 
> Signed-off-by: Sarah Newman <srn@prgmr.com>

Thanks for your patch, I can see how this can be a real
problem, especially for a learning bridge.

There are some details which probably need to be resolved before
this can be applied.

* if the bridge is being DoS attacked by random MAC addresses
  then the policy under spam needs to be considered.
  Not sure if not inserting the new entry is the best policy.

* The counter probably doesn't need to be unsigned long (64 bit on x86_64)
  maybe u32 is enough.

* The bridge attributes in general are controllable both by netlink
  and sysfs. It would make sense to do this for max fdb as well.

Also what do the vendors using bridge for L2 offload to switch think?
Many switches need to clone table, and similar limits must be in other
versions. FreeBSD has a limit like this.

  parent reply	other threads:[~2017-11-15 20:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 19:27 [PATCH] net: bridge: add max_fdb_count Sarah Newman
2017-11-15 19:43 ` Sarah Newman
2017-11-15 20:04 ` Stephen Hemminger [this message]
2017-11-16  2:25   ` Andrew Lunn
2017-11-16  4:05     ` Toshiaki Makita
2017-11-16  4:54       ` Sarah Newman
2017-11-16  6:13         ` Toshiaki Makita
2017-11-16  6:20           ` Roopa Prabhu
2017-11-16 16:54             ` Stephen Hemminger
2017-11-15 21:34 ` Egil Hjelmeland
2017-11-16  3:01 ` Andrew Lunn
2017-11-16  7:31 ` Nikolay Aleksandrov
2017-11-16  9:20   ` Sarah Newman
2017-11-16  9:49     ` Nikolay Aleksandrov
2017-11-16  9:58     ` Willy Tarreau
2017-11-16 18:23       ` Sarah Newman
2017-11-16 19:23         ` Andrew Lunn
2017-11-16 19:36           ` Nikolay Aleksandrov
2017-11-16 20:54             ` Sarah Newman
2017-11-16 20:21           ` Vincent Bernat
2017-11-17  0:27             ` Stephen Hemminger
2017-11-17  5:26               ` Willy Tarreau
2017-11-17  6:14                 ` Nikolay Aleksandrov
2017-11-17  8:01                   ` Nikolay Aleksandrov
2017-11-17 14:06                 ` Andrew Lunn
2017-11-17 18:44                   ` Willy Tarreau
2017-11-21 14:53 ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171115120452.3b426442@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=netdev@vger.kernel.org \
    --cc=srn@prgmr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).