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.
źródło
echo 1 > /sys/class/net/br0/bridge/multicast_snooping
.jaki jest powrót,
ip route show cache table all
gdy występuje ten błąd?arp -n
lubip neigh show
pokaż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).Czy zrobiłeś to samo dla ipv6? to rozwiązało dla nas problem
PA,
- creis
źródło
net.ipv6.neigh.default.gc_thresh1 = 1024 net.ipv6.neigh.default.gc_thresh2 = 2048 net.ipv6.neigh.default.gc_thresh3 = 4096)
przez sysctl.