Cosa succede quando la cache ARP trabocca?

In almeno un'implementazione esiste un limite rigido alla capacità della tabella ARP. Cosa succede quando la cache ARP è piena e viene offerto un pacchetto con una destinazione (o hop successivo) che non è memorizzata nella cache? Cosa succede sotto il cofano e qual è l'effetto sulla qualità del servizio?

Ad esempio, i router Brocade NetIron XMR e Brocade MLX hanno un massimo di sistema configurabileip-arp . Il valore predefinito in quel caso è 8192; la dimensione di una sottorete / 19. Dalla documentazione non è chiaro se questo sia per interfaccia o per l'intero router, ma ai fini di questa domanda, possiamo supporre che sia per interfaccia.

Pochi networkers configurerebbero una sottorete / 19 su un'interfaccia appositamente, ma non è quello che è successo. Stavamo migrando un router core da un modello Cisco a un Brocade. Una delle molte differenze tra Cisco e Brocade è che Cisco accetta route statiche definite sia con un'interfaccia in uscita che con un indirizzo hop successivo, ma Brocade insiste sull'una o sull'altra. Abbiamo lasciato l'indirizzo dell'hop successivo e abbiamo mantenuto l'interfaccia. Successivamente, abbiamo appreso l'errore dei nostri modi e siamo passati dall'interfaccia all'indirizzo dell'hop successivo, ma tutto sembrava funzionare inizialmente.

+----+ iface0    +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1       .2+----+
      10.0.0.0/30

Prima della migrazione, R1 era un Cisco e aveva la seguente rotta.

ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2

Dopo la migrazione, R1 era un broccato e aveva la seguente rotta.

ip route 10.1.0.0 255.255.0.0 iface0

R2 è un router Cisco e i router Cisco eseguono ARP proxy per impostazione predefinita. Questa è la (errata) configurazione in produzione che ha posto le basi per quello che si è rivelato essere un overflow della cache ARP.

1. R1 riceve un pacchetto destinato alla rete 10.1.0.0/16.
2. Sulla base del percorso dell'interfaccia statica, gli ARP R1 per la destinazione sono attivi iface0
3. R2 riconosce che può raggiungere la destinazione e risponde all'ARP con il proprio MAC.
4. R1 memorizza nella cache il risultato ARP che combina un IP in una rete remota con il MAC di R2.

Questo accade per ogni destinazione distinta in 10.1.0.0/16. Di conseguenza, anche se / 16 è sottorete correttamente oltre R2, e ci sono solo due nodi sul collegamento adiacente a R1 e R2, R1 subisce un sovraccarico della cache ARP perché induce R2 a comportarsi come se tutti gli indirizzi 65k fossero collegati direttamente.

Il motivo per cui sto ponendo questa domanda è perché spero che mi aiuti a dare un senso ai rapporti sui problemi del servizio di rete (giorni dopo) che ci hanno portato, alla fine, alla cache ARP traboccante. Nello spirito del modello StackExchange, ho cercato di distillare ciò che credo sia una domanda chiara e specifica a cui si possa rispondere obiettivamente.

MODIFICA 1 Per essere chiari, chiedo di parte del livello di colla tra collegamento dati (livello 2) e rete (livello 3), non la tabella di inoltro MAC all'interno del livello collegamento dati. Un host o un router crea il primo per mappare gli indirizzi IP agli indirizzi MAC, mentre uno switch crea il secondo per mappare gli indirizzi MAC alle porte.

EDIT 2 Mentre apprezzo lo sforzo con il quale i rispondenti sono andati a spiegare perché alcune implementazioni non sono soggette all'overflow della cache ARP, ritengo sia importante che questa domanda sia indirizzata a quelle che sono. La domanda è "cosa succede quando", non "il fornitore X è sensibile a". Ho fatto la mia parte ora descrivendo un esempio concreto.

EDIT 3 Un'altra domanda non è questa: "come posso evitare il trabocco della cache ARP?"

Modifica 2 :

Come hai menzionato...

ip route 10.1.0.0 255.255.0.0 iface0

Forza Brocade a proxy-arp per ogni destinazione in 10.1.0.0/16 come se fosse direttamente collegata iface0.

Non posso rispondere dell'implementazione della cache ARP di Brocade, ma vorrei semplicemente indicare la soluzione semplice al tuo problema ... configurare il percorso in modo diverso:

ip route 10.1.0.0 255.255.0.0 CiscoNextHopIP

