もう途方に暮れていますので、どんな助けでもいただければ幸いです。
私は IPv6 ホスト (Linux 4.15.1-gentoo SMP x86_64) を持っていますが、このホストはランダムに近隣広告の送信を停止します。tcpdump を実行すると、近隣要請要求が多数表示され、それらの要求に対する反応はほぼゼロです。ときどき、ホストは NA を送信しますが、それは数十の NS 要求を無視した後だけです。明らかに、これによって IPv6 接続が完全に切断されます。
関係があるかどうかはわかりませんが、ブリッジ インターフェイスには IPv6 が設定されています (そのブリッジではいくつかの lxc コンテナーも実行されています)。ブリッジは、STP がオフになっている典型的な brctl ブリッジです。
IPv6 は静的に構成されます (ホストとゲートウェイの両方)。
手動でネットワークに不要な近隣広告を大量に送信することで（たとえば、 ndsendfrom を使用vzctl）、問題を少し軽減できますが、明らかに解決策ではありません。
/proc/sys/net/ipv6/conf/br0/disable_ipv6さらに奇妙なことに、procfs ( )経由でインターフェイス上の ipv6 を無効にしてから再度有効にし、それを再設定 (ip -6 addr addなど) すると、一時的に問題が「解決」されます。ただし、1、2 日後に再び発生します。
完全性を保つために、ホスト上で nftables ファイアウォールが実行されていますが、すべての icmpv6 トラフィック (ip6 nexthdr ipv6-icmp acceptすべての場所経由) が明示的に許可されています。問題が発生したときにファイアウォールを無効にしても、何も変わりません。
では、質問です。根本的な問題を正確に特定するにはどうすればいいでしょうか?
アップデート: 私の場合、カーネルを数回アップデートした後、問題は解消されましたが、それ以降のカーネル バージョンでも、特にルーティング テーブルが大きい場合やネイバーの数が多い場合に、同様の問題が発生するという報告があります。報告によると、カーネルの IPv6 ルート/ネイバー キャッシュ サイズの制限が小さいことが、この問題の原因の 1 つである可能性があります。同様の問題が発生している場合は、を実行したり を編集したりして、net.ipv6.route.max_sizesysctl パラメータを比較的大きな値 (例1048576)に上げてみてください。また、ガベージ コレクターが頻繁に実行されないように を上げることも必要になるでしょう。また、ネイバー キャッシュに特に多くのレコードがある場合は、 、 、 を 確認してください。sysctl -w net.ipv6.route.max_size=1048576/etc/sysctl.confnet.ipv6.route.gc_threshnet.ipv6.neigh.default.gc_thresh1net.ipv6.neigh.default.gc_thresh2net.ipv6.neigh.default.gc_thresh3https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txtこれらすべてのオプションが何をするのかを説明します。
答え1
Linux の VLAN 対応ブリッジのマルチキャスト スヌーピングにバグがあることを発見しました。ルータ広告には影響しませんが、マルチキャスト フラッディングがオンの場合でも近隣探索をブロックします。システムの起動時に Dad が実行され、その Dad がマルチキャスト転送データベースに残ります。ただし、これは 200 秒または 300 秒後に期限切れになります。その後、近隣探索マルチキャスト パケットはそのポートにドロップされます。これは近隣探索でのみ発生し、ルータ広告では発生しません。次の操作を実行すると、これを確認できます。
bridge mdb show
エントリが表示されている場合は、multicast_snooping がオンになっています。バグが発生する可能性があります。私の場合、セットアップしたシステムの約 80% が近隣探索マルチキャストのみをブロックし始めました。その他のマルチキャストはフラッディングされるか、正しくスヌーピングされます。
現時点での解決策は、multicast_snooping をオフにすることです。
echo 0 > /sys/net/devicename/bridge/multicast_snooping
時間があれば、テスト セットアップを作成します。このバグは 2 年間私を悩ませてきましたが、緊急メンテナンス中にようやく問題を完全に把握する時間ができました。
答え2
私は 4.16.2-gentoo カーネルでも同じ問題を抱えていました。しかし、私の場合はカーネルとはまったく関係がないことが判明しました。
問題のボックスは、IPv6 VPN ゲートウェイとして機能し、安定した接続を維持していました。背後のサブネット ルーターもまったく問題ありませんでした。ルーティングされたサブネット自体の接続が頻繁に失われていました。
TL;DR;
ファイアウォール私の場合、原因はipv6でした。rpフィルターこの設定により、サブネット ルーターの近隣要請がフィルタリングされました。
ログインを有効にしてそれを発見しました/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
なぜこのようなことが起きているのかがわかるまで、ipv6 rpfilter を無効にしました。設定は非常にシンプルで、すべて問題ないように見えますが、インターフェイスが VLAN になっていることが原因かもしれません...