web-dev-qa-db-ja.com

Linuxホストは、ipv6近隣要請要求への応答をランダムに停止します

私は気が遠くなるので、どんな助けでもありがたいです。

ネイバーアドバタイズメントの送信をランダムに停止するIPv6ホスト(Linux 4.15.1-gentoo SMP x86_64)があります。 tcpdumpを実行すると、多くのネイバー要請要求が表示され、それらの要求に対する反応はほとんどありません。場合によっては、ホストは引き続きNAを送信しますが、それは数ダースがNS要求を無視した後でのみです。明らかに、これはIPv6接続を完全に破壊します。

関連性があるかどうかはわかりませんが、IPv6はブリッジインターフェイスで構成されています(そのブリッジでもいくつかのlxcコンテナーが実行されています)。ブリッジは、STPがオフになっている典型的なbrctlブリッジです。

IPv6は静的に構成されます(ホストとゲートウェイの両方)。

未承諾のネイバーアドバタイズメントでネットワークを手動でフラッディングする(たとえば、ndsendからvzctlを使用)と、問題を少し軽減できますが、明らかに解決策ではありません。

さらに奇妙なことに、procfs(/proc/sys/net/ipv6/conf/br0/disable_ipv6)を介してインターフェイスでipv6を無効にしてから再度有効にし、再構成(ip -6 addr addなど)すると、問題が一時的に「修正」されます。しかし、それは1日か2日で再び起こります。

完全を期すために、ホスト上で実行されているnftablesファイアウォールがありますが、これはすべてのicmpv6トラフィックを明示的に許可します(どこでもip6 nexthdr ipv6-icmp accept経由)。問題が発生したときにファイアウォールを無効にしても、何も変わりません。

だから、ここに質問があります:根本的な問題を特定するために私は何ができますか?

[〜#〜] update [〜#〜]:私にとって、問題はいくつかのカーネルの更新後に消えましたが、同様の問題の報告がありますそれ以降のカーネルバージョン、特に大きなルーティングテーブルや多数のネイバーを使用する場合。伝えられるところによると、ここで考えられる原因の1つは、カーネルのipv6ルート/ネイバーキャッシュサイズの小さな制限です。同様の問題が発生している場合は、たとえばnet.ipv6.route.max_sizeを実行するか、1048576を編集して、sysctl -w net.ipv6.route.max_size=1048576 sysctlパラメーターを比較的大きな値(例:/etc/sysctl.conf)に上げてみてください。 。また、ガベージコレクターを頻繁に実行しないように、net.ipv6.route.gc_threshを上げることもできます。また、ネイバーキャッシュに特に多くのレコードがある場合は、net.ipv6.neigh.default.gc_thresh1net.ipv6.neigh.default.gc_thresh2、およびnet.ipv6.neigh.default.gc_thresh3を確認してください。これらすべてのオプションの機能については、 https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt を参照してください。

2
lierdakil

4.16.2-gentooカーネルでも同じ問題が発生していました。しかし、私の場合、カーネルとはまったく関係がないことがわかりました。

問題のボックスは、ipv6 VPNゲートウェイとして機能し、安定した接続を維持していました。その背後にあるサブネットルーターでさえ完全に問題なく、ルーティングされたサブネット自体が常に接続を失っていました。

TL; DR;
firewalld私の場合は犯人でした。 ipv6 rpfilter設定は、サブネットルーターのネイバー要請をフィルタリングしました。

/etc/firewalld/firewalld.confでのログインを有効にすることでそれについて知りました

LogDenied=all

その結果、次のようなログラインが作成されました(MACおよびSRCが短縮され、難読化されました)。

kernel: rpfilter_DROP: IN=enp6s0.100 OUT= MAC=XX:…:XX SRC=fe80:…:beaf DST=ff02:0000:0000:0000:0000:0001:ff00:0001 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0

なぜこれが起こっているのかがわかるまで、ipv6rpfilterを無効にしました。セットアップは非常に簡単で、すべてが私には問題ないように見えますが、おそらくそれはVLANをビーイングするインターフェースの問題です...

1
m0gg