Package: iproute2 Version: 4.20.0-2+deb10u1 Problem: External MAC@ reaches max Linux bridge, but not net namespace linked via veth pair to it, based on very minimal config
Hello Debian team, I would like to report problem which possibly has to do with IPROUTE2 package, I’m experiencing it both Debian 10 (this) and 12 (6.1.0-3). I really did my best reviewing at least 7 stack-exchange (and like) stories and I’m at my wit’s end, wondering why this is possibly not fixed in 2023 seeing debates go back into like 2014.. So it’s plain simple to want to make multiple namespaces able to communicate via common host bridge to external network. VETH tech is all time documented as solution to this. The problem on given path in subject is this: NS veth IP@ = .251 , 0e:61:72:97:aa:ff (Bridge) veth IP@ = .44 , ce:18:16:4b:0c:c2 Bridge IP@ = .254 , 00:50:56:01:01:02 External IP@ = .other 1) When I initially set up plain “veth port --> NS veth port”, with IP@ at each end, it’s all seamless, ARP and pings.. >== 2) Once I enslave veth port to bridge, I can’t reach external network <=== 3) Veth also does not work on IP level anymore, all the time with ICMP echo from NS space it runs ARP first, though both “ip nei” are populated with mutual MAC records. The following goes in loop.. peterg@debian:~$ sudo tcpdump -ni vinet-brp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vinet-brp, link-type EN10MB (Ethernet), capture size 262144 bytes 11:18:12.966955 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2333, seq 0, length 64 11:18:12.966984 ARP, Request who-has 70.0.0.251 tell 70.0.0.44, length 28 11:18:12.966989 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length 28 11:18:13.967994 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2333, seq 1, length 4) Once I configure bridge iface with some IP address of same subnet /24 like veth and NS veth (also externals) use → the NS nei can show changing MAC address for bridge veth iface 11:30:27.860907 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length 28 11:30:28.848251 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2352, seq 14, length 64 11:30:28.884892 ARP, Request who-has 70.0.0.251 tell 70.0.0.44, length 28 11:30:28.884908 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length 28 11:30:28.980890 ARP, Request who-has 70.0.0.44 tell 70.0.0.251, length 28 11:30:28.980909 ARP, Reply 70.0.0.44 is-at 00:50:56:01:01:02, length 28 <--- inet_bash >> ip nei 70.0.0.1 dev vinet FAILED 70.0.0.44 dev vinet lladdr ce:18:16:4b:0c:c2 DELAY <--- 5) The bridge vs NS veth pinging works 6) The bridge relays ARP into external network and back (checked on Cisco switch), learns of external MAC@s ===> 7) External MAC@ does not make it to NS space by ARP <=== 8) I don’t aim to deploy IP@ with bridge and bridge veth ifaces → this is just to check how it works 9) This blog was quite surprising stating that bridge without IP@ can affect routing in global namespace, few /sys kernel tweaks → no help https://unix.stackexchange.com/questions/655602/why-two-bridged-veth-cannot-ping-each-other/674621#674621 10) Even tried to stop default MAC learning on bridge veth iface by “ip link set dev vinet-brp type bridge_slave learning off” ⇒ did not work, neigh flushed and pinging .251 vs .254 just worked. So I believe that bridge veth iface is broken in its essential functionality using default “learning/flooding on” settings. Thanks for your time to look at this and give hope or deny this so I need to create extra ports in my host to get what I want to. BR Peter ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
