Re: Help testing patch that may help diagnosing the PR 240106

> On Mar 30, 2023, at 2:07 AM, overwatch <overwatch@lab.kyngin.net> wrote:
> 
> Zhenlei, I did get your message here, and I believe I understand the situation, though I don't know if it represents exactly what I was seeing with our setup.
> 
> I'll try to install your patch and set the switch back to how it was, if only to see if it shows up any errors, just as soon as I get a free minute.
> 
> Thank you for the patch!
> 
> ps - Which OS version for this patch?  13.1 release?

The patch is against current, and I've tested on stable/13.
It can be applied smoothly on releng/13.2, releng/13.1 and stable/12 branches.

You can do it on whichever branch convenient for you ;)

> 
> -kvs
> 
> 
> On 3/29/23 00:05, Zhenlei Huang wrote:
>> 
>>> On Mar 29, 2023, at 1:03 PM, Zhenlei Huang <zlei@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.
>> 
>> 
>> 
>> 
>>