Date: Thu, 30 Mar 2023 10:07:09 +0800 From: Zhenlei Huang <zlei@FreeBSD.org> To: overwatch <overwatch@lab.kyngin.net> Cc: freebsd-net@freebsd.org Subject: Re: Help testing patch that may help diagnosing the PR 240106 Message-ID: <F487DF63-B7D3-41DE-9C46-9F60D4D55FE9@FreeBSD.org> In-Reply-To: <16b52f9e-d146-737e-1fe5-01ad62492c7f@lab.kyngin.net> References: <4431A103-64AA-4EDF-9830-ED320161B75C@FreeBSD.org> <4416034C-237B-4D8F-B04E-A22F2D56BF9C@FreeBSD.org> <16b52f9e-d146-737e-1fe5-01ad62492c7f@lab.kyngin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_751519AE-ED8B-42B6-9743-15760EE6EFFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 30, 2023, at 2:07 AM, overwatch <overwatch@lab.kyngin.net> = wrote: >=20 > 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. >=20 > 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. >=20 > Thank you for the patch! >=20 > 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 ;) >=20 > -kvs >=20 >=20 > On 3/29/23 00:05, Zhenlei Huang wrote: >>=20 >>> On Mar 29, 2023, at 1:03 PM, Zhenlei Huang <zlei@FreeBSD.org> wrote: >>>=20 >>> Hi, >>>=20 >>> I write here so that the original PR 240106 is not polluted. >>>=20 >>> Can you please test the attached patch with bridge / lagg setup? >>>=20 >>> For long: >>>=20 >>> In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240106#c28 = you encountered >>> problem and I said: >>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>> 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. >>>=20 >>> Here is a simple diagram, the arrow shows the flow of ARP request = from epair0a. >>>=20 >>> 11:22:33:44:55:66 [1] -> cc0 -> port 1 -> >>> epair0a -> epair0b -> bridge0 -> lagg0 = physical-switch <-> host0 >>> <- <- cc1 <- port 2 <- >>> [2] >>>=20 >>> 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. >>>=20 >>> Apparently bridge0 will dropped the ARP reply as it believes = 11:22:33:44:55:66 (epair0a) is >>> within segment of lagg0. >>>=20 >>>> 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. >>>=20 >>>=20 >>> Best regards, >>> Zhenlei >>>=20 >> Sorry forgot the patch. >>=20 >>=20 >>=20 >>=20 >>=20 --Apple-Mail=_751519AE-ED8B-42B6-9743-15760EE6EFFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On Mar 30, 2023, at 2:07 AM, overwatch <<a = href=3D"mailto:overwatch@lab.kyngin.net" = class=3D"">overwatch@lab.kyngin.net</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">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.<br class=3D""><br class=3D"">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.<br = class=3D""><br class=3D"">Thank you for the patch!<br class=3D""><br = class=3D"">ps - Which OS version for this patch? 13.1 release?<br = class=3D""></div></div></blockquote><div><br class=3D""></div><div>The = patch is against current, and I've tested on stable/13.</div><div>It can = be applied smoothly on releng/13.2, <span style=3D"caret-color: = rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">releng/13.1 and stable/12 = branches.</span></div><div><span style=3D"caret-color: rgb(0, 0, 0); = color: rgb(0, 0, 0);" class=3D""><br class=3D""></span></div><div><span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">You = can do it on whichever branch </span><font color=3D"#000000" = class=3D""><span style=3D"caret-color: rgb(0, 0, 0);" = class=3D"">convenient for you ;)</span></font></div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = class=3D""><br class=3D"">-kvs<br class=3D""><br class=3D""><br = class=3D"">On 3/29/23 00:05, Zhenlei Huang wrote:<br = class=3D""><blockquote type=3D"cite" class=3D""><br class=3D""><blockquote= type=3D"cite" class=3D"">On Mar 29, 2023, at 1:03 PM, Zhenlei Huang = <<a href=3D"mailto:zlei@FreeBSD.org" = class=3D"">zlei@FreeBSD.org</a>> wrote:<br class=3D""><br = class=3D"">Hi,<br class=3D""><br class=3D"">I write here so that the = original PR 240106 is not polluted.<br class=3D""><br class=3D"">Can you = please test the attached patch with bridge / lagg setup?<br class=3D""><br= class=3D"">For long:<br class=3D""><br class=3D"">In <a = href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240106#c28" = class=3D"">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D240106#c28<= /a> you encountered<br class=3D"">problem and I said:<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">The IF_BRIDGE(4) seems = to hide some thing to protect itself get confused.<br = class=3D""></blockquote>Actually IF_BRIDGE(4) has a learning mode. You = can `man ifconfig` and refer the<br class=3D"">`Bridge Interface = Parameters` section.<br class=3D""><br class=3D"">By default the = learning mode of all bridge members is on, and the bridge will<br = class=3D"">insert or update an entry to its (internal) forwarding table. = When unicast packets<br class=3D"">come to the bridge member, the bridge = will check if it is for itself, if not then<br class=3D"">the packets = will be forwarded to one bridge member if a forwarding entry is = found.<br class=3D"">While the magic is, if the bridge member to be = forwarded is the receiving one, then<br class=3D"">the packets are = silently discarded.<br class=3D""><br class=3D"">That's perfect fine, = but will be hard to diagnose if user has wrong network setup,<br = class=3D"">bridge loops e.g., or some other ones set duplicated ether = address for their nic,<br class=3D"">or some bad guys / virus / trojans = send spoofed packets on the wire. Those are common<br class=3D"">and I = think it will be good if IF_BRIDGE(4) can emit logs so that the symptoms = will<br class=3D"">be obvious and it will be easy to diagnose.<br = class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">If you = can confirm, then please config you switch properly. The two ports cc0 = and cc1 connected should be in same link aggregation group.<br = class=3D""></blockquote>If two ports (on physical switch), say 1 and 2, = are not in same link aggregation group,<br class=3D"">then packets = (typically broadcast ones) received on 1 will be forwarded to 2, and<br = class=3D"">the lagg interface will be bounce-backed (from port 2) the = packets it send (to port 1).<br class=3D"">If the lagg happenly be the = member of IF_BRIDGE(4), then the bridge will update<br class=3D"">its = forwarding entry as it learn mac address from lagg interface.<br = class=3D""><br class=3D"">Here is a simple diagram, the arrow shows the = flow of ARP request from epair0a.<br class=3D""><br = class=3D"">11:22:33:44:55:66 = [1] = &n= bsp; -> cc0 -> port 1 -><br = class=3D""> epair0a -> epair0b = -> bridge0 -> lagg0 = &n= bsp; physical-s= witch <-> host0<br class=3D""> = &n= bsp; &nbs= p; <- = <- cc1 <- port 2 = <-<br class=3D""> = &n= bsp; &nbs= p; [2]<br= class=3D""><br class=3D"">On [1] bridge0 will learn MAC = 11:22:33:44:55:66 on port member epair0b and add entry,<br = class=3D"">after [2] it will learn same MAC on port member lagg0 and = update the entry. Then<br class=3D"">subsequent ARP reply (to = 11:22:33:44:55:66, epair0a i.e.) sent from host0 reach bridge0<br = class=3D"">via lagg0.<br class=3D""><br class=3D"">Apparently bridge0 = will dropped the ARP reply as it believes 11:22:33:44:55:66 (epair0a) = is<br class=3D"">within segment of lagg0.<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">I'll see if I can teach = IF_BRIDGE(4) to emit warnings in case it get ARP request packet sent = from it self.<br class=3D""></blockquote>Attached patch will enable = IF_BRIDGE(4) to emit logs about MAC address port flapping.<br = class=3D"">Various hardware vendors have similar facilities.<br = class=3D""><br class=3D""><br class=3D"">Best regards,<br = class=3D"">Zhenlei<br class=3D""><br class=3D""></blockquote>Sorry = forgot the patch.<br class=3D""><br class=3D""><br class=3D""><br = class=3D""><br class=3D""><br = class=3D""></blockquote></div></div></blockquote></div><div = class=3D""><div><br class=3D""></div> </div> <br class=3D""></body></html>= --Apple-Mail=_751519AE-ED8B-42B6-9743-15760EE6EFFE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F487DF63-B7D3-41DE-9C46-9F60D4D55FE9>