ブリッジングとipv6に関連するLinuxホストでのネイバーテーブルのオーバーフロー

注：この問題の回避策は（以下で説明するように）すでにありますので、これは「知りたい」質問にすぎません。

私はxen 4を実行しているブレードとiscsiを提供するequallogicsを含む約50台のホストで生産的な設定をしています。すべてのxen dom0は、ほぼプレーンなDebian 5です。セットアップには、xenブリッジネットワークをサポートするために、すべてのdom0にいくつかのブリッジが含まれています。合計で、各dom0に5〜12のブリッジがあり、それぞれ1つのVLANにサービスを提供しています。どのホストもルーティングが有効になっていません。

ある時点で、マシンの1つをRAIDコントローラを含む新しいハードウェアに移動したため、xenパッチを適用したアップストリーム3.0.22 / x86_64カーネルをインストールしました。他のすべてのマシンはdebian xen-dom0-kernelを実行します。

それ以来、セットアップのすべてのホストで、約2分ごとに次のエラーに気づきました。

[55888.881994] __ratelimit: 908 callbacks suppressed
[55888.882221] Neighbour table overflow.
[55888.882476] Neighbour table overflow.
[55888.882732] Neighbour table overflow.
[55888.883050] Neighbour table overflow.
[55888.883307] Neighbour table overflow.
[55888.883562] Neighbour table overflow.
[55888.883859] Neighbour table overflow.
[55888.884118] Neighbour table overflow.
[55888.884373] Neighbour table overflow.
[55888.884666] Neighbour table overflow.

arpテーブル（arp -n）は、すべてのマシンで約20を超えるエントリを表示することはありませんでした。私たちは明らかな調整を試み、

/proc/sys/net/ipv4/neigh/default/gc_thresh*

値。最終的には16384エントリまでですが、効果はありません。〜2分の間隔も変更されなかったため、これはまったく無関係であるという結論に至りました。tcpdumpは、どのインターフェイスでも一般的でないIPv4トラフィックを示しませんでした。tcpdumpからの唯一の興味深い発見は、次のようにバーストするipv6パケットでした：

14:33:13.137668 IP6 fe80::216:3eff:fe1d:9d01 > ff02::1:ff1d:9d01: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:9d01, length 24
14:33:13.138061 IP6 fe80::216:3eff:fe1d:a8c1 > ff02::1:ff1d:a8c1: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:a8c1, length 24
14:33:13.138619 IP6 fe80::216:3eff:fe1d:bf81 > ff02::1:ff1d:bf81: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:bf81, length 24
14:33:13.138974 IP6 fe80::216:3eff:fe1d:eb41 > ff02::1:ff1d:eb41: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:eb41, length 24

この設定にはipv6サービスがないため、問題がおそらくipv6に関連しているという考えが私の頭に浮かびました。

他の唯一のヒントは、ホストのアップグレードが問題の始まりと一致したことでした。問題のホストの電源を切りましたが、エラーは発生しませんでした。次に、ホストのブリッジを削除し、特定のブリッジを1つ削除（ifconfigダウン）した場合：

br-vlan2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:120 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:5286 (5.1 KiB)  TX bytes:726 (726.0 B)

eth0.2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1801 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:126228 (123.2 KiB)  TX bytes:1464 (1.4 KiB)

bridge name bridge id       STP enabled interfaces
...
br-vlan2158     8000.0026b9fb162c   no      eth0.2158
br-vlan2159     8000.0026b9fb162c   no      eth0.2159

エラーは再び消えました。ご覧のとおり、ブリッジはipv4アドレスを保持しておらず、唯一のメンバーはeth0.2159であるため、トラフィックはブリッジを通過できません。ブリッジとインターフェース.2159 / .2157 / .2158は、接続されているvlanを除いてすべての面で同一であり、ダウンしても影響がありませんでした。ここで、sysctl net.ipv6.conf.all.disable_ipv6を介してホスト全体でipv6を無効にし、再起動しました。この後、ブリッジbr-vlan2159を有効にしても、エラーは発生しません。

どんなアイデアでも大歓迎です。

あなたの問題は、でパッチされたカーネルのバグが原因であると思いますnet-next。

テーブルを再ハッシュしようとするバグのため、ブリッジが初期化されるとマルチキャストスヌーピングが無効になります。IGMPスヌーピングは、ブリッジがすべてのHBH ICMPv6マルチキャストクエリ応答を転送することを停止します。その結果、ネイバーテーブルは、見るff02::べきではないマルチキャスト応答からのネイバーで一杯になります（試行ip -6 neigh show nud all）。

適切な回避策は、次のようにスヌーピングを再度有効にすることですecho 1 > /sys/class/net/eth0/bridge/multicast_snooping。代わりに、ネイバーテーブルのGCしきい値を、ブロードキャストドメイン内のホスト数よりも大きくすることもできます。

パッチはこちらです。

ip route show cache table allこのエラーが発生した場合の戻り値は何ですか？

arp -nまたはip neigh show、キャッシュ内の一部のエントリのみを表示します。

ip route show cache table all より詳細になります（v6に関連する多くのエントリが含まれます）。

私たちは明らかな調整を試み、/ proc / sys / net / ipv4 / neigh / default / gc_thresh *を上げました

ipv6でも同じことをしましたか？それは私たちのために問題を解決しました

さようなら

-クレイス