From: Vladimir Oltean <olteanv@gmail.com>
To: Colin Foster <colin.foster@in-advantage.com>
Cc: netdev@vger.kernel.org,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Horatiu Vultur <horatiu.vultur@microchip.com>
Subject: Re: packets trickling out of STP-blocked ports
Date: Sat, 1 Jan 2022 18:04:29 +0200 [thread overview]
Message-ID: <20220101160429.hmvjahhapob4gkol@skbuf> (raw)
In-Reply-To: <20211231002823.de3ugpurq3fv343b@skbuf>
On Fri, Dec 31, 2021 at 02:28:23AM +0200, Vladimir Oltean wrote:
> Traditionally, DSA has made a design decision that all switch ports
> inherit the single MAC address of the DSA master. IOW, if you have 1 DSA
> master and 4 switch ports, you have 5 interfaces in the system with the
> same MAC address. It was like this for a long time, and relatively
> recently, Xiaofei Shen added the ability for individual DSA interfaces
> to have their own MAC address stored in the device tree.
I thought a bit more in the back of my head and I need to make a
correction to what I said. It doesn't matter that DSA interfaces have
the same MAC address, because swp2 and swp3 are both bridge ports, and
therefore, their MAC addresses are both local FDB entries, even if
unique. So the bridge would still complain that it receives packets with
a MAC SA equal to a local FDB entry.
ip link add veth0 type veth peer name veth1
ip link add br0 type bridge
ip link set veth0 master br0
[ 84.987666] br0: port 1(veth0) entered blocking state
[ 84.992857] br0: port 1(veth0) entered disabled state
[ 84.998172] device veth0 entered promiscuous mode
ip link set veth1 master br0
[ 87.083140] br0: port 2(veth1) entered blocking state
[ 87.088280] br0: port 2(veth1) entered disabled state
[ 87.093625] device veth1 entered promiscuous mode
ip link set br0 type bridge stp_state 1
ip link set br0 up
ip link set veth0 up
ip link set veth1 up
[ 116.758260] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
[ 116.764899] br0: port 2(veth1) entered blocking state
[ 116.771353] br0: port 2(veth1) entered listening state
[ 116.778272] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
[ 116.785703] br0: port 1(veth0) entered blocking state
[ 116.790776] br0: port 1(veth0) entered listening state
[ 117.112892] br0: port 2(veth1) entered blocking state
[ 132.312686] br0: port 1(veth0) entered learning state
[ 133.740183] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 145.752889] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 147.672675] br0: port 1(veth0) entered forwarding state
[ 147.677978] br0: topology change detected, propagating
[ 147.683388] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
[ 149.741219] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 176.472805] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 181.742095] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 238.552814] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 245.742659] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
bridge link
6: veth1@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state blocking priority 32 cost 2
7: veth0@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
Looking at br_fdb_update(), the print is pretty harmless - the bridge is
smart enough to not actually relearn the local FDB entry towards an
external port. No FDB update is being done. The print is also
rate-limited. So it's just that - a warning. I am not sure whether it's
worth disabling IPv6 Router Solicitations, given that, as mentioned,
basically any other traffic sent through the plain bridge port will
trigger this. I consider it a non-problem.
ip addr add 192.168.100.1/24 dev veth1
ping 192.168.100.2
PING 192.168.100.[ 1434.033119] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
2 (192.168.100.2) 56(84) bytes of data.
[ 1435.112977] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1436.152991] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1437.193428] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
From 192.168.100.1 icmp_seq=1 Destination Host Unreachable
From 192.168.100.1 icmp_seq=2 Destination Host Unreachable
From 192.168.100.1 icmp_seq=3 Destination Host Unreachable
[ 1438.232784] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1438.260075] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1439.272769] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
[ 1440.312904] br0: received packet on veth0 with own address as source address (addr:c2:fc:33:30:4c:bf, vlan:0)
From 192.168.100.1 icmp_seq=4 Destination Host Unreachable
^C
--- 192.168.100.2 ping statistics ---
7 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6280ms
pipe 4
next prev parent reply other threads:[~2022-01-01 16:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 23:07 packets trickling out of STP-blocked ports Colin Foster
2021-12-31 0:28 ` Vladimir Oltean
2022-01-01 16:04 ` Vladimir Oltean [this message]
2021-12-31 10:27 ` Alexandre Belloni
2021-12-31 15:06 ` Colin Foster
2021-12-31 15:17 ` Alexandre Belloni
2021-12-31 15:31 ` Andrew Lunn
2021-12-31 15:53 ` Colin Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220101160429.hmvjahhapob4gkol@skbuf \
--to=olteanv@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=colin.foster@in-advantage.com \
--cc=horatiu.vultur@microchip.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).