From nobody Wed Mar 29 05:03:29 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PmZFs2vsGz41yf6 for ; Wed, 29 Mar 2023 05:03:45 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PmZFs1Zr6z4Gp8; Wed, 29 Mar 2023 05:03:45 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680066225; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=LCHqTwp/fktdqRTT/l0k5a7zIXW2SBYsiPTECfauriE=; b=vR3AbVrQu9dgX74u8be1rQn76UrU4YcQvV+LKDQ2ZNmHgolul04+BlU73l3J7oXFgWz4iQ 59D4hJJeIRnQlsP/Su2Scg7I0NB+VSVsovPcMF1Swd1i+AZOVp/h2i/Dp9ACRQ/YFT1b5a Pday60tYbGykl3I8Axfe5q5412djn+b9FBmPw7fBaeRMHB91iKZ+RFkqlXYVbawKb+DBuk j8uf0h0zmxYKd+IezT0THC+5G1+7WdVo2jqlDfX1INKOmevoBsF96nxAvfOlj2PLl+5dmk l9fAa/iYoUHHJDYJi6fQTRz8u9+X63nK91wXLzBp10tcDIOwkPihlJ+nhd41Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680066225; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=LCHqTwp/fktdqRTT/l0k5a7zIXW2SBYsiPTECfauriE=; b=bCFJdTTio5b6mLefPIJD+o2RVrE7AYa45iMjj1fZSBAyZlcrGm8mfOTEoav686O4Jc79DL uBKr7YffWeMPUUQSL/LHvZdFUWjxFyR9XQyM52xFoLtcJbd5CvUmdRTuIHfIV2cOhUmSmp YhH42dMPkTHjIwPhRERmjXWDdDTDikiVCVB+/NE4e9+XtDYFWONrm9BN6iqI1fbijrTDIt gAQvwvOmcYf9UADMmviqjVZF5RsaIE1FLX5wJrFmTZXfJNpVKT6+DvlnIXV2BWP+MzndK0 kx1W0FleuOeV6rjBGOp/YDUspH59QlXB5H7iRPWRD1bf40wzi7aJxJYRVCnvNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680066225; a=rsa-sha256; cv=none; b=qKt6J1MSo40iu4R9pdhVYa0mNWv4yqg9Tg15i91UGRPqpi1J5doiHYXG+D2rLWNIU22OHb 9WYY3xQyV2G9JC33adqHpCWtYfAxBTO8tBQ84d+zIlA4TgO7+vNIe1635i8scA02dHIw+o OTiiVI7H8E1PFZLfVd9rj77qEc6lmQrC+zcoHQAfedW+kG2qVAEnecI9yB4MB+s8OKJSB1 COpJb/PtsN8uyn6QCh2RnigsG679trz03cny7WnQ+OrfeiTFZHhW1Hn/p2FewKs1PmRXeN e7ScgBIzy4ew1Ht1GzWgml8wIXjwsZeoTpyEjrcdV6ezXrmVSURbl0d7dv0Vsw== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PmZFr27Fyzy0f; Wed, 29 Mar 2023 05:03:44 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) Subject: Help testing patch that may help diagnosing the PR 240106 Message-Id: <4431A103-64AA-4EDF-9830-ED320161B75C@FreeBSD.org> Date: Wed, 29 Mar 2023 13:03:29 +0800 Cc: freebsd-net@freebsd.org To: overwatch@lab.kyngin.net X-Mailer: Apple Mail (2.3696.120.41.1.2) X-ThisMailContainsUnwantedMimeParts: N 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=3D240106#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 ->=20 epair0a -> epair0b -> bridge0 -> lagg0 = physical-switch <-> host0 <- <- cc1 <- port 2 <- =20 [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. 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