☰

IPv6 接続が突然失われ、同時に IPv6 隣接ルーターのステータスが STALE になります。どうすればこれを回避できますか?

tag-icon • tag-icon ipv6 arp best-practices
IPv6 接続が突然失われ、同時に IPv6 隣接ルーターのステータスが STALE になります。どうすればこれを回避できますか?

ブリッジ ネットワーク (つまり、独自の MAC アドレス) を備えたホスト上に VM があります。ホストと VM は両方とも CentOS を実行しています。ネットワークは、/etc/sysconfig/network-scripts/ifcfg-enpXsY静的 IP アドレスを含む単純なファイルによって管理されています。IPv4 は問題なく動作します。

VM に IPv6 アドレスを割り当てました (ホストにも IPv6 アドレスがあります)。このアドレスはデータ センターで正しくルーティングされます。ただし、ほとんどの接続では IPv4 が使用されます (マシンの DNS AAAA エントリはまだありません。IPv6 をテスト中です)。

VMを起動すると完全なIPv6接続が確立されます。しかし、しばらくするとIPv6接続が機能しなくなります(IPv6 マジック?) 問題を近隣 (ARP/NDISC キャッシュ) データに絞り込みました。

IPv6が機能しない、IPv6 入出力による ping または接続ができない場合は、次のように表示されます。

# ip -6 neighbour 
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router STALE

キャッシュを更新するための修正/回避策:

# ip -6 neighbour flush dev enp1s2
# ip -6 neighbour
(empty, as expected)

次に、ping6ホストは VM 内からキャッシュを埋めます。

# ping6 2912:1375:23:9a6c::2
PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 data bytes
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 time=2.35 ms
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 time=0.468 ms
^C
# ip -6 neighbour
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router REACHABLE
2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 DELAY

IPv6 ネイバー/ARP テーブルが有効状態に復元され、接続が機能しています。

私の質問は次のとおりです:

  1. キャッシュが古くなるのはなぜですか?
  2. それを避けるにはどうしたらいいでしょうか？
  3. 上記のコマンドでなぜ/どのように修正されるのでしょうか?

もちろん、cronジョブ内でこれらのコマンドを実行することはできますが (どのくらいの頻度で?)、IPv6 が一般的に機能するためには、それが本当に必要ないのではないでしょうか?

PS: テストにはスクリプトを使用しました:IPv6スタックは約20分ごとに故障しますそれは RFC で説明できますか?

PPS: ファイアウォール設定 (短縮された出力、関連するすべてのビットが含まれているはずです):

# ip6tables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9023  709K ACCEPT     icmpv6    !lo    *       ::/0                 ::/0                
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9360  785K ACCEPT     icmpv6    *      !lo     ::/0                 ::/0

つまり、ICMPv6 は VM 上で入出力が受け入れられます。ホスト上でフィルタリングを確認する必要がありますか?

答え1

一般的に、古い状態は良いことであり、実際、古い状態であることは許容されます。

RFC 4861 のセクション 5.1 を見てみましょう。

  STALE       The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability.

ネイバーは到達可能ではないことが分かっており (タイマーが期限切れ、最近トラフィックがない、など)、トラフィックがネイバーに再度送信されると到達可能性が「検証」されます。

したがって、ネイバーにトラフィックを再度送信できる場合は問題はありません。

関連情報