XenServer 来宾中的 IPv6 随机停止工作

我的 XenServer 7.0 VM 运行 Ubuntu 16.04 和内核 4.4.0 决定在重新启动整个机器或重置网络接口后不久停止接收 IPv6 数据包。

tcpdump虽然一切正常，但在 XenServer 主机上运行会在 ping 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

一切如预期。大约 15-30 分钟后，虚拟机停止看到回显回复，我从以下渠道得到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

出于某种原因，当事情停止工作时，回显回复也会通过 xenbr0 接口，而不仅仅是 eth0。

在客人身上运行service networking stop && service networking start会使一切重新工作。在 XenServer 上禁用和重新启用 VM 网络链接没有帮助。我已经尝试在虚拟机上禁用路由器广告，但这也无济于事。

我不知道这是从哪里来的，不知道是 XenServer 问题还是 Ubuntu/Linux 问题。在 xenbr0 上看到的任性数据包似乎指向 XenServer，重置 VM 网络堆栈有助于这一事实似乎指向 Linux...

更新

在阅读了一些关于 XenServer 网络的信息后，问题似乎是 XenServer 虚拟交换机将数据包路由到了错误的接口。预期的流量是eth0 -> vif2.0，但是数据包会eth0 -> xenbr0在 Dom0 机器上结束，而不是在正确的 DomU 上结束。在 DomU 上重新启动网络后，一些随后发送的邻居请求或邻居广告似乎暂时解决了该问题：

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

我对 IPv6 的了解还不是很深，尚无法说出究竟是什么导致它再次工作。