From: Stephen Hemminger <stephen@networkplumber.org>
To: Ali Shirvani <alishirv@protonmail.com>
Cc: Ali Shirvani via Bridge <bridge@lists.linux-foundation.org>
Subject: Re: [Bridge] How to connect more than 200 interfaces to a bridge
Date: Wed, 9 Nov 2022 12:08:58 -0800 [thread overview]
Message-ID: <20221109120858.52e5a0aa@hermes.local> (raw)
In-Reply-To: <pPm5jFjNYHBUzqlDouAIg2v7XTQZJnHIVSWXoYOaTijreJ22xAZOSAcwJXHJiTLN8jIAQCs-LeX7hp9hp-FaxW-HGjn69fc6-eG3Kv6lxc4=@protonmail.com>
On Wed, 09 Nov 2022 19:25:32 +0000
Ali Shirvani <alishirv@protonmail.com> wrote:
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, November 9th, 2022 at 8:21 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
>
> > On Wed, 09 Nov 2022 10:51:27 +0000
> > Ali Shirvani via Bridge bridge@lists.linux-foundation.org wrote:
> >
> > > Hello everyone,
> > >
> > > It seems we reach the Linux bridge limitation on the number of interfaces in a single bridge. Currently, we have 210 tap interface in a bridge, and we suffer from more than 50% packet loss when we ping the IP address of the virtual machine that uses one of the tap interfaces in the bridge.
> > > Do you know how we can connect more than 200 VMs virtual interfaces to a bridge?
> > >
> > > Best regards,
> > > Ali
> > >
> > > Sent with Proton Mail secure email.
> >
> >
> > The upper limit on interfaces per bridge should be 1023.
> > That limitation comes from spanning tree.
> >
> > You might bet able to improve performance by disabling flooding to those tap devices.
> > Normally, any broadcast/unknown/multicast must be copied and flooded to each interface.
>
> Thanks a lot for your guidance. I disabled the spanning tree on the bridge with `brctl stp br0 off` but the issue does not resolve. Would you please elaborate more about disabling flooding on tap devices, I don't know how I should disable flooding on tap devices.
Look at the documentation of the bridge command which describes per-port options:
https://man7.org/linux/man-pages/man8/bridge.8.html
You do want to leave flooding on for the downstream bridge port.
You can also add some security by limiting where/when STP comes from and disable
learning on the TAP devices so that if VM sends bogus packets, the bridge won't get DoS.
prev parent reply other threads:[~2022-11-09 20:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 10:51 [Bridge] How to connect more than 200 interfaces to a bridge Ali Shirvani
2022-11-09 16:51 ` Stephen Hemminger
2022-11-09 19:25 ` Ali Shirvani
2022-11-09 19:55 ` Stephen Hemminger
2022-11-09 20:08 ` Stephen Hemminger [this message]
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=20221109120858.52e5a0aa@hermes.local \
--to=stephen@networkplumber.org \
--cc=alishirv@protonmail.com \
--cc=bridge@lists.linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.