[Users] 2.6.18-ovz028test015 and 2.6.18-ovz028test018 break IPv6
Kirill Korotaev
dev at sw.ru
Mon Mar 5 03:38:27 EST 2007
Michael,
Can you please check that the patch from bug
http://bugzilla.openvz.org/show_bug.cgi?id=476
helps you?
Thanks,
Kirill
> Hello,
>
> Introduction... I've been on the users list for a while and just
> joined the developers list. Excuse the cross post but I'm not sure
> which would be most appropriate.
>
> I work extensively with IPv6. All of my devices are configured for
> IPv6 and I actively participate in the global IPv6 network and have for
> over 5 years. I'm a member of the North American v6 Task Force,
> NAv6TF.org. My name servers, ntp servers, smtp servers, and web servers
> all show active IPv6 traffic and have for years. I'm also a big user of
> VMware and I'm also the author of an IPv6 paper that's up on their site
> somewhere.
>
> So, I'll prefix this with a bit of a rant.
>
> <Rant>
>
> I don't use venet. The way it's implemented, especially vis-a-vis
> IPv6, it makes no sense to me at all. the venet0 devices have no
> hardware / mac layer addresses so how is IPv6 neighbor discovery and
> autoconfiguration protocols suppose to work? These are really
> fundamental to the nature of IPv6 and, unless you want to use IPv6
> purely like it just IPv4 with fat addresses (which it is NOT) and live
> entirely in an IPv4 mind-think cocoon when working with IPv6, how can
> you expect this to work with fully implemented IPv6?
>
> The bridged networking of the veth devices seem to be the only viable
> way to deal with this. I HAVE tried using venet for IPv6 and failed
> miserably.
>
> This is also how I deal with IPv6 on VMware. I never use the local
> networking (host local or NAT) devices and only use the bridged devices
> there. In the case of VMware, the bridged devices are the default and
> you can add the routed or nat'ed devices. That makes a lot more sense
> to me.
>
> So IPv6 HAS to work for me. Consequently, I have to work with
> everything running over the veth devices. The venet devices just do not
> cut it at all with IPv6, so are totally useless to me for both IPv4 as
> well as IPv6 (why split the network two ways).
>
> Funny thing is, if you "turn on" IPv6 in the vz configuration files, it
> dicks things up royally by trying to force IPv6 routes out through the
> venet0 interface, which can't work, and interferes with stateless
> autoconfiguration and router discovery configuration. Leaving IPv6 off
> in the config, then it doesn't insert bogus routes and everything
> configures properly on the veth devices and IPv6 works like a charm.
> Interestingly enough, the veth devices DO get their proper link-local
> and global-unicast addresses while vnet0 sits there with not even a
> link-local address (of course - it has no mac address so how could it
> possibly have a link-local address - duh...).
>
> </Rant>
>
> Now... Onto the problem. IPv6 is working sweet with
> 2.6.18-ovz028test010 on Fedora Core 6. It would be nice to get it up to
> the FC6 2.6.19 (soon to be the 2.6.20) rebase but that's ok for now.
> When I tried 2.6.18-ovz028test015 and subsequently 2.6.18-ovz028test018,
> I found that IPv6 was totally broken. While all my interfaces properly
> autoconfigure on test10, stateless autoconf appears to be totally broken
> on test15 and test18 and even manual configuration doesn't work (hints
> strongly at broken neighbor discovery there).
>
> This may not be an OpenVZ problem, per se, though. Some time in the
> very later part of the 2.6.18 kernel.org release updates, a problem was
> introduced that broke IPv6. Some patch or another caused nodes to fail
> to join the "all nodes multicast" (ff02::1) address. This is critical
> to IPv6 router discovery and advertisement, neighbor discovery, and
> autoconfiguration. All fall down go boom.
>
> This actually wasn't "discovered" until 2.6.19 but it seems to have
> been introduced in a couple of late clicks of 2.6.18 and is not fixed in
> the kernel.org tree until 2.6.20-rc5 or so. Fedora Core seems to have
> retrofitted the fix into the last couple of clicks of the FC6 2.6.19
> (currently 2.6.19-2911) but the stock kernel.org kernels have been
> broken in a couple of 2.6.18 releases and, AFAICT, all of the 2.6.19
> releases.
>
> This is re-enforced by checking the group memberships on test010 vs
> test018 in both host and guest (netstat -g).
>
> Host test010:
>
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> lo 1 ff02::1
> eth0 1 ff02::fb
> eth0 1 ff02::1:ff10:f84d
> eth0 1 ff02::1
> veth0 1 ff02::fb
> veth0 2 ff02::1:ff10:f84d
> veth0 1 ff02::1
> veth1 1 ff02::fb
> veth1 1 ff02::1:ff3a:e3e2
> veth1 1 ff02::1
> veth1006.0 1 ff02::fb
> veth1006.0 1 ff02::1:ff01:6
> veth1006.0 1 ff02::1
> veth1010.1 1 ff02::fb
> veth1010.1 1 ff02::1:ff01:100a
> veth1010.1 1 ff02::1
> veth1026.0 1 ff02::fb
> veth1026.0 1 ff02::1:ff01:1a
> veth1026.0 1 ff02::1
>
> Host test018:
>
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> eth0 1 ff02::fb
> eth0 1 ff02::1:ff10:f84d
> veth0 1 ff02::fb
> veth0 1 ff02::1:ff10:f84d
> veth1 1 ff02::fb
> veth1 1 ff02::1:ff3a:e3e2
> veth1006.0 1 ff02::fb
> veth1006.0 1 ff02::1:ff01:6
> veth1010.1 1 ff02::fb
> veth1010.1 1 ff02::1:ff01:100a
>
> Yeah, that would be a problem and is the symptoms reported on lkml.
>
> Here's one of the guest systems (1006 above):
>
> Guest 1006 test010:
>
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> lo 1 ff02::1
> eth0 2 ff02::1:ff01:106
> eth0 1 ff02::1
> eth1 1 ff02::1:ff01:1106
> eth1 1 ff02::1
>
> Guest 1006 test018:
>
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> eth0 1 ff02::1:ff01:106
> eth1 1 ff02::1:ff01:1106
>
> Same problem. Missing the ff02::1 address on every interface. Bad
> juju.
>
> I suspect that test15 and test18 picked up the bad IPv6 patch and broke
> IPv6. We need a rebase to a working kernel or a retrofit of the patch
> from 2.6.20. I have not been able to get the oz patch to patch into the
> 2.6.19 FC6 kernels, but that would be a good place to start since they
> are no have IPv6 working. You might examine those retrofit patches.
> Better yet would be to rebase the test series up to 2.6.20.
>
> Mike
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://openvz.org/mailman/listinfo/users
More information about the Users
mailing list