Overflow della tabella vicina su host Linux relativi a bridging e ipv6

Nota: ho già una soluzione alternativa per questo problema (come descritto di seguito), quindi questa è solo una domanda "da conoscere".

Ho una configurazione produttiva con circa 50 host inclusi blade che eseguono xen 4 ed equallogici che forniscono iscsi. Tutti i dom0 xen sono quasi semplici Debian 5. Il setup include diversi bridge su ogni dom0 per supportare il networking con bridge xen. In totale ci sono tra 5 e 12 ponti su ogni dom0 che servono un vlan ciascuno. Nessuno degli host ha il routing abilitato.

A un certo punto abbiamo spostato una delle macchine su un nuovo hardware incluso un controller raid e quindi abbiamo installato un kernel upstream 3.0.22 / x86_64 con patch xen. Tutte le altre macchine eseguono debian xen-dom0-kernel.

Da allora abbiamo notato su tutti gli host nell'installazione i seguenti errori ogni ~ 2 minuti:

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

La tabella arp (arp -n) non mostrava mai più di circa 20 voci su ogni macchina. Abbiamo provato le ovvie modifiche e sollevato il

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

valori. Finalmente a 16384 voci ma nessun effetto. Neanche l'intervallo di ~ 2 minuti è cambiato, il che mi ha portato alla conclusione che questo non è assolutamente correlato. tcpdump non ha mostrato traffico ipv4 insolito su nessuna interfaccia. L'unica scoperta interessante di tcpdump sono stati i pacchetti ipv6 che hanno fatto irruzione come:

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

che mi ha fatto venire in mente l'idea che il problema potrebbe essere correlato a ipv6, poiché non abbiamo servizi ipv6 in questa configurazione.

L'unico altro suggerimento era la coincidenza dell'aggiornamento dell'host con l'inizio dei problemi. Ho spento l'host in questione e gli errori erano spariti. Poi ho successivamente abbattuto i ponti sull'host e quando ho rimosso (ifconfig down) uno in particolare:

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

Gli errori sono scomparsi di nuovo. Come puoi vedere, il bridge non contiene alcun indirizzo ipv4 ed è solo membro eth0.2159, quindi nessun traffico dovrebbe attraversarlo. Il bridge e l'interfaccia .2159 / .2157 / .2158 che sono in tutti gli aspetti identici a parte il vlan a cui sono collegati non hanno avuto alcun effetto quando vengono rimossi . Ora ho disabilitato ipv6 sull'intero host tramite sysctl net.ipv6.conf.all.disable_ipv6 e riavviato. Dopodiché anche con bridge br-vlan2159 abilitato non si verificano errori.

Tutte le idee sono benvenute.

Credo che il tuo problema sia dovuto a un bug del kernel che è stato corretto net-next.

Lo snooping multicast viene disabilitato quando il bridge viene inizializzato a causa di un bug che tenta di modificare la tabella. Snooping IGMP ferma il ponte di inoltrare ogni HBH ICMPv6 risposta di query multicast, che risultati nella tabella vicino di casa riempiendo con ff02::vicini di risposte multicast, che dovrebbe non vedere (provare ip -6 neigh show nud all).

La soluzione corretta è quella di tentare di riattivare snooping come: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. L'alternativa è rendere le soglie gc della tabella adiacente maggiori del numero di host nel dominio di trasmissione.

La patch è qui .

qual è il ritorno ip route show cache table allquando si verifica questo errore?

arp -no ip neigh showmostrerà solo alcune delle voci nella cache.

ip route show cache table all sarà molto più dettagliato (e includerà molte voci relative alla v6).

Abbiamo provato le ovvie modifiche e abbiamo alzato / proc / sys / net / ipv4 / neigh / default / gc_thresh *

Hai fatto lo stesso per ipv6? che ha risolto il problema per noi

Ciao,

- creis