Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
No attempt at all? Then it's against your own rules I've read before submitting this.
-----Original Message-----
From: Luca Boccassi <bluca@debian.org>
Sent: piatok 27. októbra 2023 11:17
To: GASPAROVIC Peter OBS/MKT <peter.gasparovic@orange.com>; 1054642@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Control: tags -1 upstream
On Fri, 27 Oct 2023 at 09:18, <peter.gasparovic@orange.com> wrote:
>
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Funix
> .stackexchange.com%2Fquestions%2F655602%2Fwhy-two-bridged-veth-cannot-
> ping-each-other%2F674621%23674621&data=05%7C01%7Cpeter.gasparovic%40or
> ange.com%7C5d4b8a4dcdf140886f7608dbd6cd941d%7C90c7a20af34b40bfbc48b925
> 3b6f5d20%7C0%7C0%7C638339950657397266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7C&sdata=mgDKlgwu7NBcoSLZwC0GooZDiBEiz6GVRL02UaMF40E%3D&reserved=0
> 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
You need to report this upstream, nobody here is going to look at something like this
____________________________________________________________________________________________________________
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.
Reply to: