我的 XenServer 7.0 VM 运行带有内核 4.4.0 的 Ubuntu 16.04，在重新启动整个机器或重置网络接口后不久决定停止接收 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 的了解还不够深入，因此无法说出究竟是什么原因导致它再次发挥作用。
答案1
问题在于，正如通常情况一样，我的托管服务提供商 Hetzner 的非标准 IPv6 设置。据我所知，不可能设置“真正的”桥接 IPv6，因为我的专用 /64 子网固定为仅路由到一个特定的 MAC 地址。NA 或 NS 数据包显然可以在短时间内覆盖该地址，但不久之后它将恢复为主机 MAC 地址。我现在通过在主机上启用 IPv6 数据包转发并将其设置为 DomU 上的 IPv6 网关来解决该问题。