Przepełnienie tabeli sąsiadów na hostach Linux związanych z mostowaniem i ipv6

Uwaga: Mam już obejście tego problemu (jak opisano poniżej), więc jest to tylko pytanie „chcieć wiedzieć”.

Mam produktywną konfigurację z około 50 hostami, w tym blade z Xen 4 i equallogics zapewniającymi iscsi. Wszystkie Xen dom0 są prawie zwykłym Debianem 5. Instalacja zawiera kilka mostków na każdym dom0 do obsługi sieci mostkowanej xen. W sumie na każdym dom0 jest od 5 do 12 mostków obsługujących po jednym vlan. Żaden z hostów nie ma włączonego routingu.

W pewnym momencie przenieśliśmy jedną z maszyn na nowy sprzęt, w tym kontroler RAID, dlatego zainstalowaliśmy jądro 3.0.22 / x86_64 z łatkami xen. Wszystkie pozostałe maszyny uruchamiają jądro debian xen-dom0-kernel.

Od tego czasu zauważyliśmy na wszystkich hostach w konfiguracji następujące błędy co ~ 2 minuty:

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

Tabela arp (arp -n) nigdy nie pokazywała więcej niż około 20 wpisów na każdej maszynie. Próbowaliśmy oczywistych poprawek i podnieśliśmy

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

wartości. FInally do 16384 wpisów, ale bez efektu. Nie zmienił się nawet odstęp ~ 2 minut, co doprowadziło mnie do wniosku, że jest to całkowicie niezwiązane. tcpdump nie wykazał nietypowego ruchu IPv4 na żadnym interfejsie. Jedynym ciekawym odkryciem z tcpdump były pakiety ipv6 pękające w następujący sposób:

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

co przyniosło mi myśl, że problem może być związany z ipv6, ponieważ w tej konfiguracji nie mamy żadnych usług ipv6.

Jedyną inną wskazówką była zbieżność aktualizacji hosta z początkiem problemów. Wyłączyłem hosta i błędy zniknęły. Następnie zdemontowałem mosty na hoście, a kiedy zdjąłem (ifconfig down) jeden szczególnie most:

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

Błędy zniknęły ponownie. Jak widać, most nie ma adresu IPv4, a jego jedynym członkiem jest eth0.2159, więc żaden ruch nie powinien go przekraczać. Mostek i interfejs .2159 / .2157 / .2158, które we wszystkich aspektach są identyczne z wyjątkiem sieci vlan, z którą są połączone, nie działały po zdjęciu . Teraz wyłączyłem ipv6 na całym hoście poprzez sysctl net.ipv6.conf.all.disable_ipv6 i zrestartowałem. Po tym nawet przy włączonym pomoście br-vlan2159 nie występują błędy.

Wszelkie pomysły są mile widziane.

Uważam, że twój problem jest spowodowany przez załatany błąd jądra net-next.

Szpiegowanie multiemisji zostaje wyłączone po zainicjowaniu mostu z powodu błędu, który próbuje odtworzyć tabelę. IGMP Snooping zatrzymuje most od przekazywania wszelkich HBH ICMPv6 odpowiedź zapytania multicast, co wynika z tabeli sąsiada zapełniać z ff02::sąsiadami z multicast odpowiedziami, które powinno nie widzą (TRY ip -6 neigh show nud all).

Właściwym rozwiązaniem jest próba ponownego włączenia podsłuchiwanie jak: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. Alternatywą jest zwiększenie progów gc tabeli sąsiedniej niż liczba hostów w domenie rozgłoszeniowej.

Łatka jest tutaj .

jaki jest powrót, ip route show cache table allgdy występuje ten błąd?

arp -nlub ip neigh showpokaże tylko niektóre wpisy w pamięci podręcznej.

ip route show cache table all będzie o wiele bardziej szczegółowy (i będzie zawierał wiele wpisów związanych z wersją 6).

Wypróbowaliśmy oczywiste poprawki i podnieśliśmy / proc / sys / net / ipv4 / neigh / default / gc_thresh *

Czy zrobiłeś to samo dla ipv6? to rozwiązało dla nas problem

PA,

- creis