IPv6 On CentOS 6

Home » CentOS » IPv6 On CentOS 6
CentOS 14 Comments

We’ve been running ipv6 for a year or so now, but some of our newer instances (all on an ESX cluster) are not working. It looks like it’s all of our CentOS 6 instances. I’m hoping someone can point me in the right direction…

tshark indicates that it’s neighbor discovery that’s failing:

[26] # cat ../network NETWORKING=yes HOSTNAME

14 thoughts on - IPv6 On CentOS 6

  • Not sure where you get that from. Instead try adding
    IPV6_DEFAULTDEV=eth0
    to /etc/sysconfig/network

    FWIW you can see the current routing table with “ip -6 route”.

  • That’s not something normally in our configs, I think it was in the default config the CentOS 6 installer created, and I only stripped out some of the excess… stuff like that I left in in case it mattered in 6
    for some reason… The config on the working CentOS 5 systems (which is what we use on the CentOS 6 systems also) is much simpler:

    [113] # cat /etc/sysconfig/network NETWORKING=yes NETWORKING_IPV6=yes HOSTNAME=ns6.peak.org GATEWAY 7.55.16.1
    [114] # cat /etc/sysconfig/network-scripts/ifcfg-eth0
    DEVICE=eth0
    BOOTPROTO=static BROADCAST 7.55.19.255
    IPADDR 7.55.16.53
    NETMASK%5.255.252.0
    ONBOOT=yes TYPE=Ethernet

    IPV6INIT=yes IPV6ADDR&07:f678::56
    IPV6_DEFAULTGW&07:f678::1

    netstat is the one I usually use:

    [39] # ip -6 router Object “router” is unknown, try “ip help”.
    [40] # netstat -rn -A inet6
    Kernel IPv6 routing table Destination Next Hop
    Flags Metric Ref Use Iface
    2607:f678::/64 ::
    U 256 1 0 eth0
    fe80::/64 ::
    U 256 0 0 eth0
    ::/0 2607:f678::1
    UG 1 5 0 eth0
    ::1/128 ::
    U 0 1 1 lo
    2607:f678::16:66/128 ::
    U 0 58 1 lo fe80::250:56ff:fe98:708b/128 ::
    U 0 0 1 lo ff00::/8 ::
    U 256 0 0 eth0

  • With ipv6 in the picture stop using net-tools – they were deprecated a long time ago and there’s multiple edge cases and bugs where they don’t work properly or lack features… learn to use the iproute2 toolset – ip, ss and tc being the key ones.

    And it’s ip -6 route not ip -6 router… or ip -6 r s in short ;-)

  • Love gratuitous changes to long standard toolsets… sigh…

    You’re right, sorry, it was late on Friday ;-)

    [50] # ip -6 r unreachable ::/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376
    hoplimit 4294967295
    unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    unreachable 2002:a00::/24 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    unreachable 2002:7f00::/24 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    unreachable 2002:a9fe::/32 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    unreachable 2002:ac10::/28 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    unreachable 2002:c0a8::/32 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    unreachable 2002:e000::/19 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    2607:f678::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
    hoplimit 4294967295
    unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101 mtu 16436
    advmss 16376 hoplimit 4294967295
    fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
    hoplimit 4294967295
    default via 2607:f678::1 dev eth0 metric 1 mtu 1500 advmss 1440
    hoplimit 4294967295

    Also love quality error messages “-101” is *sooo* informative ;-)

    But the last line should be the important one and shows the proper default route in place, though the even more important one is the route to the local net (2607:f678::/64) which also looks right. It’s not a routing issue, it’s a neighbor discovery issue:

    [55] # ip neigh show
    2607:f678::1 dev eth0 FAILED
    207.55.16.1 dev eth0 lladdr 00:26:88:f2:9e:80 REACHABLE

  • It’s not a recent change and is far from gratuitous….

    http://lists.debian.org/debian-devel/2009/03/msg00780.html

    Features such as traffic shaping, policy routing and multiple IPs on an interface (not virtual interfaces) either are impossible with net-tools or just don’t work very well…

    Are you allowing ICMPv6? I don’t just mean echo and echo-reply (the pings above) but most of the rest of it too?

    IPv6 relies on ICMPv6 heavily for path MTU discovery, neighbour discovery and a whole lot more…

  • Yes, the test system has the default ip6tables, but we always permit icmp:

    # Firewall configuration written by system-config-firewall
    # Manual customization of this file is not recommended.
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    -A INPUT -p ipv6-icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
    -A INPUT -j REJECT –reject-with icmp6-adm-prohibited
    -A FORWARD -j REJECT –reject-with icmp6-adm-prohibited COMMIT

  • Hmm this is especially weird given the 5.8 systems are working –
    otherwise I’d have moved the troubleshooting up to vmware or the switch next…

    Without access to the machines/switches to traffic dump and check in wireshark you’ve got me stumped at this point I’m afraid…

  • I found another CentOS 6 system that not only is talking ipv6 properly, but the test system that can’t even talk to the router can talk to it. That indicates it’s probably something wonky with the network itself…

  • Hmm…

    I don’t have a C6 ipv6 machine but I do have a F17 which might not be too far off in behaviour…

    The general recommendation though is that next hop should always be via the local link FE80:: addresses (I notice your public address for gateway there)…

    Don’t worry about the error -101 – the actual error is the unreachable bit and just says that those networks can’t be reached over the lo device – which is understandable…

    Here’s a look at my F17 server for comparison:

    ip -6 r s
    2001:0:4137:9e76:24f8:3b1a:2598:7928 via fe80::e291:f5ff:fecc:7919 dev em1 metric 0
    cache
    2001:0:9d38:953c:2805:3e4f:484e:6234 via fe80::e291:f5ff:fecc:7919 dev em1 metric 0
    cache
    2001:0:9d38:953c:344a:332e:37f7:24f7 via fe80::e291:f5ff:fecc:7919 dev em1 metric 0
    cache
    2001:470:97df:1::/64 dev em1 proto kernel metric 256 expires 85879sec unreachable fe80::/64 dev lo proto kernel metric 256 error -101
    fe80::/64 dev em1 proto kernel metric 256
    default via fe80::e291:f5ff:fecc:7919 dev em1 proto kernel metric
    1024 expires 1305sec

    I’m using radvd on my network … but things shouldn’t be too far off for static settings…

    Is the other C6 system that *is* working on the same vmware server, bare metal or on another virtualization server?

  • Migrating one of the vms to the same physical host made them start talking to each other, so it’s definitely a vmware issue, though why it’s interacting badly with CentOS 6 is a good question. It could be a bug in vmware tools/the ethernet driver. At least it’s narrowed down now…

  • An update to close: it’s a vmware issue:

    * new CentOS 5 creations exhibit the same behavior
    * a few months ago, we migrated from an esx 4.0 cluster to a new esx 4.1
    cluster
    * we’ve just recently started using a new CentOS 6 template; the CentOS
    6 system that’s working was created before the migration
    * a fresh install on esxi 4.0.0 worked fine; when the vm was restarted on the new cluster, it exhibited the same failure. I’m hoping to get an esx 4.0 instance running to I can try the same test, as it seems that esx 4.0 vms will migrate properly and work. Failing that, we can clone the working CentOS 6 system for now until we can work with vmware to figure out what’s going on…

LEAVE A COMMENT