web-dev-qa-db-ja.com

ブリッジングと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を有効にしても、エラーは発生しません。

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

linuxnetworkingipv6arp
9
tim

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

テーブルを再ハッシュしようとするバグのため、ブリッジが初期化されるとマルチキャストスヌーピングが無効になります。 IGMPスヌーピングは、ブリッジがすべてのHBH ICMPv6マルチキャストクエリ応答を転送することを停止します。これにより、ネイバーテーブルは、マルチキャスト応答からのff02::ネイバーでいっぱいになる必要があります不可参照（ ip -6 neigh show nud all）をお試しください。

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

パッチは here です。

5
dbavatar

このエラーが発生した場合の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でも同じことをしましたか？それは私たちのために問題を解決しました

さようなら

-クレイス

3
creis