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