In questo modo, impedisci a Brocade di ARP-ing per tutto il 10.1.0.0/16 (nota, potrebbe essere necessario rinumerare il collegamento tra R1 e R2 in modo che sia esterno al 10.1.0.0/16, a seconda dell'implementazione delle cose di Brocade) .

Risposta originale :

Mi aspetto che nella maggior parte, o anche in tutte le implementazioni, vi sia un limite rigido alla capacità della tabella ARP.

I router CPU Cisco IOS sono limitati solo dalla quantità di DRAM nel router, ma in genere questo non sarà un fattore limitante. Alcuni switch (come Catalyst 6500) presentano una forte limitazione nella tabella di adiacenza (che è correlata alla tabella ARP); Sup2T ha 1 milione di adiacenze .

Quindi, cosa succede quando la cache ARP è piena e viene offerto un pacchetto con una destinazione (o hop successivo) che non è memorizzata nella cache?

I router CPU Cisco IOS non esauriscono lo spazio nella tabella ARP, poiché tali ARP sono archiviati nella DRAM. Supponiamo che tu stia parlando di Sup2T. Pensala in questo modo, supponi di avere un Cat6500 + Sup2T e di aver configurato tutti i Vlan possibili, tecnicamente

4094 total Vlans - Vlan1002 - Vlan1003 - Vlan1004 - Vlan1005 = 4090 Vlans

Supponiamo di rendere ogni Vlan a / 24 (quindi 252 possibili ARP), e impacchettare ogni Vlan pieno ... ovvero 1 milione di voci ARP.

4094 * 252 = 1,030,680 ARP Entries

Ognuno di questi ARP consumerebbe una certa quantità di memoria nella tabella ARP stessa, oltre alla tabella di adiacenza IOS. Non so di cosa si tratta, ma supponiamo che l'overhead totale di ARP sia di 10 byte ...

Ciò significa che ora hai consumato 10 MB per l'overhead ARP; non è ancora molto spazio ... se fossi così a corto di memoria, vedresti qualcosa del genere %SYS-2-MALLOCFAIL.

Con così tanti ARP e un timeout ARP di quattro ore, dovresti servire in media quasi 70 ARP al secondo; è più probabile che la manutenzione su 1 milione di voci ARP esaurisca la CPU del router (potenzialmente messaggi CPUHOG).

A questo punto, potresti iniziare a far rimbalzare le adiacenze del protocollo di routing e avere IP semplicemente irraggiungibili perché la CPU del router era troppo occupata per ARP per l'IP.

L'unica esperienza effettiva che ho avuto con questo evento è stata sugli switch C3550 (limite MAC 2-8k, a seconda del modello sdm) e lì ha lasciato cadere la voce più vecchia dalla tabella.

Per IOS e JunOS e altri stack commerciali devi solo testare, per fortuna non è molto difficile.

Ma per linux , freebsd, netbsd, openbsd, uIP, lwIP e probabilmente molte altre implementazioni puoi semplicemente controllare il loro codice sorgente per il comportamento.

In Linux è necessario selezionare "net / core / neighbour.c" (iniziare con la riga "if (entry> = tbl-> gc_thresh3 '||') e 'net / ipv4 / arp.c'.
In Linux sembra che hanno tre livelli completi

1. gc_thresh1 - nulla viene fatto fino a quando non viene colpito
2. gc_thresh2 - questo può essere colpito momentaneamente
3. gc_thresh3 - questa dimensione non può essere superata

Quando gc_thresh3 tenta di superare, tenta di forzare l'esecuzione della garbage collection, a meno che non sia già stata eseguita di recente. La raccolta dati inutili sembra eliminare le voci a cui non si fa più riferimento, quindi non significa più vecchio o più recente, tuttavia il superamento di gc_staletime sembra essere un modo di dereferenziare la voce, che si traduce nuovamente nella voce più vecchia.
Se non è possibile eseguire Garbage Collect, la nuova voce non viene semplicemente aggiunta. Tutti questi intervalli gc_threshN e periodici garbage collection possono essere regolati.
Il codice è agnostico della famiglia di indirizzi (ipv4, ipv6), pertanto le tabelle ND e IPv4 ARP IPv6 sono gestite dallo stesso identico percorso di codice, non da un percorso duplicato.

Arp per l'indirizzo IP lo memorizza nella tabella e in base all'implementazione dovrebbe eliminare la voce più vecchia. L'impatto sulle prestazioni dipende, se si tratta di un evento insolito, non di grande impatto, ma si tratta di un vettore di attacco, quindi qualcuno può inviare molti arp che influiscono sull'utilizzo del processore

Lo switch andrà su ARP per quell'IP di destinazione per ottenere il suo indirizzo MAC (che popolerebbe anche la tabella CAM con la risposta). La richiesta ARP viene trasmessa a tutte le porte. Ciò richiede la CPU e coinvolge il ARP Inputprocesso. Se le richieste ARP sono per lo stesso IP, a causa della frequenza di overflow della tabella ARP, lo switch dovrebbe limitare l'ARP a una volta ogni due secondi. Se le richieste riguardano IP casuali abbastanza frequentemente, la CPU potrebbe aumentare in quanto tale CPU è coinvolta sia nelle richieste che nelle risposte ARP.

Dagli attacchi che ho appreso sugli switch Cisco 3550, 3560 ecc., Puoi trasformarli in hub giganti una volta sovraccaricato il limite dell'indirizzo MAC. Gli switch hanno un limite impostato di indirizzo MAC (circa 6000) che può essere memorizzato e, una volta raggiunto tale limite, invaderà tutti i dati dalle sue interfacce. Non riesco a ricordare se questo vale per i pacchetti 802.1q perché non ho dovuto farlo da molto tempo. Potrebbe essere necessario avviare il mio laboratorio di rete a casa per scoprirlo.