On Fri, Apr 19, 2013 at 08:04:01PM +0200, Art -kwaak- van Breemen wrote:
> Hi,
> On Thu, Apr 18, 2013 at 12:15:35PM +0200, Laurens Vets wrote:
>> I was wondering what the best way is to configure a private network
>> between guests. Would it be best to use a dummy device on the host
>> or just an alias on the loopback interface in the guests?
> I think the dummy device should be banned.
> Nobody seems to really understand it.
while I personally agree, I found that the dummy device
has the ability to help folks to 'get it working' without
really understanding the underlying principles.
the danger lies in the almost mythical interpretations
most folks come up with about 'how this works' :)
one thing usually overlooked with the dummy devices is
the fact that _any_ packet sent to a dummy device will
be simply discarded and no packet will ever be received
from a dummy device either ... which doesn't really
matter for the Linux-VServer setup, as all local traffic
passes through the lo device anyways, and the dummy
device is merely a placeholder to bind the IP to.
as the routing part for local IPs is done automagically,
this only comes up when somebody tries to tie iptable
(or firewalling) rules to the dummy device (which of
course have no effect, as there is no traffic through
dummyX)
I'll also add some comments to the 'rules' below :)
> if !( use network namespace) {
> There is a single IP stack.
but there are multiple routing tables with rules
> Every ip on every interface, it doesn't matter. One stack!
except for lo, which has special handling on linux
> Communications between those ip's are *always* local.
communication on the host, between host and guest or
between guests (in a non network namespace setup)
> An ip with a mask on an interface is only put there for
> routing and arp purposes.
> There are 2 exceptions to this rule:
> 1a) 127.0.0.0/8 has a special filtering in vanilla linux
> that can be turned off. If turned off, you can use
> 127.0.0.0/8 on every interface as normal routable
> ip addresses.
> 1b) 127.0.0.0/8 has a special filtering in vserver linux
> with a network context (That's about 99.999999999% of
> those that read this). If I am correct, under water
> it will be rewritten to 127.<networkcontextid>.1,
> which means the localhost of that vserver.
only if the proper network context flags are set
(LBACK_REMAP, HIDE_LBACK), but they are on by
default, so yes, that and CONFIG_AUTO_LBACK is
doing that for 99.999999% of all recent setups.
> 2) network masks used on lo means you bind to *all*
> addresses in that network. 127.0.0.0/8 means you can
> use 127.0.0.0 to 127.255.255.255 . 192.168.1.15/24
> on lo means that you own every ip address from
> 192.168.1.0 to 192.168.1.255 .
while lo handles network assignments special, it
also handles addresses in general special in such
way that they are normally not reachable from the
outside (i.e. always local)
> That's an easy way to kill a network, because you
> will have all those addresses, and hence will respond
> to arp requests for all those addresses.
unlikely IMHO (packets to the host will become
martians, routing doesn't allow for arp replies),
but the host will answer to all of those IPs for
local traffic, which usually isn't what you want.
> IPv6 is almost the same, except for arp (neighbour discovery).
> Because the neigbour discovery in IPv6 works differently, you
> can not put an ipv6 address on lo, and expect everything to
> work.
> Your host will not respond to discovery. For that you need
> to add a ipv6 proxy entry for that address on the correct
> interface. Or you just add that ip address to that interface
> with the right mask.
> }
> If you use network namespaces, all this applies *per*
> namespace. Each namespace is a seperate ip stack following
> the same rules.
> Hmmm:
> http://www.paul.sladen.org/vserver/archives/201009/0109.html
> Same answer: you don't need another interface.
> But remember: that "network" will not be private.
> It will be accessible by any interface on the server.
again, depends on the configuration, for example
rp_filter and routing tables can easily prevent
certain interfaces from advertising certain IPs
and of course, from responding to any packets.
best,
Herbert
Received on Sun Apr 21 21:03:16 2013