Linux Ethernet Bridging - Dec 2018 - [Bridge] Correct PVID behavior with bridge's VLAN filtering on/off?

Hi Nikolay, Roopa, Jiri, Ido,

When a bridge has vlan_filtering=0 and notifies a switch driver through
HOST_OBJ_MDB about MC addresses that the CPU/management port is
interested in getting MC traffic for, I am seeing that the mdb->vid is
set to 0 because br_allowed_ingress() checks for BROPT_VLAN_ENABLED
which is now disabled and so we never populated *vid to anything but 0
because the caller: br_handle_frame_finish() zeroed it out.

This creates a problem with the b53 DSA switch driver because in order
to match the bridge's default_pvid, we did program the switch's
"default
tag" to be 1, which gets used for all untagged frames that ingress the
switch (which AFAICT is correct behavior for PVID).

Despite having turned off VLAN filtering in the switch such that it does
allow ingress of packets with a VID that is not present in the VLAN
table (violation), Multicast addresses do behave differently and we
really must be strictly matching the programmed PVID in order for MC
frames to ingress the switch even with VLAN filtering turned off.

So with all that being written, should the bridge still be sending MDB
notifications and use the bridge's default_pvid even with
vlan_filtering=0? And if we did that, what use case could we be possibly
breaking?

Let me know if this is not clear so I can provide mode details.

Thank you very much.
-- 
Florian

On Tue, Dec 11, 2018 at 11:48:21AM -0800, Florian Fainelli
wrote:
> Hi Nikolay, Roopa, Jiri, Ido,
> 
> When a bridge has vlan_filtering=0 and notifies a switch driver through
> HOST_OBJ_MDB about MC addresses that the CPU/management port is
> interested in getting MC traffic for, I am seeing that the mdb->vid is
> set to 0 because br_allowed_ingress() checks for BROPT_VLAN_ENABLED
> which is now disabled and so we never populated *vid to anything but 0
> because the caller: br_handle_frame_finish() zeroed it out.
s/br_handle_frame_finish()/br_dev_xmit()/ ? Since you're talking about
HOST_OBJ_MDB
> This creates a problem with the b53 DSA switch driver because in order
> to match the bridge's default_pvid, we did program the switch's
"default
> tag" to be 1, which gets used for all untagged frames that ingress the
> switch (which AFAICT is correct behavior for PVID).
Not sure I'm following. If bridge is not VLAN-aware, then where do you
see 'default_pvid' being used?
> Despite having turned off VLAN filtering in the switch such that it does
> allow ingress of packets with a VID that is not present in the VLAN
> table (violation), Multicast addresses do behave differently and we
> really must be strictly matching the programmed PVID in order for MC
> frames to ingress the switch even with VLAN filtering turned off.
> 
> So with all that being written, should the bridge still be sending MDB
> notifications and use the bridge's default_pvid even with
> vlan_filtering=0? And if we did that, what use case could we be possibly
> breaking?
> 
> Let me know if this is not clear so I can provide mode details.
I think you need to provide more details about the device you're working
with. I can explain what we're doing in mlxsw for reference.

When you use a VLAN-unaware bridge w/o VLAN devices, we make sure all
untagged packets get tagged with some arbitrary VLAN (now 1, soon 4095).
You never see this VLAN on the wire, since we remove it before sending
the packets. It is only used because all packets in the ASIC must be
tagged.

After we have a VLAN we classify the packet to a FID (bridge) and it
does {FID,DMAC} lookup in the FDB (MDB).

IIUC, your problem is that you also need to tag all the packets (you
used '1', can be something else), but then you program the MDB entry
according to the VLAN passed in the notification ('0') and not use
('1'). We completely ignore the VID in this case and use the FID which
we lookup based on the ifindex of the bridge.