On Sat, Nov 30, 2024 at 12:07:57AM +0000, Andy Strohman wrote: > 802.1q networks with IVL (independent VLAN learning) can > tolerate duplicate MACs as long as the duplicates > reside in different VLANs. Similarly, IVL networks > allow for L2 hairpining where different VLANs are > used for each side of the hairpin in order to not > confuse the intermediate bridge's FDBs. > > When these types of networks are inter-connected > using 802.1ad or Q-in-Q, only the outer VLAN tag is > considered by the 802.1ad bridge during FDB lookup. > > While traffic segregation by inner and outer VID works as > expected, the inner VLAN's independent VLAN learning can > be defeated. > > The following example describes the issue in terms of > duplicate MACS in different VLANs. But, the same concept > described in this example also applies L2 hairpining via > different VLANs. > > _______________________ > | .1ad bridge | > |_______________________| > PVID3| PVID3| PVID3| > | | | > TAGGED: 7| 8| 8| > ____|____ _____|___ _____|___ > | .1q br 1| |.1q br 2| |.1q br 3| > |_________| |________| |________| > PVID7 | PVID8 | PVID8| > HOST A HOST B HOST C > > The above diagram depicts a .1ad bridge that has "pvid 3 > untagged" configured for every member port. These member ports are > connected to .1q bridges, named 1, 2 and 3. .1q br 1 allows VID 7 tagged > on its port facing the .1ad bridge. .1q bridge 2 and 3 allow > VID 8 tagged on their ports that face the .1ad bridge. Host A > is connected to .1q br 1 via a port that is configured as "pvid 7 > untagged". Host B and C are connected to bridges via ports > configured as "pvid 8 untagged". > > Prior to this change, if host A has the same (duplicate) MAC > address as host B, this can disrupt communication between > host B and host C. This happens because the .1ad bridge > will see the duplicate MAC behind two of its ports > within the same VID (3). It's not examining the inner VLAN to > know that the hosts are actually reside within in different > L2 segments. > > With this change, the .1ad bridge uses both the inner and outer VID > when looking up the FDB. With this technique, host B and C are > able to communicate without disruptions due to the duplicate MAC > assigned to host A. > > Here is an example FDB dump on a .1ad bridge that is configured like > the above diagram: > > root@OpenWrt:~# bridge fdb show dynamic > f4:a4:54:80:93:2f dev lan3 vlan 3 inner vlan 8 master br-lan > f4:a4:54:81:7a:90 dev lan1 vlan 3 inner vlan 7 master br-lan > f4:a4:54:81:7a:90 dev lan2 vlan 3 inner vlan 8 master br-lan > > Note how duplicate MAC f4:a4:54:81:7a:90 is behind both lan1 and > lan2. This FDB dump shows two entries with the same MAC and > the same 802.1ad VLAN, 3. Prior to this change, only one fdb entry > per MAC/VID would be possible. As such, the bridge would have > issues forwarding. After this change, these entries are understood > to be distinct as they pertain to different inner vlans, and > therefore separate L2 segments. > > Signed-off-by: Andy Strohman <andrew@xxxxxxxxxxxxxxxxxx> > --- > drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +- > drivers/net/ethernet/intel/ice/ice_main.c | 6 +- > drivers/net/ethernet/intel/igb/igb_main.c | 4 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +- > .../ethernet/mellanox/mlxsw/spectrum_router.c | 4 +- > .../ethernet/mellanox/mlxsw/spectrum_span.c | 4 +- > .../mellanox/mlxsw/spectrum_switchdev.c | 2 +- > drivers/net/ethernet/mscc/ocelot_net.c | 4 +- > .../net/ethernet/qlogic/qlcnic/qlcnic_main.c | 8 +- > drivers/net/macvlan.c | 4 +- > drivers/net/vxlan/vxlan_core.c | 6 +- > include/linux/if_bridge.h | 4 +- > include/linux/netdevice.h | 6 +- > include/linux/rtnetlink.h | 4 +- > include/trace/events/bridge.h | 20 ++-- > include/uapi/linux/if_link.h | 1 + > include/uapi/linux/neighbour.h | 1 + > net/bridge/br_arp_nd_proxy.c | 8 +- > net/bridge/br_device.c | 11 +- > net/bridge/br_fdb.c | 107 ++++++++++-------- > net/bridge/br_input.c | 22 ++-- > net/bridge/br_netlink.c | 18 ++- > net/bridge/br_private.h | 25 ++-- > net/bridge/br_vlan.c | 34 +++++- > net/core/neighbour.c | 1 + > net/core/rtnetlink.c | 58 ++++++---- > 26 files changed, 227 insertions(+), 143 deletions(-) > Hi, This patch makes fdb lookups slower for everybody, ruins the nice key alignment, increases the key memory usage and adds more complexity for a corner case, especially having 2 different hosts with identical macs sounds weird. 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? 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. As it stands I'm against adding such matching, but I'd love to hear what other people think. Cheers, Nik
