> On Mar 29, 2023, at 1:03 PM, Zhenlei Huang <z...@freebsd.org> wrote: > > Hi, > > I write here so that the original PR 240106 is not polluted. > > Can you please test the attached patch with bridge / lagg setup? > > For long: > > In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240106#c28 you > encountered > problem and I said: > >> The IF_BRIDGE(4) seems to hide some thing to protect itself get confused. > Actually IF_BRIDGE(4) has a learning mode. You can `man ifconfig` and refer > the > `Bridge Interface Parameters` section. > > By default the learning mode of all bridge members is on, and the bridge will > insert or update an entry to its (internal) forwarding table. When unicast > packets > come to the bridge member, the bridge will check if it is for itself, if not > then > the packets will be forwarded to one bridge member if a forwarding entry is > found. > While the magic is, if the bridge member to be forwarded is the receiving > one, then > the packets are silently discarded. > > That's perfect fine, but will be hard to diagnose if user has wrong network > setup, > bridge loops e.g., or some other ones set duplicated ether address for their > nic, > or some bad guys / virus / trojans send spoofed packets on the wire. Those > are common > and I think it will be good if IF_BRIDGE(4) can emit logs so that the > symptoms will > be obvious and it will be easy to diagnose. > >> If you can confirm, then please config you switch properly. The two ports >> cc0 and cc1 connected should be in same link aggregation group. > > If two ports (on physical switch), say 1 and 2, are not in same link > aggregation group, > then packets (typically broadcast ones) received on 1 will be forwarded to 2, > and > the lagg interface will be bounce-backed (from port 2) the packets it send > (to port 1). > If the lagg happenly be the member of IF_BRIDGE(4), then the bridge will > update > its forwarding entry as it learn mac address from lagg interface. > > Here is a simple diagram, the arrow shows the flow of ARP request from > epair0a. > > 11:22:33:44:55:66 [1] -> cc0 -> port 1 -> > epair0a -> epair0b -> bridge0 -> lagg0 > physical-switch <-> host0 > <- <- cc1 <- port 2 <- > [2] > > On [1] bridge0 will learn MAC 11:22:33:44:55:66 on port member epair0b and > add entry, > after [2] it will learn same MAC on port member lagg0 and update the entry. > Then > subsequent ARP reply (to 11:22:33:44:55:66, epair0a i.e.) sent from host0 > reach bridge0 > via lagg0. > > Apparently bridge0 will dropped the ARP reply as it believes > 11:22:33:44:55:66 (epair0a) is > within segment of lagg0. > >> I'll see if I can teach IF_BRIDGE(4) to emit warnings in case it get ARP >> request packet sent from it self. > > Attached patch will enable IF_BRIDGE(4) to emit logs about MAC address port > flapping. > Various hardware vendors have similar facilities. > > > Best regards, > Zhenlei >
Sorry forgot the patch.
0001-bridge-Log-MAC-address-port-flapping.patch
Description: Binary data
