On Tue Oct 06 2020, Vladimir Oltean wrote: > On Tue, Oct 06, 2020 at 03:23:36PM +0200, Kurt Kanzenbach wrote: >> On Tue Oct 06 2020, Vladimir Oltean wrote: >> Does this mean that tagged traffic is forwarded no matter what? > > Precisely. The bridge VLAN table should be irrelevant to the acceptance > or forwarding decision of the packet if vlan_filtering is 0. I see. > >> That doesn't work with the current implementation, because the VLAN >> tags are interpreted by default. There's a global flag to put the >> switch in VLAN unaware mode. But it's global and not per bridge or >> port. > > Oh, there is? Maybe you can use it then. > > JUST FOR CONTEXT, for sja1105 and felix/ocelot, this is the mode that > they're operating in, when a bridge with vlan_filtering=0 is configured > as an upper. > > In sja1105, I don't even have the VLAN awareness flag that you have. So > I need to change the VLAN TPID from 0x8100 to 0xdadb, and the switch > will think that VLAN-tagged frames aren't VLAN. So all frames are tagged > internally by the switch with the port-based VLAN ID and PCP, when in > vlan_filtering=0. > And because my knob is global and not per bridge either, I just set > ds->vlan_filtering_is_global = true and let DSA handle the rest. What's that flag doing? ... /* Disallow bridge core from requesting different VLAN awareness * settings on ports if not hardware-supported */ bool vlan_filtering_is_global; OK, that's what I need for the bridging part. > > As for ocelot/felix, those switches have 2 knobs: > - VLAN awareness: does the ingress port derive the classified VLAN from > the packet's 802.1Q header? If yes, the VLAN ID and PCP are taken from > the packet. If not, they are taken from the port-based default. > - VLAN ingress filtering: does the ingress port drop a VLAN-tagged frame > if the classified VLAN is not installed in its ingress filter? > > As you may guess, even for ocelot/felix, when we have a bridge with > vlan_filtering=0, we are still configuring it as: > VLAN awareness = disabled > VLAN ingress filtering = enabled > > Because the classified VLAN is not derived from the packet, it will > always be equal to the pvid of the port, which is installed privately by > the driver. So no packet drops due to VLAN, regardless of VLAN ID. > >> So you're saying private VLANs can be used but the user or the other >> kernel modules shouldn't be allowed to use them to simplify the >> implementation? Makes sense to me. > > Yes. > And because the user is more likely to install VLAN 2 and 3 than 4095 > and 4094, maybe you could use private VLANs from the end of the range, > just to make this restriction less obvious (or maybe not at all). > >> The egress port has to member to that VLAN. > > Same as ocelot/felix. This is the reason why we make it VLAN-unaware. > There's no point in disabling just VLAN ingress filtering if the end > result is still going to be a drop, albeit due to a different reason (no > destinations). OK. Thanks, Kurt
Attachment:
signature.asc
Description: PGP signature
