NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: vioif(4) ipv6 issues?

Staffan Thomén wrote:
Greg Troxel wrote:
Jeff Rizzo<> writes:

I just noticed that a host of mine running as a Xen guest is not
getting (or maybe just sending) ipv6 packets correctly. It's running
pretty much the same as some physical hosts, and the only difference I
can see is the Xen (and vioif) aspect.

Are you using a bridge for xvifN.0 on the dom0?

Try using ping6 to the link-local (fe80::) addresses. Remember to use
%ifname as it appears in ifconfig (other end's address, your ifname).

Try running tcpdump in promiscuous mode on both ends. That can hide
some mcast programming/filtering bugs to help diagnosis.

First, ping the ll address of the xvif from the domU, and vice versa.

The tone I imagined in your email seems to suggest that you know why
this is happening.

I am seeing this exact problem on my Xen setup, it's a NetBSD 7.1 dom0
with 7.1 domU:s using xvif linked to the real wm with a bridge. The
domUs sometimes become completely unresponsive on ipv6, but then
recover. ipv4 seems completely unaffected.

Sometimes the dom0 is also unresponsive on v6.

It seems to happen as the domUs are idle, with little to no traffic,
because one of the VMs host my (v6) irc session and it has stayed up for
30+ days.

Following up on my own mail here, sorry.

I did some investigation and noticed that listing the entries in NDP on my v6 gateway showed the nonresponsive (xen domU) hosts as having expired. This would explain the unresponsiveness.

Next I dumped the traffic going through the dom0's interface, and saw the gateway querying ff02::<eui64> of the expired hosts repeatedly but not getting a reply (this seems like a fallback broadcast).

So I looked a little closer, and my domU:s were using dhcpcd to handle ipv6, so I put 'ipv4only' in dhcpcd.conf, set net.inet6.ip6.accept_rtadv to 1 in sysctl, enabled rtsold and restarted networking. Voila, the problem went away completely.

I'm guessing this is a bug in dhcpcd and that it doesn't reply to neighbour solicitation queries properly when there's a transparent hop like bridge(4) in the network. The expire times seem to become very short (looks like 60 seconds) where hosts directly connected get 24 hours.

Maybe this can help the OP.


Home | Main Index | Thread Index | Old Index