> 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? In all my examples I'm using the same PVID, because that's a required condition for the issue to happen. I omit that the other .1ad ports in could have different .1ad VIDs configured for them, to focus on the concept I'm trying to describe. But other VIDs can be configured on other ports. So, there could be collisions of .1q VIDs across different .1ad VIDs. As such, I don't want to ignore the outer VID during FDB lookup. In my use case (topology-sim) the test fabric consists of .1ad bridges that are connected to networking equipment under test. The topology-sim user configures virtual ethernet cables (point to point) and/or L2 IVL ethernet segments between multiple devices under test. They do this to construct an arbitrary ethernet topology that they want to test. topology-sim assigns / maps each one of these L2 segments to a unique .1ad VID. This is how it keeps the "virtual wires" from interfering with each other. So if one virtual wire (ie .1ad vid 3) is connecting to a switch under test that is emitting frames with .1q vid 7, I want this virtual wire to be independent from another virtual wire (ie .1ad vid 4) that is also emitting frame with .lq7 vid 7. I acknowledge that we shouldn't make this upstream change just for topology-sim, considering that I'm the only user of it. But these same problems can affect, for example, metro ethernet carriers that use .1ad vlan stacking to differentiate between their different customer's sites. I'm not trying to claim that metro ethernet carriers would be inclined to use this feature -- I'm just providing another example to point out that this same concept applies to use cases outside of topology-sim, because toplogy-sim uses VLAN stacking in a typical, conventional way. I'll now proceed to go over my hairpin example, https://docs.google.com/drawings/d/1FybJP3UyCPxVQRGxAqGztO4Qc5mgXclV4m-QEyfUFQ8 in more detail. I think that it will help demonstrate why I want to consider the inner tags. It's an example about a circuitous network path where the same packet can enter the same .1ad bridge multiple times, with the same .1ad VID, but different inner .1q VIDs. Like I mentioned before, this network is contrived. I've never seen this done, and don't expect that it is a common topology. But my goal is to prevent connectivity issues that only arise due to how topology-sim constructs the virtual L2 ethernet segments. The network under test has a bridge mode firewall that is used to inspect traffic as it passes from some subset of a L2 segment to another subset of the same L2 segment. The way that the network operator achieve this goal is by creating separate VLANs for each subset of the L2 segment that need firewall interjection. This way, communicate between these different subsets are forced though the firewall. The firewall bridges the two VLANs to merge them into one L2 segment, one broadcast domain. Say the topology-sim user wants to interconnect two .q1 bridges via a virtual Ethernet connection. topology-sim accomplishes this by setting the same PVID for both ports that that face these .q1 switches under test. Let's follow what happens when a packets it transmitted from A towards B. When the frame is emitted from ".lq #1", heading toward the .1ad switch, it is .1q tagged as 7. When the .1ad bridge receives the frame, it will associate it with .1ad vid 3 and .1q vid 7 can be seen in the packet, if desired. At this point, the .1ad bridge can either learn that A is behind it's left port, for .1ad vid 3 (current implementation), or it can learn that A is behind the left port only for .1ad vid 3 + inner .1a vid 7 (proposed functionality). When the frame leaves the .1ad switch heading toward ".1q #2", it will just have .1q vid 7 tag. ".1q #2" sends the packet to the firewall, via its left port, untagged. The firewall bridges the frame, and therefore transmits out its right port to ".1q #2", untagged. ".1q #2" transmits toward .1ad with .1q tag 8. When the .1ad bridge receives the frame, it will associate it with .1ad vid 3 and the inner .1q vid 8 can be seen in the packet if desired. At this point, the .1ad bridge can either learn that A is behind its right port, for .1ad vid 3 or it can learn that A is behind it's right port, for .1ad vid 3 + .1q inner vid 8. Without my change, the .1ad switch's fdb entry for A's mac, .1ad vid 3, would flip continuously between the left and right port. With my change, for .1ad vid 3, the .1ad bridge will always forward packets destined to host A's MAC to the right if the inner vid is 8 and will always forward host A's MAC to the left when the inner vid is 7. I hope this example explains why I want to look at the inner VID. The fact that we can have inner VID collisions for different outer vids, drives the need to examine the outer VID. This is why, collectively I want to consider MAC + inner + outer. Does that make sense?
