On 10/16/20 8:43 AM, Vladimir Oltean wrote: > On Fri, Oct 16, 2020 at 02:11:06PM +0200, Kurt Kanzenbach wrote: >> When VLAN awareness is disabled, the packet is still classified with the >> pvid. But, later all rules regarding VLANs (except for the PCP field) >> are ignored then. So, the programmed pvid doesn't matter in this case. > > Ok, clear now. > >> The only way to implement the non-filtering bridge behavior is this >> flag. However, this has some more implications. For instance when >> there's a non filtering bridge, then standalone mode doesn't work >> anymore due to the VLAN unawareness. This is not a problem at the >> moment, because there are only two ports. But, later when there are more >> ports, then having two ports in a non-filtering bridge and one in >> standalone mode doesn't work. That's another limitation that needs to be >> considered when adding more ports later on. > > Well, then you have feedback to bring to the hardware engineers when > switches with more than 2 user ports will be instantiated. > >> Besides that problem everything else seem to work now in accordance to >> the expected Linux behavior with roper restrictions in place. > > Ok, that's great. I probably missed parts of this long discussion, but for this generation of switches, does that mean that you will only allow a bridge with vlan_filtering=1 to be configured and also refuse toggling of vlan_filtering at run time? -- Florian
