[Bridge] Fw: [Bug 218047] New: linux network bridge kernel set group_fwd_mask 65535
The kernel intentionally does not allow forwarding of IEEE pause frames. These need to be handled dropped in the bridge. Any mask without bit 1 set should work. Originally LACP, STP and MACPAUSE frames were always blocked and could not be changed. The restriction was relaxed for LACP and STP frames. Begin forwarded message: Date: Thu, 26 Oct 2023 05:16:24 + From: bugzilla-dae...@kernel.org To: step...@networkplumber.org Subject: [Bug 218047] New: linux network bridge kernel set group_fwd_mask 65535 https://bugzilla.kernel.org/show_bug.cgi?id=218047 Bug ID: 218047 Summary: linux network bridge kernel set group_fwd_mask 65535 Product: Networking Version: 2.5 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3 Component: Other Assignee: step...@networkplumber.org Reporter: ne-vleza...@yandex.ru Regression: No If trying set the parameter from network bridge? going error: [root@arch user]# ip link set bridge0 type bridge group_fwd_mask 65535 RTNETLINK answers: Invalid argument setting this parameter is desirable if the switching is routed to a separate virtual machine on the hypervisor, and on the host it looks like this: ip link add dev ns-switch.0 up mtu 16384 master bridge0 type veth peer name host0 address $SWMAC netns switch mtu 16384 ip link add dev ns-host1.0 up mtu 16384 master bridge0 type veth peer name host0 netns host1 mtu 16384 ip link add dev ns-host2.0 up mtu 16384 master bridge0 type veth peer name host0 netns host2 mtu 16384 ip link add dev ns-host3.0 up mtu 16384 master bridge0 type veth peer name host0 netns host3 mtu 16384 ip link add dev ns-host4.0 up mtu 16384 master bridge0 type veth peer name host0 netns host4 mtu 16384 tc qdisc add dev ns-switch.0 handle : ingress tc qdisc add dev ns-host1.0 handle : ingress tc qdisc add dev ns-host2.0 handle : ingress tc qdisc add dev ns-host3.0 handle : ingress tc qdisc add dev ns-host4.0 handle : ingress tc qdisc add dev gt-ll0 handle : ingress tc qdisc add dev gt-ll0 handle 1: root htb default 10 tc qdisc add dev ns-switch.0 handle 1: root htb default 10 tc qdisc add dev ns-host1.0 handle 1: root htb default 10 tc qdisc add dev ns-host2.0 handle 1: root htb default 10 tc qdisc add dev ns-host3.0 handle 1: root htb default 10 tc qdisc add dev ns-host4.0 handle 1: root htb default 10 tc filter add dev ns-host1.0 parent : prio 9 protocol all flower dst_mac 01:00:00:00:00:00/8 action vlan push id 10 action mirred egress redirect dev gt-ll0 tc filter add dev ns-host2.0 parent : prio 9 protocol all flower dst_mac 01:00:00:00:00:00/8 action vlan push id 11 action mirred egress redirect dev gt-ll0 tc filter add dev ns-host3.0 parent : prio 9 protocol all flower dst_mac 01:00:00:00:00:00/8 action vlan push id 12 action mirred egress redirect dev gt-ll0 tc filter add dev ns-host4.0 parent : prio 9 protocol all flower dst_mac 01:00:00:00:00:00/8 action vlan push id 13 action mirred egress redirect dev gt-ll0 tc filter add dev ns-host1.0 parent : prio 10 protocol all matchall action vlan push id 10 tc filter add dev ns-host2.0 parent : prio 10 protocol all matchall action vlan push id 11 tc filter add dev ns-host3.0 parent : prio 10 protocol all matchall action vlan push id 12 tc filter add dev ns-host4.0 parent : prio 10 protocol all matchall action vlan push id 13 tc filter add dev ns-host1.0 parent 1: prio 65535 protocol all matchall action drop tc filter add dev ns-host1.0 parent 1: prio 1 protocol 802.1Q flower vlan_id 10 action vlan pop tc filter add dev ns-host2.0 parent 1: prio 65535 protocol all matchall action drop tc filter add dev ns-host2.0 parent 1: prio 1 protocol 802.1Q flower vlan_id 11 action vlan pop tc filter add dev ns-host3.0 parent 1: prio 65535 protocol all matchall action drop tc filter add dev ns-host3.0 parent 1: prio 1 protocol 802.1Q flower vlan_id 12 action vlan pop tc filter add dev ns-host4.0 parent 1: prio 65535 protocol all matchall action drop tc filter add dev ns-host4.0 parent 1: prio 1 protocol 802.1Q flower vlan_id 13 action vlan pop the config example from be network lab. -- You may reply to this email to add a comment. You are receiving this mail because: You are the assignee for the bug.
Re: [Bridge] [PATCH iproute2-next 1/2] configure: add the --color option
On Wed, 13 Sep 2023 19:58:25 +0200 Andrea Claudi wrote: > This commit allows users/packagers to choose a default for the color > output feature provided by some iproute2 tools. > > The configure script option is documented in the script itself and it is > pretty much self-explanatory. The default value is set to "never" to > avoid changes to the current ip, tc, and bridge behaviour. > > Signed-off-by: Andrea Claudi > --- More build time config is not the answer either. Don't want complaints from distribution users about the change. Needs to be an environment variable or config file.
Re: [Bridge] Getting + maintaining a consistent MDB view in userspace?
On Tue, 8 Aug 2023 02:29:09 +0200 Linus Lüssing wrote: > Hi, > > Is there a recommended way to get and monitor the MDB state from > userspace, without potential synchronization races? > > I can use "bridge monitor mdb" to get changes or "bridge mdb show" > to get the current state (as well as use the underlying netlink > calls from my own application without the "bridge" command). > > But if I were first calling "bridge mdb show" and then "bridge > monitor mdb" then there is a brief moment where I might miss some > changes. Or if I were doing it the other way around then a change > might wrongly override a valid entry? Or the full dump might not > be as up to date as the change event I got before? > > Ideally I'd be looking for a variant of "bridge monitor mdb" which > first dumps the whole, consistent mdb state and after that > provides updates in the correct order. > > Regards, Linus Same issue as dumping routing table which routing daemons deal with. Most applications end up with two netlink sockets, one for monitor and one for dumping. You really can't do it from the bridge utility, need to build your own tools.
[Bridge] [PATCH iproute2 3/7] bridge: make print_vlan_info static
Function defined and used in only one file.
Signed-off-by: Stephen Hemminger
---
bridge/br_common.h | 1 -
bridge/vlan.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bridge/br_common.h b/bridge/br_common.h
index 1bdee65844c1..704e76b0acb2 100644
--- a/bridge/br_common.h
+++ b/bridge/br_common.h
@@ -6,7 +6,6 @@
#define MDB_RTR_RTA(r) \
((struct rtattr *)(((char *)(r)) + RTA_ALIGN(sizeof(__u32
-void print_vlan_info(struct rtattr *tb, int ifindex);
int print_linkinfo(struct nlmsghdr *n, void *arg);
int print_mdb_mon(struct nlmsghdr *n, void *arg);
int print_fdb(struct nlmsghdr *n, void *arg);
diff --git a/bridge/vlan.c b/bridge/vlan.c
index 5b304ea94224..dfc62f83a5df 100644
--- a/bridge/vlan.c
+++ b/bridge/vlan.c
@@ -18,6 +18,7 @@
static unsigned int filter_index, filter_vlan;
static int vlan_rtm_cur_ifidx = -1;
+static void print_vlan_info(struct rtattr *tb, int ifindex);
enum vlan_show_subject {
VLAN_SHOW_VLAN,
@@ -1309,7 +1310,7 @@ static int vlan_global_show(int argc, char **argv)
return 0;
}
-void print_vlan_info(struct rtattr *tb, int ifindex)
+static void print_vlan_info(struct rtattr *tb, int ifindex)
{
struct rtattr *i, *list = tb;
int rem = RTA_PAYLOAD(list);
--
2.39.2
Re: [Bridge] [PATCH net-next 2/2] bridge: Add a sysctl to limit new brides FDB entries
On Mon, 15 May 2023 10:50:46 +0200
Johannes Nixdorf wrote:
> +static struct ctl_table br_sysctl_table[] = {
> + {
> + .procname = "bridge-fdb-max-entries-default",
That name is too long.
Also, all the rest of bridge code does not use sysctl's. Why is this
special and why should the property be global and not per bridge?
NAK
Re: [Bridge] [Question] Any plan to write/update the bridge doc?
On Mon, 24 Apr 2023 14:28:00 -0700 Jakub Kicinski wrote: > On Mon, 24 Apr 2023 17:25:08 +0800 Hangbin Liu wrote: > > Maybe someone already has asked. The only official Linux bridge document I > > got is a very ancient wiki page[1] or the ip link man page[2][3]. As there > > are > > many bridge stp/vlan/multicast paramegers. Should we add a detailed kernel > > document about each parameter? The parameter showed in ip link page seems > > a little brief. > > > > I'd like to help do this work. But apparently neither my English nor my > > understanding of the code is good enough. Anyway, if you want, I can help > > write a draft version first and you (bridge maintainers) keep working on > > this. > > > > [1] https://wiki.linuxfoundation.org/networking/bridge > > [2] https://man7.org/linux/man-pages/man8/bridge.8.html > > [3] https://man7.org/linux/man-pages/man8/ip-link.8.html > > Sounds like we have 2 votes for the CLI man pages but I'd like to > register a vote for in-kernel documentation. > > I work at a large company so my perspective may differ but from what > I see: > > - users who want to call the kernel API should not have to look at >the CLI's man Internal Kernel API's are not stable. So documentation is only the auto generated kernel docs. There is an effort to cover netlink API's with YAML. Bridge could/should be part of that. > - man pages use archaic and arcane markup, I'd like to know how many >people actually know how it works and how many copy / paste / look; >ReST is prevalent, simple and commonly understood Yes, but that is what distributions want. > - in-kernel docs are rendered on the web as soon as they hit linux-next > - we can make sure documentation is provided with the kernel changes, >in an ideal world it doesn't matter but in practice the CLI support >may never happen (no to mention that iproute does not hold all CLI) > > Obviously if Stephen and Ido prefer to document the bridge CLI that's > perfectly fine, it's their call :) For new sections of uAPI, however, > I personally find in-kernel docs superior. The in-kernel documents usually only cover the architecture and motivation. What/why/how... Not the user visible public API's.
Re: [Bridge] [Question] Any plan to write/update the bridge doc?
On Mon, 24 Apr 2023 18:46:53 +0300 Ido Schimmel wrote: > On Mon, Apr 24, 2023 at 05:25:08PM +0800, Hangbin Liu wrote: > > Hi, > > > > Maybe someone already has asked. The only official Linux bridge document I > > got is a very ancient wiki page[1] or the ip link man page[2][3]. As there > > are > > many bridge stp/vlan/multicast paramegers. Should we add a detailed kernel > > document about each parameter? The parameter showed in ip link page seems > > a little brief. > > I suggest improving the man pages instead of adding kernel > documentation. The man pages are the most up to date resource and > therefore the one users probably refer to the most. Also, it's already > quite annoying to patch both "ip-link" and "bridge" man pages when > adding bridge port options. Adding a third document and making sure all > three resources are patched would be a nightmare... > > > > > I'd like to help do this work. But apparently neither my English nor my > > understanding of the code is good enough. Anyway, if you want, I can help > > write a draft version first and you (bridge maintainers) keep working on > > this. > > I can help reviewing man page patches if you want. I'm going to send > some soon. Will copy you. > > > > > [1] https://wiki.linuxfoundation.org/networking/bridge > > [2] https://man7.org/linux/man-pages/man8/bridge.8.html > > [3] https://man7.org/linux/man-pages/man8/ip-link.8.html > > > > Thanks > > Hangbin Yes, please update the iproute2 man pages. From there, I can make the old wiki just be a reference to them. And Michael will pickup the man7.org versions from the current iproute2. The iproute2 git tree is single source of current documentation please.
Re: [Bridge] [PATCH net-next 01/16] net: bridge: Set strict_start_type at two policies
On Thu, 26 Jan 2023 18:01:09 +0100
Petr Machata wrote:
> static const struct nla_policy br_port_policy[IFLA_BRPORT_MAX + 1] = {
> + [IFLA_BRPORT_UNSPEC]= { .strict_start_type =
> + IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT + 1 },
Is the original IFLA_BRPORT a typo? ETH not EHT
Re: [Bridge] How to connect more than 200 interfaces to a bridge
On Wed, 09 Nov 2022 19:25:32 + Ali Shirvani wrote: > Sent with Proton Mail secure email. > > --- Original Message --- > On Wednesday, November 9th, 2022 at 8:21 PM, Stephen Hemminger > wrote: > > > > On Wed, 09 Nov 2022 10:51:27 + > > 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.
Re: [Bridge] How to connect more than 200 interfaces to a bridge
On Wed, 09 Nov 2022 19:25:32 + Ali Shirvani wrote: > Sent with Proton Mail secure email. > > --- Original Message --- > On Wednesday, November 9th, 2022 at 8:21 PM, Stephen Hemminger > wrote: > > > > On Wed, 09 Nov 2022 10:51:27 + > > 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. It is not a spanning tree issue, in fact STP can protect you from bad VM's. It is more about configuring the bridge ports after setup.
Re: [Bridge] How to connect more than 200 interfaces to a bridge
On Wed, 09 Nov 2022 10:51:27 + Ali Shirvani via Bridge 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](https://proton.me/) 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.
Re: [Bridge] [PATCH iproute2-next 2/2] bridge: fdb: enable FDB blackhole feature
On Thu, 29 Sep 2022 17:21:37 +0200
Hans Schultz wrote:
>
> @@ -493,6 +496,8 @@ static int fdb_modify(int cmd, int flags, int argc, char
> **argv)
> req.ndm.ndm_flags |= NTF_EXT_LEARNED;
> } else if (matches(*argv, "sticky") == 0) {
> req.ndm.ndm_flags |= NTF_STICKY;
> + } else if (matches(*argv, "blackhole") == 0) {
> + ext_flags |= NTF_EXT_BLACKHOLE;
> } else {
> if (strcmp(*argv, "to") == 0)
> NEXT_ARG();
The parsing of flags is weird here, most of the flags are compared with strcmp()
but some use matches().. I should have used strcmp() all the time; but at the
time did not realize what kind of confusion matches() can cause.
