Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #84458

Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Hello Peter,

On Wed, Jan 03, 2024 at 10:21:21PM +0000, peter.gasparovic@orange.com wrote:
> 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

I have problems understanding your mail. Under 3) you write "it all
works" but then there are still some issues about duplicate traffic
(which isn't the original problem?).

Can you please clearify if there is still something to do/fix?

Best regards
Uwe

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Luca Boccassi <bluca@debian.org> - 2023-10-27 11:30 +0200
  Processed: Re: Bug#1054642: Failing ARP relay from external ->  Linux bridge -> veth port --> NS veth port "Debian Bug Tracking System" <owner@bugs.debian.org> - 2023-10-27 11:30 +0200
  Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Daniel Gröber <dxld@darkboxed.org> - 2023-10-29 11:50 +0100
    Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Daniel Gröber <dxld@darkboxed.org> - 2023-10-30 13:10 +0100
      Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Daniel Gröber <dxld@darkboxed.org> - 2023-11-11 01:40 +0100
        Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Daniel Gröber <dxld@darkboxed.org> - 2023-11-18 03:50 +0100
          Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Daniel Gröber <dxld@darkboxed.org> - 2023-12-03 11:20 +0100
            Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Uwe Kleine-König <ukleinek@debian.org> - 2024-11-06 22:00 +0100
              Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Bastian Blank <waldi@debian.org> - 2025-03-25 09:10 +0100
                Bug#1054642: RE: Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Ben Hutchings <ben@decadent.org.uk> - 2025-03-26 19:30 +0100

csiph-web