Message-ID:  <DBBPR02MB1046348F8268D662710176873F8DDA@DBBPR02MB10463.eurprd02.prod.outlook.com>
Date: Thu, 26 Oct 2023 13:35:08 +0000
From: peter.gasparovic@...nge.com
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Failing ARP relay net -> Linux bridge -> veth port --> NS veth port

Hello Kernel team,

I would like to report problem which possibly has to do with IPROUTE2 package, I’m experiencing it both Debian 10 and 12 and don’t know it this is industry wide so using your contact per “ip” man-page. I really can’t appreciate enough the whole network kernel evolution has converged to “ip” tools and comfort with it in general. 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
(Bridge) veth IP@ = .44
Bridge IP@ = .254
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@...ian:~$ 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
<br><div style='text-align: Center;font-family: Helvetica 75 Bold;color: #ED7D31;font-size: 8pt;margin: 5pt;'>Orange Restricted</div>
____________________________________________________________________________________________________________
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.

Powered by blists - more mailing lists