Michael H. Warfield a écrit :
On Thu, 2009-03-05 at 20:50 +0100, Benoit Branciard wrote:
the debian-add_ip.sh script available in vzctl 3.0.23 does not set up
IPv6 default route correctly for a Debian 5.0 (Lenny) container.
The reason seems to be that the default behaviour of the ifconfig
command changed from etch to lenny: when adding IPv6 addresses without
specifying a prefixlen, the prefixlen is assumed to be /128 in Lenny
instead of /0 in etch.
That doesn't make sense to me. I would think the /0 (which should be
all addresses are valid to the local subnet) would be, should be, wrong.
On a normal ethernet device yes, /0 is wrong.
On a venet device /0 is needed to force default route to be forwarded to
the host. This seems messy, but this is the way it works.
I see nothing where a /0 would be valid. I find it weird that Etch
would have been setting it up that way.
Yes, having ifconfig defaulting to /0 seems like a bug in Etch, which
has been corrected in Lenny. /128 is a far more acceptable default value
(that is, a single IP address).
But having debian-add_ip.sh NOT specifying the REQUIRED /0 (in venet
context), and relying on a buggy default value, is another bug.
The patch below corrects the problem by explicitely specifying the
prefixlen, and works for both Etch and Lenny containers.
That patch is on the vnet devices. If this is proper behavior in the
vnet devices, that's just more evidence to me that the vnet devices are
broken vis-a-vis IPv6.
It works for me.
Without mac addresses and not supporting
stateless autoconf and neighbor discovery and router advertisements,
venet does not need router advertisements. It just needs an IPv6 address
which is explicitely configured by the host administrator, and do not
support stateless autoconf by design.
If anything, the clients should get a correct /64 address and then
somehow get their proper default route (either static or through router
advertisements, but router advertisement doesn't work on the vnet
system). But, of course, that means the host is acting as a router with
IPv6 forwarding enabled (net.ipv6.conf.all.forwarding = 1) which use to
then interfere with default routing, but doesn't seem to anymore (that
behavior may have been altered to correct non-compliance with test
suites - I haven't played with that aspect in years). Is that why
this /0 kludge? To avoid having to put the host in IPv6 forwarding mode
and just fake out IPv6 forwarding in the vnet module?
venet needs net.ipv6.conf.all.forwarding = 1 on the host to support IPv6
properly.
That would just
be more non-standard behavior. Where do you get your /64 from? Is it
local to that host and hard coded? How do other hosts know to route to
it then. Is it the local /64 you are sitting on (a semi bridging mode?)
how would neighbor discovery then work? How are the scopes and
multicast suppose to work when you do this with a /0?
I believe venet does not support multicast and other fancy things. There
must be some practical reasons for veth to exist :-)
I agree that when I came to OpenVZ, I found network management to be
quite messy. But venet devices were found to be quite useable for the
vast majority of containers hosting classical unicast services. Provided
this patch is applied when it comes to lenny :-)
--- debian-add_ip.sh.0 2009-03-05 18:57:40.000000000 +0100
+++ debian-add_ip.sh 2009-03-05 19:02:43.000000000 +0100
@@ -87,8 +87,8 @@
printf "
auto ${VENET_DEV}:${ifnum}
iface ${VENET_DEV}:${ifnum} inet6 manual
- up ifconfig ${VENET_DEV}:${ifnum} add ${ip}
- down ifconfig ${VENET_DEV}:${ifnum} del ${ip}
+ up ifconfig ${VENET_DEV}:${ifnum} add ${ip}/0
+ down ifconfig ${VENET_DEV}:${ifnum} del ${ip}/0
" >> ${CFGFILE}.bak
fi
Mike
------------------------------------------------------------------------
_______________________________________________
Users mailing list
[email protected]
https://openvz.org/mailman/listinfo/users
--
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.
_______________________________________________
Users mailing list
[email protected]
https://openvz.org/mailman/listinfo/users
