运行内核为4.4.0的Ubuntu 16.04的我的XenServer 7.0虚拟机决定在重新启动整个机器或重新设置networking接口后立即停止接收IPv6数据包。
在一切正常的情况下，在XenServer主机上运行tcpdump时，在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
一切都被尊重。 大约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
出于某种原因，当事情停止工作时，echo回复也会通过xenbr0接口，而不仅仅是eth0。
运行service networking stop && service networking start在客人service networking stop && service networking start使一切都工作了。 在XenServer上禁用和重新启用VMnetworking链接不起作用。 我已经尝试禁用虚拟机上的路由器广告，但这也没有帮助。
我不知道这是从哪里来的，无论是XenServer问题还是Ubuntu / Linux问题。 在xenbr0看到的任性数据包似乎指向XenServer，重置VMnetworking堆栈的事实似乎指向Linux …
更新
在阅读了关于XenServernetworking的一些信息之后，问题似乎是XenServer虚拟交换机将数据包路由到错误的接口。 预期的stream量是eth0 -> vif2.0 ，但数据包走eth0 -> xenbr0 ，因此结束在Dom0机器而不是正确的DomU。 在DomU上重新启动networking后，一些发送邻居请求或邻居广告似乎暂时解决了这个问题：
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的了解并不深，但还不能确定究竟是什么导致它再次运行。
问题就在于我的托pipe服务提供商Hetzner的非标准IPv6设置。 据我所知，没有“真正的”桥接IPv6设置是可能的，因为我的专用/ 64子网是固定的只能路由到一个特定的MAC地址。 NA或NS数据包可以在短时间内覆盖它，但不久之后它将恢复到主机MAC地址。 我现在通过在主机上启用IPv6数据包转发并将其设置为DomU上的IPv6网关来解决该问题。