[Lxc-users] [lxc-devel] Request for inclusion into mainline LXC utils

Michael H. Warfield mhw at WittsEnd.com
Mon Jan 25 13:50:15 UTC 2010

On Mon, 2010-01-25 at 01:01 -0500, Michael H. Warfield wrote:

: - Snip...


> [root at alcove ~]# cat /proc/sys/net/ipv6/conf/all/accept_ra
> 1

> root at ubuntu:~# cat /proc/sys/net/ipv6/conf/all/accept_ra
> 0

> That's what was killing me and blocking autoconf in Debian.  I set that
> to 1 for all and for eth0 and it all magically starts working.

> Leaves unresolved why this is required in the Debian containers and NOT
> in the Fedora containers but someone else can worry about that while I
> integrate this into my container "hacks".

> This is what I had to add to the container /etc/sysctl.conf to make this
> all work:

> net.ipv6.conf.all.forwarding=0
> net.ipv6.conf.all.accept_ra=1
> net.ipv6.conf.default.accept_ra=1
> net.ipv6.conf.eth0.accept_ra=1

> Had to add all of them.  Leave any one of them out and it fails (which
> probably means, if there is an eth1 or eth2, they need to be there as
> well...  Gag...)

> Which begs a question (not "begs the question" which is a logical
> conundrum of a different sort)...  WHY is this necessary in Debian
> containers and not at all in Fedora containers?

And found the answer to this one too and it raises a serious (to me)
issue for the lxc developers...

The problem is rooted in the differences between network setup between
Debian and Fedora / RedHat et al.  The later initializes the IPv6
subsystem based on the excellent and comprehensive IPv6 init scripts by 
Peter Bieringer and company.  Debian basically does nothing, which is OK
but somewhat suboptimal (doesn't set up local routes or block private
address 6to4 routes amongst others which can cause problems if you are
not connected to a real IPv6 network) in most cases.  In the Fedora
case, if you have NETWORKING_IPV6=yes and IPV6FORWARDING=no, it simply
does the right thing and sets those up properly, even though it's
somewhat redundant in that it's explicitly setting some values to their
default values.  In the Debian case, it depends on those values
defaulting to a reasonable host leaf node, as if it were not a router,
and expects you to manually set it correctly if it is a router.  That is
very true in most cases.  It's not true in this case.  It's a corner
case of running a virtualized leaf node on a host system that is acting
as an IPv6 router, which shouldn't be that common.  The Debian container
is booting up with sysctl values which are not normally default for a
real, non-virtualized, system.

It means that a Debian container will behave differently if it is
migrated between hosts which are and are not routers.  That's where the
question comes for the lxc developers.  Should it?  Or should LXC have
something in it to set these sysctl values or configure these sysctl
values back to reasonable defaults so it behaves the same?  Apparently,
the container virtualization is working properly and we can change them
in the containers.  Should there be something in the lxc configurations
for setting sysctl values as part of the lxc container initialization?

Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20100125/6a48cab7/attachment.pgp>

More information about the lxc-users mailing list