Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
Thank you honestly for you time to look at this and cooperation.. Good decision to supply my directly with scripts like you want to deal with this. So this one was success, it worked:
peterg@debian:~/Downloads$ ./repro.sh
Cannot remove namespace file "/var/run/netns/ns0": No such file or directory
Cannot remove namespace file "/var/run/netns/ns1": No such file or directory
Cannot find device "br0"
PING 10.0.0.101 (10.0.0.101): 56 data bytes
64 bytes from 10.0.0.101: icmp_seq=0 ttl=64 time=0.057 ms
64 bytes from 10.0.0.101: icmp_seq=1 ttl=64 time=0.072 ms
64 bytes from 10.0.0.101: icmp_seq=2 ttl=64 time=0.037 ms
64 bytes from 10.0.0.101: icmp_seq=3 ttl=64 time=0.055 ms
--- 10.0.0.101 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.037/0.055/0.072/0.000 ms
In the meantime, I was stubborn to find a solution to what I need in order to progress and MACVLAN tech actually delivered it (private mode enough), something newer than VETH tech what I could read about, and it's just perfect avoiding bridge itself. So no problem to cooperate on this fix, I will be glad, just it can get lower priority on your side if you even attributed it some 😊
Thanks, wishing successful new week.
Peter
-----Original Message-----
From: Daniel Gröber <dxld@darkboxed.org>
Sent: sobota 11. novembra 2023 1:35
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
Hi Peter,
looking at the ip/bridge dumps I don't see anything obviously broken so I started by building a reproducer using two netns'en and a bridge on the host to simulate your setup, leaving out the vlan stuff for now.
I setup two namespaces ns0/ns1 with a veth pair each connected to br0 on the host. I assign MAC addresses statically to make looking at `bridge fdb` easier (grep ^aa:). The script looks like this (trimmed, full version
attached):
ip netns add ns0
ip link add veth0 type veth \
peer name veth0 address aa:00:00:00:00:00 netns ns0
ip netns add ns1
ip link add veth1 type veth \
peer name veth1 address aa:00:00:00:00:01 netns ns1
ip link add br0 address aa:bb:bb:bb:bb:bb type bridge forward_delay 0
#^ forward_delay=0 to disable STP as this delays interfaces coming up
ip link set dev veth0 master br0
ip link set dev veth1 master br0
ip -n ns0 addr add 10.0.0.100/24 dev veth0
ip -n ns1 addr add 10.0.0.101/24 dev veth1
ip link set br0 up
ip link set dev veth0 up
ip -n ns0 link set dev veth0 up
ip link set dev veth1 up
ip -n ns1 link set dev veth1 up
ip -n ns0 link set dev lo up
ip -n ns1 link set dev lo up
ip netns exec ns0 ping -c4 10.0.0.101
Seems to work fine. So we can establish the basic functionality does work and we need to go deeper.
Peter, can you confirm this script works on your system? If so the next step is introducing vlans.
On Mon, Oct 30, 2023 at 07:25:38PM +0000, peter.gasparovic@orange.com wrote:
> 1) As was reported, foreign external world MAC@ does not pass into
> network namespace, just external border point "vlan199"
How did you check this?
> 2) now collecting data for you, honestly I don’t see external mac
> address on "inet-br" object, so my previous statement was incorrect..
> {ossibly I might mixed this up with another "labinet-br" (working in
> its limited
> scope) which is IP-defined, while "inet-br" in question is not.
>
> 3) so question is, if the MACs learnt via vlan199 are supposed to be
> paired (displayed) with "inet-br" object and all way up into NS....
I want to make sure we're on the same page, how do you check if the MAC is reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump this will tell you whether ARP is even reaching the NS or not.
Something simple like
$ tcpdump -enli $IFACE 'arp or icmp'
optionally you can filter by MAC (`ether host` in pcap-filter speak):
$ tcpdump -enli $IFACE ('arp or icmp) and ether host aa:00:00:00:00:01
Oh and one last thing: please double and tripple check that a firewall isn't interfering.
--Daniel
____________________________________________________________________________________________________________
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: