XenServerゲストのIPv6がランダムに機能しなくなる
カーネル4.4.0でUbuntu16.04を実行しているXenServer7.0 VMは、マシン全体を再起動するか、ネットワークインターフェイスをリセットした直後に、IPv6パケットの受信を停止することを決定します。
すべてが機能している間、XenServerホストでtcpdumpを実行すると、facebook.comにpingを実行しているときに次のことがわかります。
[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分後、VMはエコー応答の表示を停止し、これを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
何らかの理由で、動作が停止すると、エコー応答alsoは、eth0だけでなく、xenbr0インターフェイスを通過します。
ランニング service networking stop && service networking startゲストで、すべてが再び機能します。 XenServerのVMネットワークリンクを無効にしてから再度有効にすると、notヘルプが表示されます。VMでルーター広告を無効にしようとしましたが、どちらも役に立ちませんでした。
これがどこから来ているのか、XenServerの問題なのかUbuntu/Linuxの問題なのかわかりません。 xenbr0で見られる厄介なパケットは、XenServerを指しているようです。VMネットワークスタックをリセットすると、Linuxを指しているようです...
更新
XenServerネットワーキングについて少し読んだ後、問題はXenServer仮想スイッチがパケットを間違ったインターフェイスにルーティングすることであるように思われます。予想されるフローはeth0 -> vif2.0、しかしパケットは行きますeth0 -> xenbr0したがって、正しいDomUではなくDom0マシンで終了します。 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についての私の知識はまだそれほど深くはなく、何がIPv6を再び機能させるのかを正確に知ることはできません。
問題は、よくあることですが、私のホスティングプロバイダーであるHetznerの非標準のIPv6セットアップでした。私が理解している限り、専用の/ 64サブネットは1つの特定のMACアドレスにのみルーティングされるように固定されているため、「真の」ブリッジIPv6セットアップは不可能です。 NA oder NSパケットは明らかにそれを短時間オーバーライドできますが、すぐにホストのMACアドレスに戻ります。ホストでIPv6パケット転送を有効にすることで、この問題を回避しました。 DomUのIPv6ゲートウェイとして設定します。