Bug 243526

What is the status of this bug?

Links to other bugs:

http://bugs.centos.org/view.php?id=2639
http://bugzilla.kernel.org/show_bug.cgi?id=8349

And the patch that fixes this:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=7ebba6d14f8d63cad583bf1cc0330b601d5a8171

Created attachment 293338 [details]
upstream Linux changeset: [IPV6] ROUTE: No longer handle ::/0 specially

Bug is still in RHEL 5.1.

kernel-2.6.18-53.1.6.el5PAE

Example of how to workaround this bug by creating a static route to 2000::/3
that is persistent across network restarts and reboots:

/etc/sysconfig/static-routes-ipv6:

  eth0    2000::/3                               3ffe:ffff:0:1::1

I have a setup where one of the machines acts as a router with IPv6 forwarding 
enabled. This machine has two nics and they have ips
       nic1 ip = 2001:4038:0:100::1/64 ( vlan 1 )
       nic2 ip = 2000:4038:0:100::1/64 ( vlan 2 )and are on two different 
subnets ( i have two vlans on the switch ).

I have connected a machine say machine-1 with ip 2001:4038:0:100::25/64 to 
vlan 1. It's /etc/sysconfig/network looks like

         NETWORKING=yes
         NETWORKING_IPV6=yes
         IPV6_DEFAULTGW=2001:4038:0:100::1
         HOSTNAME=localhost.localdomain

The other machine say machine-2 has ip 2000:4038:0:100::25/64 and is connected 
to vlan 2.

ip -6 route on machine-1 looks like this :

unreachable ::/96 dev lo  metric 1024  expires 21332077sec error -101 mtu 
16436 advmss 16376 hoplimit 4294967295
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  expires 21332077sec error -
101 mtu 16436 advmss 16376 hoplimit 4294967295
2001:4038:0:100::/64 dev eth0  metric 256  expires 21332077sec mtu 1500 advmss 
1440 hoplimit 4294967295
unreachable 2002:a00::/24 dev lo  metric 1024  expires 21332077sec error -101 
mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:7f00::/24 dev lo  metric 1024  expires 21332077sec error -101 
mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:a9fe::/32 dev lo  metric 1024  expires 21332077sec error -101 
mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:ac10::/28 dev lo  metric 1024  expires 21332077sec error -101 
mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:c0a8::/32 dev lo  metric 1024  expires 21332077sec error -101 
mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 2002:e000::/19 dev lo  metric 1024  expires 21332077sec error -101 
mtu 16436 advmss 16376 hoplimit 4294967295
unreachable 3ffe:ffff::/32 dev lo  metric 1024  expires 21332077sec error -101 
mtu 16436 advmss 16376 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  expires 21332075sec mtu 1500 advmss 1440 
hoplimit 4294967295
default via 2001:4038:0:100::1 dev eth0  metric 1  expires 21332077sec mtu 
1500 advmss 1440 hoplimit 4294967295

and i can ping from machine-1 to machine-2 using ip's. I don't have a dns 
server. ping6  2000:4038:0:100::25 looks like 

PING 2000:4038:0:100::25(2000:4038:0:100::25) 56 data bytes
64 bytes from 2000:4038:0:100::25: icmp_seq=0 ttl=63 time=3.69 ms
64 bytes from 2000:4038:0:100::25: icmp_seq=1 ttl=63 time=0.202 ms
64 bytes from 2000:4038:0:100::25: icmp_seq=2 ttl=63 time=0.187 ms
64 bytes from 2000:4038:0:100::25: icmp_seq=3 ttl=63 time=0.240 ms
64 bytes from 2000:4038:0:100::25: icmp_seq=4 ttl=63 time=0.189 ms
64 bytes from 2000:4038:0:100::25: icmp_seq=5 ttl=63 time=0.216 ms
64 bytes from 2000:4038:0:100::25: icmp_seq=6 ttl=63 time=0.187 ms
64 bytes from 2000:4038:0:100::25: icmp_seq=7 ttl=63 time=0.201 ms

I see a "connect: Network is unreachable" only when i have commented 
IPV6_DEFAULTGW in machine-1.

