I have a Debian based Linux installation, that gets around:

It started out on a physical system, then I moved the OS into a VMware container and then into a Xen container. As physical and VMware installation this /etc/network/interfaces worked:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet6 auto
    privext 0
    post-up ip a a fe80::1337/64 dev eth0
    post-up ip a a fc0e::1337/64 dev eth0

Where working means eth0 is up and has all addresses/subnets configured on eth0 and privacy extensions are disabled.

When run as Xen VM, privacy extentions are enabled (/proc/sys/net/ipv6/conf/eth0/use_tempaddr is 2), eth0 is up, but it has only its link local fe80::/64 address. I can log into the VM and manually do

    ip a a fe80::1337/64 dev eth0
    ip a a fc0e::1337/64 dev eth0

, which works without any problems. I can reach this machine using these manually assigned addresses just as one would expect ... and as it used to work when the OS was a physical machine or a VMware VM.

So what is different about a (pv) Xen guest, that this doesn't work? In the log files there are two very suspicious entries:

syslog:Oct 31 10:41:48 hostname kernel: [    6.926601] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
syslog:Oct 31 10:41:48 hostname kernel: [    9.842540] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Suspicious, because they occur at the same wall clock time. I tried creating the VM but leaving it paused, so that the Open vSwitch has time to its thing, before the VM fully powers up. But that doesn't remedy the situation.

I also tried adding post-up sleep 5 and pre-up sleep 5 to help with timing issues ... yet its still a VM ...

It looks like a timing issue to me. How can I fix this?

1 Answer 1


You said the interface is up, but is it up as far as ip link is concerned or as far as ifup is concerned? A failure of the post-up commands would mean the latter. To debug why IPv6 ND isn't working, you have to run something like a packet tracer (tcpdump, tshark, ...) and see if you're getting router advertisements. If you are, verify that /proc/sys/net/ipv6/{default,eth0}/accept_ra is turned on. See http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6..html for more details.

  • I am sorry, I do not understand your answer. When I log into the machine ip link show reports the interfaces as up.
    – Bananguin
    Mar 5, 2015 at 8:02
  • If you run ifup -v eth0 after boot, does it just say it's already up, or does it do something else? Mar 5, 2015 at 19:22
  • It says already up.
    – Bananguin
    Mar 6, 2015 at 9:32
  • OK, so that means the post-up commands did not fail. So if at some point they succeeded, yet when you logged in the addresses were not there, that sounds like the autoconfiguration was still in progress, but ultimately decided that there's nothing to autoconfigure, and dropped all addresses from the interface. Try e.g. attaching a tshark session in pre-up, and have it write its output to a file, and then examine that file as soon as you can log in. Mar 9, 2015 at 12:08
  • I can't I don't have access to the setup anymore. I needed a solution 2 months ago. What would you expect to see in and read from that tshark dump? Notice that this must be a Xen domU specific issue.
    – Bananguin
    Mar 12, 2015 at 12:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .