Subject: Re: [vserver] VServer and Multicasting
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 14 Jan 2011 17:47:57 +0100

On Fri, Jan 14, 2011 at 03:05:37PM +0100, Furgerot Julien wrote:
> First of all, thank you for your helpful responses,

> I have resolved the multicast problem by declaring all the multicast
> addresses thanks to Eric's hint.

> However, I still have problems related to sockets. Recall, that all
> my guests are running the same software. This software contains some
> components that uses socket bound to 0.0.0.0 (all interfaces). Thus,
> when running the VMs, only the first turret uses this socket and the
> other guests are not able to use the already used socket.

services binding to 0.0.0.0 inside a Linux-VServer guest
will be automagically limited to the assigned IP addresses,
which in turn means, if you assign different IP addresses 
to different guests, they will live happily side by side
even if the services inside the guests bind to 0.0.0.0

> To overcome this problem, we have thought to two solutions :

> - The first solution consists on to review the software so that to
> make it sure to bind to the allocated IP address on a given physical
> interface. The problem with this solution is that we will be obliged
> to modify the software code.

note that binding multicast IP addresses should not create
collisions as long as they are used to receive ...

> - In the second solution, we are thinking if there is some solution
> that allows us to virtualise the network so that to isolate the
> physical interfaces between the guests, virtual interfaces, etc. in
> VServer.

this is called network namespaces, part of recent mainline
kernels (therefore present in recent Linux-VServer kernels
as well), adds overhead, needs manual setup for now, but
AFAIK, works as intended.

HTH,
Herbert

> What do you think ?

> Thank you for your answers,
> Regards,

> -- Julien
> 
> On Tue, Jan 11, 2011 at 10:08 PM, Herbert Poetzl <herbert@13thfloor.at>wrote:
> 
> > On Tue, Jan 11, 2011 at 09:58:34AM +0100, Benedikt Böhm wrote:
> > > On Mon, Jan 10, 2011 at 6:04 PM, Eric Schoeller
> > > <eschoeller@users.sourceforge.net> wrote:
> > > > Someone else will probably come up with a cleaner solution though :)
> >
> > > the following patch should make it work out-of-the-box:
> >
> > but it will also disable all checks for multicast addresses
> > inside the guest ... JFYI
> >
> > best,
> > Herbert
> >
> > > --- a/include/linux/vs_inet.h    2010-09-02 14:29:18.000000000 +0200
> > > +++ b/include/linux/vs_inet.h    2010-10-14 10:03:54.879553071 +0200
> > > @@ -244,7 +244,7 @@
> > >                 } else if (saddr == IPI_LOOPBACK) {
> > >                         if (nx_info_flags(nxi, NXF_LBACK_REMAP, 0))
> > >                                 baddr = nxi->v4_lback.s_addr;
> > > -               } else {        /* normal address bind */
> > > +               } else if (!ipv4_is_multicast(saddr)) { /* normal
> > > address bind */
> > >                         if (!v4_addr_in_nx_info(nxi, saddr,
> > NXA_MASK_BIND))
> > >                                 return -EADDRNOTAVAIL;
> > >                 }
> >