Hi Nik, Thanks for the review. > This patch makes fdb lookups slower for everybody, ruins the nice key alignment, > increases the key memory usage I could make the additional, inner_vid, fdb member variable's existence depend on a compile time flag, so that these penalties would only affect the users that want the feature. > and adds more complexity for a corner case, especially > having 2 different hosts with identical macs sounds weird. I admit that the use case is rare. In this commit message, I focused on the duplicate MAC scenario, because I thought that would be the easiest way to describe it. If the problem is hosts with duplicate MACs, that's probably best remedied by just assigning a different MAC, or translating that MAC before it reaches the 802.1d bridge. There might be a potential DoS opportunity, if an attacker knows the MAC addresses on a different VLAN. Consider someone on a "guest" VLAN transmitting a frame sourced with the MAC of a server on the "production" VLAN. My personal use case is about simulating ethernet connections and VLAN aware bridges, so that I can test networking equipment that provides VLAN functionality with IVL. https://github.com/andrewstrohman/topology-sim/raw/refs/heads/main/docs/Topology%20Simulation%20for%20Mesh%20Testing.pdf?download= describes it, if you're interested in more information about it. https://docs.google.com/drawings/d/1FybJP3UyCPxVQRGxAqGztO4Qc5mgXclV4m-QEyfUFQ8 is a diagram that shows what I'm thinking about. This case is not about duplicate macs, but rather a frame being bridged in a way, such that it passes through the same bridge twice via different ports depending on the inner VLAN. In the commit message, this is what I meant by the poorly worded: "L2 hairpining where different VLANs are used for each side of the hairpin". The diagram depicts a network where a layer 2 segment is partitioned by a L2 (bridging) firewall. I admit that this is contrived and not a typical way of constructing networks. In this case, my testing system would use a 802.1ad bridge to simulate a VLAN aware bridge between .1q #1 and .1q #2. The problem is that the .1ad bridge would get confused about which ports hosts A and B are behind. The bridge would see them behind different ports depending on whether the packet was heading to, or returning from the bridge mode firewall. If these nodes were connected with an IVL .1q bridge instead of the .1ad bridge, this topology would work. So it's a scenario where connectivity failure would be due to my testing system (topology-sim) instead of the networking equipment being tested. > Fdb matching on both tags isn't a feature I've heard of, I don't know if there are switches that support it. > Could you point to anywhere in the specs that such support is mentioned? I've never heard of this either. It's just an idea that I had. I don't know of any switches that support it. > Also could you please give more details about the use case? Maybe we can help you solve > your problem without impacting everyone. Perhaps we can mix vlan-aware bridge and tc > to solve it. Thanks. I tried to give the relevant details of my use case above. I think that using tunnels instead of VLANs would fix this for me, because the switches would not learn the inner MAC. But, the tunnel header has more overhead compared to adding a tag. > As it stands I'm against adding such matching Fair enough. I also have concerns about complexity vs value, myself. I just thought that I would give this a try in case others found it useful.