It would be helpful if you can share configuration details of your setup for 
me to reproduce the issue.

The traceroute output for the setup mentioned in comment #6 looks like this: 
 
traceroute to 2000:4038:0:100::25 (2000:4038:0:100::25), 30 hops max, 40 byte 
packets
 1   (2001:4038:0:100::1)  0.220 ms  0.156 ms  0.124 ms
 2   (2000:4038:0:100::25)  0.235 ms  0.223 ms  0.197 ms

The machine where this problem occured has been replaced. It was an IPv6 router
between two subnets, and has been replaced with a 'real' router. Other IPv6
client machines don't have this problem anymore.

Since the problem only occured on our router, I suspect that the problem is
related to one or more of the following settings:
  IPV6_ROUTER
  IPV6_AUTOCONF
  IPV6FORWARDING

I am sorry I can't give any more details at this time. If you need me to perform
more tests, please let me know and I will schedule them.

I enabled IPv6 forwarding on the machine that acted as a router by adding a 
line which looks like "net.ipv6.conf.all.forwarding=1" to /etc/sysctl.conf and 
executing sysctl -e -p /etc/sysctl.conf to dynamically enable forwarding. This 
might be useful.

First of all, let me emphasize that I'm neither a RHEL nor a CentOS user myself.
I hit this bug when it was introduced into 2.6.21-stable vanilla kernel series
and had several encounters with it later on, both with a customer running CentOS
and several people running RHEL or CentOS in #ipv6 on Freenode.

The bug itself is legit, it is in the kernel bugzille (
http://bugzilla.kernel.org/show_bug.cgi?id=8349 ), it has been tracked,
discussed and fixed on lkml by Simon Arlott, Chris Wright and David Miller (
http://lkml.org/lkml/2007/5/28/299 ). As you can read in these documents it is
caused by 

commit f11e6659ce9058928d73ff440f9b40a818d628ab
Author: David S. Miller <davem.net>
Date:   Sat Mar 24 20:36:25 2007 -0700
    [IPV6]: Fix routing round-robin locking.

during the 2.6.22 release cycle from where it was backported to 2.6.20-stable
and 2.6.21-stable. During this process it must have been picked up by RHEL
maintainers and integrated into the RHEL kernel sources (this patch is
integrated in http://centos.bio.lmu.de/5.1/os/SRPMS/kernel-2.6.18-53.el5.src.rpm
by the name "linux-2.6-ipv6-fix-routing-regression.patch").

As one can read on lkml this causes issues with manual defaultroutes. Apparently
not always, I've had cases where it just worked and cases where it didn't as
well. The proper fix, as visible on lkml as well, is

commit b407fdbabb6c630660e1e9c9c2d212a03b746775
Author: YOSHIFUJI Hideaki <yoshfuji>
Date:   Wed Jun 6 22:42:58 2007 -0700

    [PATCH] IPV6 ROUTE: No longer handle ::/0 specially.

I'm currently installing CentOS in VMware, but since this is a known bug we need
someone from RH to finally wake up and import the fix (for the "fix") into the
kernel sources as well.

DaveM, as you were involved in the patches that invoked and fixed this problem
in mainline, can you persuade your colleagues on the RHEL kernel team to apply
the fix as well?

Thanks,
Matt

Created attachment 309792 [details]
proposed patch

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

in kernel-2.6.18-98.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Partners, this bug should be fixed in the latest RHEL 5.3 Snapshot. We believe that you have some interest in its correct functionality, so we're making a friendly request to send us some testing feedback. 

If you have a chance to test it, please share with us your findings. If you have successfully VERIFIED the fix, please add PartnerVerified to the Bugzilla keywords, along with a description of the results. Thanks!

Hi,

the kernel 2.6.18-120.x86_64 from RHEL5.3beta fixed this bug for me. 

I now can use aiccu from sixxs, without the the static route for 2000::/3 and only the default route.

I'm not a official Partner, but longtime Trainer for RedHat and RHCA#8 
If that is helping :-)

Greeting 
Jens

Works! Thanks Jens. Appreciate the support. Added CustomerVerified keyword.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-0225.html