1

My XenServer 7.0 VMs running Ubuntu 16.04 with kernel 4.4.0 decide to cease receiving IPv6 packets shortly after restarting the whole machine or resetting the network interface.

While everything works, running tcpdump on the XenServer host reveals the following while pinging facebook.com:

[root@localhost ~]# tcpdump -i xenbr0 -vv ip6
tcpdump: listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C

[root@localhost ~]# tcpdump -i eth0 -vv ip6
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:25:26.063597 IP6 (flowlabel 0xa64ab, hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:4f8:xxxx:yyyy::3 > edge-star-mini6-shv-01-amt2.facebook.com: [icmp6 sum ok] ICMP6, echo request, seq 1
09:25:26.074727 IP6 (class 0x40, hlim 56, next-header ICMPv6 (58) payload length: 64) edge-star-mini6-shv-01-amt2.facebook.com > 2a01:4f8:xxxx:yyyy::3: [icmp6 sum ok] ICMP6, echo reply, seq 1
09:25:27.070651 IP6 (flowlabel 0xa64ab, hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:4f8:xxxx:yyyy::3 > edge-star-mini6-shv-01-amt2.facebook.com: [icmp6 sum ok] ICMP6, echo request, seq 2
09:25:27.081839 IP6 (class 0x40, hlim 56, next-header ICMPv6 (58) payload length: 64) edge-star-mini6-shv-01-amt2.facebook.com > 2a01:4f8:xxxx:yyyy::3: [icmp6 sum ok] ICMP6, echo reply, seq 2
^C

Everything as excpected. After around 15-30 minutes, the VMs stop seeing echo replies and I get this from tcpdump:

[root@localhost ~]# tcpdump -i xenbr0 -vv ip6
tcpdump: listening on xenbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:28:23.106447 IP6 (class 0x40, hlim 56, next-header ICMPv6 (58) payload length: 64) edge-star-mini6-shv-01-amt2.facebook.com > 2a01:4f8:xxxx:yyyy::3: [icmp6 sum ok] ICMP6, echo reply, seq 1
09:28:24.113032 IP6 (class 0x40, hlim 56, next-header ICMPv6 (58) payload length: 64) edge-star-mini6-shv-01-amt2.facebook.com > 2a01:4f8:xxxx:yyyy::3: [icmp6 sum ok] ICMP6, echo reply, seq 2
^C

[root@localhost ~]# tcpdump -i eth0 -vv ip6
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:31:37.437793 IP6 (flowlabel 0x37012, hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:4f8:xxxx:yyyy::3 > edge-star-mini6-shv-01-fra3.facebook.com: [icmp6 sum ok] ICMP6, echo request, seq 19
09:31:37.442832 IP6 (class 0x40, hlim 57, next-header ICMPv6 (58) payload length: 64) edge-star-mini6-shv-01-fra3.facebook.com > 2a01:4f8:xxxx:yyyy::3: [icmp6 sum ok] ICMP6, echo reply, seq 19
^C

For some reason, when things stop working, the echo replies also go through the xenbr0 interface, rather than just eth0.

Running service networking stop && service networking start on the guest makes everything work again. Disabling and reenabling the VM network link on XenServer does not help. I already tried disabling router advertisments on the VMs, but that didn't help either.

I have no idea where this comes from, and whether it is a XenServer problem or an Ubuntu/Linux one. The wayward packets seen on xenbr0 seem to point to XenServer, the fact that resetting the VM networking stack helps seems to point to Linux...

Update

After reading a bit about XenServer networking, the issue seems to be that the XenServer virtual switch routes the packets to the wrong interface. Expected flow would be eth0 -> vif2.0, but packets go eth0 -> xenbr0 and thus end on the Dom0 machine instead of the correct DomU. After restarting networking on the DomU, some of the then sent neighbor solicitaion or neighbor advertisment seem to fix that issue temporarily:

13:50:23.178132 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
13:50:23.378089 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
13:50:23.442094 IP6 :: > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has example.org, length 24
13:50:23.698108 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
13:50:24.050127 IP6 :: > ff02::1:ff00:36ab: ICMP6, neighbor solicitation, who has fe80::250:xxxx:yyyy:36ab, length 24
13:50:25.050149 IP6 fe80::250:xxxx:yyyy:36ab > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
13:50:25.174116 IP6 fe80::250:xxxx:yyyy:36ab > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
13:50:27.605989 IP6 fe80::250:xxxx:yyyy:36ab > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32
13:50:27.606801 IP6 fe80::1 > fe80::250:xxxx:yyyy:36ab: ICMP6, neighbor advertisement, tgt is fe80::1, length 32
13:50:27.609480 IP6 fe80::250:xxxx:yyyy:36ab > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32
13:50:27.609488 IP6 example.org > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has fe80::1, length 32
13:50:27.609943 IP6 fe80::1 > fe80::250:xxxx:yyyy:36ab: ICMP6, neighbor advertisement, tgt is fe80::1, length 32

My knowledge about IPv6 is not that deep yet to be able to tell what exactly causes it to work again.

0

1 Answer 1

1

The problem was, as so often, the non-standard IPv6 setup of my hosting provider Hetzner. As far as I understood, no "true" bridged IPv6 setup is possible, because my dedicated /64 subnet is fixed to be routed to only one specific MAC address. NA oder NS packets can apparently override that for a short time, but it will revert back to the hosts MAC address shortly after. I now worked around that problem by enabling IPv6 packet forwarding on the host and setting it as the IPv6 gateway on the DomUs.

You must log in to answer this question.

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