| Message ID | 20180220074512.4307-1-jiri@resnulli.us |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net-next] mlxsw: spectrum_switchdev: Allow port enslavement to a VLAN-unaware bridge | expand |
On 2/20/18 12:45 AM, Jiri Pirko wrote: > From: Ido Schimmel <idosch@mellanox.com> > > Up until now we only allowed VLAN devices to be put in a VLAN-unaware > bridge, but some users need the ability to enslave physical ports as > well. > > This is achieved by mapping the port and VID 1 to the bridge's vFID, > instead of the port and the VID used by the VLAN device. > > The above is valid because as long as the port is not enslaved to a > bridge, VID 1 is guaranteed to be configured as PVID and egress > untagged. > > Signed-off-by: Ido Schimmel <idosch@mellanox.com> > Signed-off-by: Jiri Pirko <jiri@mellanox.com> > --- > drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++------- > 1 file changed, 5 insertions(+), 7 deletions(-) > Maybe I am missing something in the setup, but I am not getting host-to-host connectivity. I booted a switch with this patch, configured a bridge: # ip a sh dev br0 44: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff inet6 3000:1000:1000:1000::1/80 scope global valid_lft forever preferred_lft forever inet6 fe80::7efe:90ff:fee8:3a79/64 scope link valid_lft forever preferred_lft forever Connected ports: # ip li sh master br0 36: swp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:7d brd ff:ff:ff:ff:ff:ff 37: swp1s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:7e brd ff:ff:ff:ff:ff:ff 38: swp1s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:7f brd ff:ff:ff:ff:ff:ff 39: swp1s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:80 brd ff:ff:ff:ff:ff:ff 40: swp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff 41: swp3s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:7a brd ff:ff:ff:ff:ff:ff 42: swp3s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:7b brd ff:ff:ff:ff:ff:ff 43: swp3s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 7c:fe:90:e8:3a:7c brd ff:ff:ff:ff:ff:ff The switch can see the hosts: # net show lldp LocalPort Speed Mode RemotePort RemoteHost Summary ----------- ------- --------- ------------ ------------------------------------- ----------------------- eth0 1G Mgmt swp37 pioneerMS16.mvlab.cumulusnetworks.com IP: 10.0.3.155/22(DHCP) swp1s0 10G Access/L2 swp1 host1 Untagged: br0 swp1s1 10G Access/L2 swp1 host2 Untagged: br0 swp1s2 10G Access/L2 swp1 host3 Untagged: br0 swp1s3 10G Access/L2 swp1 host4 Untagged: br0 swp3s0 10G Access/L2 swp1 host5 Untagged: br0 swp3s1 10G Access/L2 swp1 host6 Untagged: br0 swp3s2 10G Access/L2 swp1 host7 Untagged: br0 swp3s3 10G Access/L2 swp1 host8 Untagged: br0 and can talk to the hosts: # ping6 ff02::2%br0 PING ff02::2%br0(ff02::2) 56 data bytes 64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms 64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!) 64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!) 64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!) 64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!) 64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!) 64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!) 64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!) 64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!) but the hosts can not talk to each other: cumulus@host3:~$ net show lldp LocalPort Speed Mode RemoteHost RemotePort --------- ----- ------------ ----------- ---------- swp1 10G Interface/L3 mlx-2700-05 swp1s2 cumulus@host3:~$ ping6 3000:1000:1000:1000::2 PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes ^C --- 3000:1000:1000:1000::2 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 1999ms
On Wed, Feb 21, 2018 at 11:16:35AM -0700, David Ahern wrote: > On 2/20/18 12:45 AM, Jiri Pirko wrote: > > From: Ido Schimmel <idosch@mellanox.com> > > > > Up until now we only allowed VLAN devices to be put in a VLAN-unaware > > bridge, but some users need the ability to enslave physical ports as > > well. > > > > This is achieved by mapping the port and VID 1 to the bridge's vFID, > > instead of the port and the VID used by the VLAN device. > > > > The above is valid because as long as the port is not enslaved to a > > bridge, VID 1 is guaranteed to be configured as PVID and egress > > untagged. > > > > Signed-off-by: Ido Schimmel <idosch@mellanox.com> > > Signed-off-by: Jiri Pirko <jiri@mellanox.com> > > --- > > drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++------- > > 1 file changed, 5 insertions(+), 7 deletions(-) > > > > Maybe I am missing something in the setup, but I am not getting > host-to-host connectivity. I booted a switch with this patch, configured > a bridge: > > # ip a sh dev br0 > 44: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state > UP group default qlen 1000 > link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff > inet6 3000:1000:1000:1000::1/80 scope global > valid_lft forever preferred_lft forever > inet6 fe80::7efe:90ff:fee8:3a79/64 scope link > valid_lft forever preferred_lft forever > > Connected ports: > # ip li sh master br0 > 36: swp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:7d brd ff:ff:ff:ff:ff:ff > 37: swp1s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:7e brd ff:ff:ff:ff:ff:ff > 38: swp1s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:7f brd ff:ff:ff:ff:ff:ff > 39: swp1s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:80 brd ff:ff:ff:ff:ff:ff > 40: swp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:79 brd ff:ff:ff:ff:ff:ff > 41: swp3s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:7a brd ff:ff:ff:ff:ff:ff > 42: swp3s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:7b brd ff:ff:ff:ff:ff:ff > 43: swp3s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master br0 state UP mode DEFAULT group default qlen 1000 > link/ether 7c:fe:90:e8:3a:7c brd ff:ff:ff:ff:ff:ff > > The switch can see the hosts: > # net show lldp > > LocalPort Speed Mode RemotePort RemoteHost > Summary > ----------- ------- --------- ------------ > ------------------------------------- ----------------------- > eth0 1G Mgmt swp37 > pioneerMS16.mvlab.cumulusnetworks.com IP: 10.0.3.155/22(DHCP) > swp1s0 10G Access/L2 swp1 host1 > Untagged: br0 > swp1s1 10G Access/L2 swp1 host2 > Untagged: br0 > swp1s2 10G Access/L2 swp1 host3 > Untagged: br0 > swp1s3 10G Access/L2 swp1 host4 > Untagged: br0 > swp3s0 10G Access/L2 swp1 host5 > Untagged: br0 > swp3s1 10G Access/L2 swp1 host6 > Untagged: br0 > swp3s2 10G Access/L2 swp1 host7 > Untagged: br0 > swp3s3 10G Access/L2 swp1 host8 > Untagged: br0 LLDP packets are trapped before L2 forwarding, which can explain why LLDP works but forwarding doesn't. > > and can talk to the hosts: > # ping6 ff02::2%br0 Can you try ff02::1 ? > PING ff02::2%br0(ff02::2) 56 data bytes > 64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms > 64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!) > 64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!) > 64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!) > 64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!) > 64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!) > 64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!) > 64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!) > 64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!) > > but the hosts can not talk to each other: > > cumulus@host3:~$ net show lldp > > LocalPort Speed Mode RemoteHost RemotePort > --------- ----- ------------ ----------- ---------- > swp1 10G Interface/L3 mlx-2700-05 swp1s2 > > cumulus@host3:~$ ping6 3000:1000:1000:1000::2 > PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes > ^C > --- 3000:1000:1000:1000::2 ping statistics --- > 3 packets transmitted, 0 received, 100% packet loss, time 1999ms Can you please try # brctl showstp br0 To make sure STP state is set to forwarding? Does it matter if you try IPv4 ping or if vlan_filtering is set 1? Unfortunately, I can't reproduce on my switch. Thanks for testing, David!
On 2/21/18 12:25 PM, Ido Schimmel wrote: >> >> and can talk to the hosts: >> # ping6 ff02::2%br0 > > Can you try ff02::1 ? same result. > >> PING ff02::2%br0(ff02::2) 56 data bytes >> 64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms >> 64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!) >> 64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!) >> 64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!) >> 64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!) >> 64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!) >> 64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!) >> 64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!) >> 64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!) >> >> but the hosts can not talk to each other: >> >> cumulus@host3:~$ net show lldp >> >> LocalPort Speed Mode RemoteHost RemotePort >> --------- ----- ------------ ----------- ---------- >> swp1 10G Interface/L3 mlx-2700-05 swp1s2 >> >> cumulus@host3:~$ ping6 3000:1000:1000:1000::2 >> PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes >> ^C >> --- 3000:1000:1000:1000::2 ping statistics --- >> 3 packets transmitted, 0 received, 100% packet loss, time 1999ms > > Can you please try > > # brctl showstp br0 > > To make sure STP state is set to forwarding? it is. > > Does it matter if you try IPv4 ping or if vlan_filtering is set 1? > Unfortunately, I can't reproduce on my switch. Bring up the hosts and then reboot the switch. At that point I get no host to host communication. As soon as I flap the port on host1 host3 to host1 starts working. So it seems to be something about the initial boot state.
On Wed, Feb 21, 2018 at 12:41:39PM -0700, David Ahern wrote: > On 2/21/18 12:25 PM, Ido Schimmel wrote: > >> > >> and can talk to the hosts: > >> # ping6 ff02::2%br0 > > > > Can you try ff02::1 ? > > same result. > > > > >> PING ff02::2%br0(ff02::2) 56 data bytes > >> 64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms > >> 64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!) > >> 64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!) > >> 64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!) > >> 64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!) > >> 64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!) > >> 64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!) > >> 64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!) > >> 64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!) > >> > >> but the hosts can not talk to each other: > >> > >> cumulus@host3:~$ net show lldp > >> > >> LocalPort Speed Mode RemoteHost RemotePort > >> --------- ----- ------------ ----------- ---------- > >> swp1 10G Interface/L3 mlx-2700-05 swp1s2 > >> > >> cumulus@host3:~$ ping6 3000:1000:1000:1000::2 > >> PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes > >> ^C > >> --- 3000:1000:1000:1000::2 ping statistics --- > >> 3 packets transmitted, 0 received, 100% packet loss, time 1999ms > > > > Can you please try > > > > # brctl showstp br0 > > > > To make sure STP state is set to forwarding? > > it is. > > > > > Does it matter if you try IPv4 ping or if vlan_filtering is set 1? > > Unfortunately, I can't reproduce on my switch. > > Bring up the hosts and then reboot the switch. At that point I get no > host to host communication. As soon as I flap the port on host1 host3 to > host1 starts working. > > So it seems to be something about the initial boot state. You didn't have IPv6 *and* IPv4 ping? I'm asking because it's possible host1 sent an MLD join to the Solicited-node multicast address before the bridge started listening, which means it didn't have a corresponding MDB entry. Assuming your hosts aren't functioning as multicast routers and sending MLD queries and that you didn't configure them as mrouter ports on the switch, then when host3 sent a neighbour solicitation message to host1's Solicited-node multicast address it wasn't flooded to host3 which prevented ping from passing. This also explains why it started working when you flapped the port on host1, as Linux generates MLD joins in these cases. You can try to disable snooping: # ip link set dev br0 type bridge mcast_snooping 0 Just a guess, but worth a try. Thanks!
On 2/21/18 1:24 PM, Ido Schimmel wrote: >>> Does it matter if you try IPv4 ping or if vlan_filtering is set 1? >>> Unfortunately, I can't reproduce on my switch. >> >> Bring up the hosts and then reboot the switch. At that point I get no >> host to host communication. As soon as I flap the port on host1 host3 to >> host1 starts working. >> >> So it seems to be something about the initial boot state. > > You didn't have IPv6 *and* IPv4 ping? I'm asking because it's possible > host1 sent an MLD join to the Solicited-node multicast address before > the bridge started listening, which means it didn't have a corresponding > MDB entry. The sim only configures IPv6, but it is not acting as an mcast router. It's really a dummy setup -- bridge on the switch, ports connected to hosts. > > Assuming your hosts aren't functioning as multicast routers and sending > MLD queries and that you didn't configure them as mrouter ports on the > switch, then when host3 sent a neighbour solicitation message to host1's > Solicited-node multicast address it wasn't flooded to host3 which > prevented ping from passing. > > This also explains why it started working when you flapped the port on > host1, as Linux generates MLD joins in these cases. > > You can try to disable snooping: > > # ip link set dev br0 type bridge mcast_snooping 0 > > Just a guess, but worth a try. good guess. That change gets it working.
From: David Ahern <dsahern@gmail.com> Date: Wed, 21 Feb 2018 11:16:35 -0700 > On 2/20/18 12:45 AM, Jiri Pirko wrote: >> From: Ido Schimmel <idosch@mellanox.com> >> >> Up until now we only allowed VLAN devices to be put in a VLAN-unaware >> bridge, but some users need the ability to enslave physical ports as >> well. >> >> This is achieved by mapping the port and VID 1 to the bridge's vFID, >> instead of the port and the VID used by the VLAN device. >> >> The above is valid because as long as the port is not enslaved to a >> bridge, VID 1 is guaranteed to be configured as PVID and egress >> untagged. >> >> Signed-off-by: Ido Schimmel <idosch@mellanox.com> >> Signed-off-by: Jiri Pirko <jiri@mellanox.com> >> --- >> drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++------- >> 1 file changed, 5 insertions(+), 7 deletions(-) >> > > Maybe I am missing something in the setup, but I am not getting > host-to-host connectivity. I booted a switch with this patch, configured > a bridge: I'm waiting for this discussion to be fully resolved before applying this patch. Just FYI...
On 2/22/18 11:58 AM, David Miller wrote: > From: David Ahern <dsahern@gmail.com> > Date: Wed, 21 Feb 2018 11:16:35 -0700 > >> On 2/20/18 12:45 AM, Jiri Pirko wrote: >>> From: Ido Schimmel <idosch@mellanox.com> >>> >>> Up until now we only allowed VLAN devices to be put in a VLAN-unaware >>> bridge, but some users need the ability to enslave physical ports as >>> well. >>> >>> This is achieved by mapping the port and VID 1 to the bridge's vFID, >>> instead of the port and the VID used by the VLAN device. >>> >>> The above is valid because as long as the port is not enslaved to a >>> bridge, VID 1 is guaranteed to be configured as PVID and egress >>> untagged. >>> >>> Signed-off-by: Ido Schimmel <idosch@mellanox.com> >>> Signed-off-by: Jiri Pirko <jiri@mellanox.com> >>> --- >>> drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++------- >>> 1 file changed, 5 insertions(+), 7 deletions(-) >>> >> >> Maybe I am missing something in the setup, but I am not getting >> host-to-host connectivity. I booted a switch with this patch, configured >> a bridge: > > I'm waiting for this discussion to be fully resolved before applying this > patch. Just FYI... > Ido: IPv4 works at boot; IPv6 requires the mcast snooping disable. For this vlan-unaware bridges can that be set automatically? And then, what are the options for lldp?
On Thu, Feb 22, 2018 at 12:27:35PM -0700, David Ahern wrote: > Ido: > > IPv4 works at boot; IPv6 requires the mcast snooping disable. For this > vlan-unaware bridges can that be set automatically? Can you please try the following patch? diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c index bbd238e50f05..54262af4e98f 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c @@ -112,11 +112,11 @@ static const int mlxsw_sp_sfgc_bc_packet_types[MLXSW_REG_SFGC_TYPE_MAX] = { [MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_NON_IP] = 1, [MLXSW_REG_SFGC_TYPE_IPV4_LINK_LOCAL] = 1, [MLXSW_REG_SFGC_TYPE_IPV6_ALL_HOST] = 1, + [MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_IPV6] = 1, }; static const int mlxsw_sp_sfgc_mc_packet_types[MLXSW_REG_SFGC_TYPE_MAX] = { [MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_IPV4] = 1, - [MLXSW_REG_SFGC_TYPE_UNREGISTERED_MULTICAST_IPV6] = 1, }; static const int *mlxsw_sp_packet_type_sfgc_types[] = { It should fix your problem. The real problem that I can then address in net-next is the fact that the Linux bridge tries to be smart and only resorts to flooding unregistered multicast packets in case its querier is disabled and in case it didn't detect any other querier in the network. This isn't currently reflected to underlying drivers. Only mcast snooping on/off. Anyway, it's not related to the patch in question. You'd get the same behavior with VLAN-aware bridges. > And then, what are the options for lldp? Didn't understand the question. Can you clarify?
On 2/22/18 1:55 PM, Ido Schimmel wrote: > On Thu, Feb 22, 2018 at 12:27:35PM -0700, David Ahern wrote: >> Ido: >> >> IPv4 works at boot; IPv6 requires the mcast snooping disable. For this >> vlan-unaware bridges can that be set automatically? > > Can you please try the following patch? > ... > > It should fix your problem. it does. > > The real problem that I can then address in net-next is the fact that > the Linux bridge tries to be smart and only resorts to flooding > unregistered multicast packets in case its querier is disabled and in > case it didn't detect any other querier in the network. This isn't > currently reflected to underlying drivers. Only mcast snooping on/off. > > Anyway, it's not related to the patch in question. You'd get the same > behavior with VLAN-aware bridges. > >> And then, what are the options for lldp? > > Didn't understand the question. Can you clarify? > nm. mental lapse.
Hi Dave, On Thu, Feb 22, 2018 at 01:58:39PM -0500, David Miller wrote: > I'm waiting for this discussion to be fully resolved before applying this > patch. Just FYI... I have a fix for the issue David reported, but it is not related to this patch (problem manifests itself with VLAN-aware bridges as well).
On 2/20/18 12:45 AM, Jiri Pirko wrote: > From: Ido Schimmel <idosch@mellanox.com> > > Up until now we only allowed VLAN devices to be put in a VLAN-unaware > bridge, but some users need the ability to enslave physical ports as > well. > > This is achieved by mapping the port and VID 1 to the bridge's vFID, > instead of the port and the VID used by the VLAN device. > > The above is valid because as long as the port is not enslaved to a > bridge, VID 1 is guaranteed to be configured as PVID and egress > untagged. > > Signed-off-by: Ido Schimmel <idosch@mellanox.com> > Signed-off-by: Jiri Pirko <jiri@mellanox.com> > --- > drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12 +++++------- > 1 file changed, 5 insertions(+), 7 deletions(-) > Tested-by: David Ahern <dsahern@gmail.com>
From: Ido Schimmel <idosch@idosch.org> Date: Mon, 26 Feb 2018 08:54:33 +0200 > Hi Dave, > > On Thu, Feb 22, 2018 at 01:58:39PM -0500, David Miller wrote: >> I'm waiting for this discussion to be fully resolved before applying this >> patch. Just FYI... > > I have a fix for the issue David reported, but it is not related to this > patch (problem manifests itself with VLAN-aware bridges as well). Ok, I've applied this patch to net-next then. Thank you.
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c index f9f53af04fe1..917663adf925 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c @@ -1882,14 +1882,10 @@ mlxsw_sp_bridge_8021d_port_join(struct mlxsw_sp_bridge_device *bridge_device, struct netlink_ext_ack *extack) { struct mlxsw_sp_port_vlan *mlxsw_sp_port_vlan; + struct net_device *dev = bridge_port->dev; u16 vid; - if (!is_vlan_dev(bridge_port->dev)) { - NL_SET_ERR_MSG_MOD(extack, "Only VLAN devices can be enslaved to a VLAN-unaware bridge"); - return -EINVAL; - } - vid = vlan_dev_vlan_id(bridge_port->dev); - + vid = is_vlan_dev(dev) ? vlan_dev_vlan_id(dev) : 1; mlxsw_sp_port_vlan = mlxsw_sp_port_vlan_find_by_vid(mlxsw_sp_port, vid); if (WARN_ON(!mlxsw_sp_port_vlan)) return -EINVAL; @@ -1912,8 +1908,10 @@ mlxsw_sp_bridge_8021d_port_leave(struct mlxsw_sp_bridge_device *bridge_device, struct mlxsw_sp_port *mlxsw_sp_port) { struct mlxsw_sp_port_vlan *mlxsw_sp_port_vlan; - u16 vid = vlan_dev_vlan_id(bridge_port->dev); + struct net_device *dev = bridge_port->dev; + u16 vid; + vid = is_vlan_dev(dev) ? vlan_dev_vlan_id(dev) : 1; mlxsw_sp_port_vlan = mlxsw_sp_port_vlan_find_by_vid(mlxsw_sp_port, vid); if (WARN_ON(!mlxsw_sp_port_vlan)) return;