Hi Daniel, hope you are good, had peaceful Christmas time, entering yet better NY 2024 hope so... sorry for overlooking this, even wanted to respond early December, then got delayed again.. Now I do so as its still interesting to me!
1) yes, my sole quick method was "ip nei" command to confirm the ARP passthrough 2) no firewall at all, plain Debian installation 3) you will not believe --> but before Xmas and now, it all works and MAC is passed e2e. That's so pitty. Only change I made was my underlay change of vSwitch uplink to another port... because I re-considered my overall lab setup, yet it hardly could improve this as the external MAC made it to external (VLAN) iface of the bridge, before/. Anyhow, possibly I understand the "bridge fbd" only shows learned MACs on given interface (my VLAN199) and is not supposed to attribute it to all others all way up to NS, like I attempted to guess.. Finally, either this of MACVLAN setup (where I found this), I have new finding which I don’t like as it creates a hell of duplicate traffic into network. The problem is, that either VETH or MACVLAN-configured IP host's VM duplicates incoming packets on its receiving port, connected to vSphere vSwitch, which in turn just dully floods it to uplinks, where my Wireshark sniffer sees it. This is how I discovered that. I prepared this diagram for you to see and tell. https://docs.google.com/document/d/1mNkZswDSG_OjLnsgXJvIX2tUGSEebcZf720eS29eFCA/edit?usp=sharing BR, all the best wishes in NY2024! Peter -----Original Message----- From: Daniel Gröber <d...@darkboxed.org> Sent: nedeľa 3. decembra 2023 11:09 To: GASPAROVIC Peter OBS/MKT <peter.gasparo...@orange.com> Cc: 1054...@bugs.debian.org Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Hi Peter, > So now we move to VLAN level? Yeah, but I'm still waiting for the answers to my questions from two emails ago: > I'd be happy to still track this bug down but I need you to > investigate the behaviour in your environment. If you've torn down the > lab already we can also just call it quits. > > If you do want to continue some questions are still pending, see quoted below. > > > On Mon, Oct 30, 2023 at 07:25:38PM +0000, peter.gasparo...@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.
