Neighbor table overflow pada host Linux terkait dengan bridging dan ipv6

Catatan: Saya sudah memiliki solusi untuk masalah ini (seperti dijelaskan di bawah) jadi ini hanya pertanyaan "ingin tahu".

Saya memiliki pengaturan produktif dengan sekitar 50 host termasuk blade yang menjalankan xen 4 dan equallogics yang menyediakan iscsi. Semua xen dom0s hampir polos Debian 5. Setup mencakup beberapa jembatan di setiap dom0 untuk mendukung xen bridged networking. Total ada antara 5 dan 12 jembatan pada setiap dom0 yang melayani satu vlan masing-masing. Tidak ada host yang memiliki perutean yang diaktifkan.

Pada satu titik waktu kami memindahkan salah satu mesin ke perangkat keras baru termasuk pengontrol serangan dan jadi kami memasang kernel 3.0.22 / x86_64 upstream dengan patch xen. Semua mesin lain menjalankan debian xen-dom0-kernel.

Sejak itu kami perhatikan pada semua host di setup kesalahan berikut setiap ~ 2 menit:

[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.

Tabel arp (arp -n) tidak pernah menampilkan lebih dari sekitar 20 entri pada setiap mesin. Kami mencoba tweak yang jelas dan mengangkat

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

nilai-nilai. Akhirnya ke 16384 entri tetapi tidak ada efek. Bahkan interval ~ 2 menit tidak berubah yang membawa saya pada kesimpulan bahwa ini sama sekali tidak berhubungan. tcpdump tidak menunjukkan traffic ipv4 yang tidak biasa pada antarmuka apa pun. Satu-satunya temuan menarik dari tcpdump adalah paket-paket ipv6 muncul seperti:

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

yang menempatkan ide di benak saya bahwa masalah mungkin terkait dengan ipv6, karena kami tidak memiliki layanan ipv6 dalam pengaturan ini.

Satu-satunya petunjuk lainnya adalah kebetulan upgrade host dengan awal masalah. Saya mematikan host yang dimaksud dan kesalahan hilang. Kemudian saya kemudian menurunkan jembatan pada host dan ketika saya menurunkan (ifconfig down) satu terutama jembatan:

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

Kesalahan hilang lagi. Seperti yang Anda lihat jembatan tidak memiliki alamat ipv4 dan hanya anggotanya eth0.2159 sehingga tidak ada lalu lintas yang boleh melintasinya. Bridge dan interface .2159 / .2157 / .2158 yang dalam semua aspek identik terlepas dari vlan yang mereka sambungkan tidak memiliki efek ketika diturunkan. Sekarang saya menonaktifkan ipv6 pada seluruh host melalui sysctl net.ipv6.conf.all.disable_ipv6 dan reboot. Setelah ini bahkan dengan bridge br-vlan2159 diaktifkan tidak ada kesalahan terjadi.

Setiap ide dipersilakan.

Saya percaya masalah Anda adalah karena bug kernel yang telah diperbaiki net-next.

Mengintip multicast akan dinonaktifkan ketika jembatan diinisialisasi karena bug yang mencoba untuk mengulang tabel. Pengintaian IGMP menghentikan bridge agar tidak meneruskan setiap balasan permintaan multicast HBH ICMPv6, yang menghasilkan tabel tetangga terisi dengan ff02::tetangga dari balasan multicast yang seharusnya tidak dilihatnya (coba ip -6 neigh show nud all).

Solusi yang tepat adalah upaya untuk mengaktifkan kembali mengintip seperti: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. Alternatifnya adalah dengan membuat ambang tabel tetangga gc lebih besar dari jumlah host di domain siaran.

Tambalan ada di sini .

apa kembalinya ip route show cache table allketika Anda mengalami kesalahan ini?

arp -natau ip neigh showhanya akan menampilkan beberapa entri dalam cache.

ip route show cache table all akan jauh lebih rinci (dan akan mencakup banyak entri terkait v6).

Kami mencoba tweak yang jelas dan mengangkat / proc / sys / net / ipv4 / neigh / default / gc_thresh *

Apakah Anda melakukan hal yang sama untuk ipv6? yang memecahkan masalah bagi kita

Sampai jumpa,

- creis