Re: [PATCH net-next] bridge: Make the FDB consider inner tag for Q-in-Q

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Wed, Dec 04, 2024 at 02:12:18AM -0800, Andrew Strohman wrote:
> > I didn't say "tagged". I just said "not PVID". There are 2 independent
> > bridge VLAN attributes: "pvid" and [egress-]"untagged". I am suggesting
> > that packets in VID 3, 4, 5 all exit the 802.1ad bridge untagged, but
> > every bridge port has a unique PVID from this range.
> >
> > bridge vlan add dev port1 vid 3 pvid untagged
> > bridge vlan add dev port1 vid 4 untagged
> > bridge vlan add dev port1 vid 5 untagged
> >
> > bridge vlan add dev port1 vid 3 untagged
> > bridge vlan add dev port1 vid 4 pvid untagged
> > bridge vlan add dev port1 vid 5 untagged
> >
> > bridge vlan add dev port1 vid 3 untagged
> > bridge vlan add dev port1 vid 4 untagged
> > bridge vlan add dev port1 vid 5 pvid untagged
> 
> Thanks for the clarification. I think you meant to have the second
> set of three commands affect port2 and the third set of three
> commands affect port3. Please let me know if I'm wrong
> about this.

Yes, it should have been port1, port2, port3.

> I gave this a try:
> 
> root@OpenWrt:~# bridge vlan show
> port              vlan-id
> lan1              3 PVID Egress Untagged
>                   4 Egress Untagged
>                   5 Egress Untagged
> lan2              3 Egress Untagged
>                   4 PVID Egress Untagged
>                   5 Egress Untagged
> lan3              3 Egress Untagged
>                   4 Egress Untagged
>                   5 PVID Egress Untagged
> root@OpenWrt:~# bridge fdb show dynamic
> f4:a4:54:80:93:2f dev lan1 vlan 3 master br-lan
> e0:3f:49:47:9a:38 dev lan2 vlan 4 master br-lan
> f4:a4:54:81:7a:90 dev lan3 vlan 5 master br-lan
> 
> Like you said, this has a FDB per port. But I think
> I need to have a FDB per inner/outer VLAN combination.
> 
> Connectiving works as expected in the above example,
> but only because of unknown-unicast flood, which of course,
> is suboptimal. The switch is acting like a hub.
> 
> For example, ever time the host behind lan1 sends a frame
> to the host behind lan2, the bridge is not able to find an FDB
> entry for the VID corresponding to PVID of lan1 and the MAC
> of the host behind lan2. The only FDB entry for the MAC
> corresponding to the host behind lan2 is associated with
> the VID corresponding to the PVID of lan2 (which is a
> different VID than what the packet arrived on).
> Hence, there is constant unicast flood.

Yes, I understand this is the implication of my proposal. I just was
under the impression that the behavior (complete segregation of stations
in the 802.1ad bridge into multiple FDBs) would be equivalent with what
you wish to achieve with the Outer+Inner VLAN lookup. To be more precise,
I thought that you want to keep the outer VLAN into the mix for FDB
lookups for exactly that reason, thus the suggestion to make the
isolation at the 802.1ad bridge level directly. I didn't look with
enough attention into the FDB dump, to see that in your example, only
the inner VID gives the namespacing that you desire.

But to be honest, looking again, I don't understand why just modifying
the bridge to perform FDB lookups based on Inner VID + MAC DA wouldn't
be sufficient? Why does it have to be Outer VID + Inner VID + MAC DA?
I guess adding a bridge option to classify on the inner VLAN protocol
could be easier to swallow, both for the software bridge and for switchdev.

> I also don't think that this solves the issue for
> https://docs.google.com/drawings/d/1FybJP3UyCPxVQRGxAqGztO4Qc5mgXclV4m-QEyfUFQ8
> . If you like, I'm happy to explain why. But before I do, I want to
> make sure we are on the same page before going further.

Here the same thing. The 802.1ad bridge has the same PVID on all ports.
Why does the FDB lookup have to be as complex as to take 2 VIDs into
consideration, instead of just the inner one?