lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+HUmGhYzSE-ruiOfQa9UCKcMuN361asxwCD=Nmdjar9jC0bTA@mail.gmail.com>
Date:   Sat, 2 Nov 2019 15:08:19 -0700
From:   Francesco Ruggeri <fruggeri@...sta.com>
To:     David Ahern <dsahern@...il.com>
Cc:     David Miller <davem@...emloft.net>, shuah@...nel.org,
        netdev <netdev@...r.kernel.org>, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] selftest: net: add icmp reply address test

> > > I apologize in advance  for being slow ...
> > > I have 3 namespaces that have to share the same LAN, I am not trying
> > > 1-1 connections among those namespaces.
> > >
> >
> > How would you cable this if it were an actual network with physical nodes?
> > - bridge on R1 (since it is the gw for H1), with connections to R2 and
> > H1 into the bridge
> > - second connection between R1 and R2
> > - connection between R2 and H2
> >
> > For the simulation, network namespaces represent physical nodes, veth
> > pairs act like a cable between the nodes / namespaces and the bridge
> > makes the LAN.

Thanks, I see what you mean now.
I was assuming a different physical model, with all the namespaces on the LAN
connected to a hub (simulated by the dummy device). For simulation purposes this
model seem simpler: there are N interfaces instead of N pairs, and one does not
have to deal with the bridge end of the pairs.
Why is the model you described preferable?

Thanks,
Francesco

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