Problema di velocità effettiva di rete (relativo all'ARP)


9

Il piccolo college in cui lavoro ha problemi di rete molto strani. Sto cercando consigli o idee qui. Siamo stati bene durante l'estate, ma il problema è iniziato pochi giorni dopo che gli studenti sono tornati al campus in vigore per l'autunno.

Sintomi

Il sintomo principale è che l'accesso a Internet funzionerà, ma è molto lento ... spesso al punto di timeout. Ad esempio, un risultato tipico di Speedtest.net restituirà il download di 4 Mbps, ma consentirà una velocità di upload da 3 a 8 Mbps. Sintomi minori possono includere prestazioni notevolmente limitate nel trasferimento dei dati da e verso il nostro file server, o anche in alcuni casi l'impossibilità di accedere al computer (impossibile raggiungere il controller di dominio). Il problema attraversa più vlan e ha interessato i dispositivi su quasi tutti i vlan in cui operiamo.

Il problema non ha alcun impatto su tutte le macchine della rete. Una macchina non interessata in genere vedrà download di almeno 11 Mbps da speedtest.net, e forse molto di più a seconda dei modelli di traffico del campus più grandi in quel momento.

C'è una variazione sul problema più grande. Abbiamo un vlan in cui gli utenti non sono stati in grado di accedere a quasi tutte le macchine. Il personale IT accedeva utilizzando un account amministratore locale (o in alcuni casi credenziali memorizzate nella cache) e da lì un rilascio / rinnovo o il ping del gateway avrebbe permesso alla macchina di funzionare ... per un po '. A complicare questo problema è che questo vlan copre i nostri laboratori informatici, che utilizzano un software chiamato Deep Freeze per ripristinare completamente i dischi rigidi dopo un riavvio. Potrebbe essere lo stesso problema che si manifesta in modo diverso a causa di dati obsoleti su macchine che non hanno modificato in modo permanente informazioni di basso livello per settimane. Siamo stati in grado di risolverlo, tuttavia, creando un nuovo vlan e spostando i laboratori nel nuovo vlan wholesale.

istigazioni

Alla fine abbiamo notato che le macchine interessate avevano tutte recenti contratti di locazione di dhcp. Siamo in grado di prevedere quando una macchina diventerà "lenta" osservando quando un contratto di locazione dhcp arriva per il rinnovo. Abbiamo giocato con tempi di leasing molto brevi per un test vlan, ma tutto ciò che è stato rimosso è stata la nostra capacità di prevedere quando la macchina sarebbe diventata lenta. Le macchine con IP statici hanno praticamente sempre funzionato normalmente. Rilasciare / rinnovare manualmente un indirizzo non farà mai rallentare una macchina. In effetti, in alcuni casi questo processo è stato risoltouna macchina in quello stato. Il più delle volte, però, non aiuta. Abbiamo anche notato che le macchine mobili come i laptop rischiano di rallentare quando attraversano nuovi vlan. Il wireless nel campus è suddiviso in "zone", dove ogni zona è mappata a un piccolo insieme di edifici. Trasferirsi in un nuovo edificio può metterti in una zona, facendoti così ottenere un nuovo indirizzo. Anche una macchina che riprende dalla modalità di sospensione è molto lenta.

Fattori attenuanti

A volte, ma non sempre, svuotare la cache arp su una macchina interessata consentirà che funzioni di nuovo normalmente. Come già accennato, il rilascio / il rinnovo dell'indirizzo IP di una macchina locale può risolvere tale macchina, ma non è garantito. Il ping del gateway predefinito a volte può anche aiutare con una macchina lenta.

Ciò che sembra aiutare di più a mitigare il problema è svuotare la cache arp sul nostro switch core di livello 3. Questo switch viene utilizzato per il nostro sistema dhcp come gateway predefinito su tutti i vlan e gestisce il routing inter-vlan. Il modello è un 3Com 4900SX. Per tentare di mitigare il problema, abbiamo impostato il timeout della cache sull'interruttore fino al minor tempo possibile, ma non ha aiutato. Ho anche messo insieme uno script che viene eseguito ogni pochi minuti per connettersi automaticamente allo switch e ripristinare la cache. Sfortunatamente, questo non funziona sempre e può anche causare il rallentamento di alcune macchine in uno stato lento per un breve periodo (anche se questi sembrano correggersi dopo pochi minuti). Al momento abbiamo un lavoro pianificato che viene eseguito ogni 10 minuti per forzare il core switch a svuotare la cache ARP, ma questo è tutt'altro che perfetto o desiderabile.

Riproduzione

Ora abbiamo una macchina di prova che possiamo forzare allo stato lento a piacimento. È collegato a uno switch con porte configurate per ciascuno dei nostri vlan. Rallentiamo la macchina connettendoci a diversi Vlan e dopo una nuova connessione o due sarà lenta.

Vale anche la pena notare in questa sezione che ciò è accaduto prima all'inizio di termini precedenti, ma in passato il problema è scomparso da solo dopo alcuni giorni. Si è risolto da solo prima che avessimo la possibilità di fare molto lavoro diagnostico ... quindi perché gli abbiamo permesso di trascinare così a lungo il termine questa volta; l'aspettativa era che questa sarebbe stata una situazione di breve durata.

Altri fattori

Vale la pena ricordare che nell'ultimo anno abbiamo avuto circa una mezza dozzina di interruttori. Si tratta principalmente di 3Com dell'era 2003-2004 (per lo più 4200) che sono stati messi tutti nello stesso momento. Dovrebbero comunque essere coperti da garanzia, acquistare HP ha reso un po 'difficile ottenere assistenza. Principalmente negli alimentatori che hanno fallito, ma in un paio di casi abbiamo usato un alimentatore da un interruttore con una scheda madre guasta per riportare in vita un interruttore con un alimentatore guasto. Al momento disponiamo di dispositivi UPS su tutti tranne tre su quattro interruttori, ma non è stato così quando ho iniziato due anni e mezzo fa. Gravi vincoli di bilancio (un paio di anni fa eravamo nella lista delle istituzioni con problemi finanziari del Dipartimento di Ed) mi hanno costretto a cercare sostituti di Netgear e TrendNet per sostituzioni,

Vale anche la pena ricordare che il grande cambiamento sulla nostra rete questa estate stava migrando da un singolo SSID wireless tra campus e all'approccio suddiviso in zone menzionato in precedenza. Non penso che questa sia la fonte del problema, come ho detto: l'abbiamo già visto prima. Tuttavia, è possibile che ciò stia esacerbando il problema e potrebbe essere la ragione per cui è stato così difficile isolarlo.

Diagnosi

All'inizio ci è sembrato chiaro, data la tempistica e la natura persistente del problema, che la fonte del problema fosse una macchina studente infetta (o dannosa) che stava facendo avvelenare la cache ARP. Tuttavia, ripetuti tentativi di isolare la fonte non sono riusciti. Tali tentativi includono numerose tracce di pacchetti di wirehark e persino la messa in linea di interi edifici per brevi periodi. Non siamo stati nemmeno in grado di trovare una voce ARP male da arma da fumo. La mia ipotesi attuale è un interruttore principale sovraccarico o difettoso, ma non sono sicuro su come testare questo, e il costo per sostituirlo alla cieca è ripido.

Ancora una volta, tutte le idee sono state apprezzate.

Aggiornamento: l'
interruttore principale viene sostituito. Dopo 4 giorni, tutto procede bene ... ma aspetterò il segno di due settimane prima di chiamare il problema risolto.


Vedi perdita di pacchetti sui computer interessati? In tal caso, dove si verifica la perdita di pacchetti? mtrpuò essere utile qui.
SEE

3
Sembra sospettosamente che uno dei tuoi switch sia difettoso, corrompendo le sue tabelle arp e propagando le voci corrotte agli altri switch. Da qui il parziale sollievo quando le tabelle vengono cancellate sul nucleo L3. Consiglio vivamente di ripristinare TUTTI gli switch prima di ulteriori tentativi di risoluzione dei problemi. Con un po 'di fortuna questo risolve del tutto il problema. Se un interruttore è veramente difettoso, si spera che non riesca a diagnosticare l'accensione dopo il riavvio. PS Lievi fluttuazioni nella rete elettrica possono avere questo effetto. Se i tuoi interruttori non sono su UPS, ciò potrebbe essere la causa principale.
Tonny,

@ErikA abbiamo qualche perdita di pacchetti. Vedrò se riesco a ottenere una traccia migliore ... ma la perdita di pacchetti proviene da ogni posizione nel campus, il che significa che l'unico punto di connessione comune è lo switch principale e lo switch collegato ai nostri server.
Joel Coel,

1
@Tonny Abbiamo ripristinato tutti (bene, quasi tutti) gli switch almeno due volte durante la risoluzione dei problemi. Ciò sembrava ridurre (non eliminare) i reclami per circa un giorno / giorno e mezzo. Abbiamo circa 40 unità di commutazione, con dispositivi UPS per tutti tranne tre o quattro. La cosa principale qui è che tutti i nostri switch sono stati installati all'incirca nello stesso momento, e abbiamo avuto 6 veri e propri guasti nell'ultimo anno, quindi c'è molta credibilità in questo.
Joel Coel,

1
Non ho alcuna esperienza con 3com, ma forse c'è un modo per limitare il numero di indirizzi mac appresi da una determinata porta. Potresti farlo su tutte le porte di accesso per le macchine degli studenti nel caso in cui qualcuno stia inondando i mac trasformando i tuoi switch in hub.
Bad Dos

Risposte:


2

Gioele,

Dal momento che hai impostato i trunk e puoi duplicare il problema a piacimento. Installa Wireshark su un laptop e rispondi / estendi una porta uplink. Se vedi la velocità dei pacchetti oltre 10.000 o l'utilizzo della porta vicino alla velocità massima, hai problemi.

Potresti avere un problema hardware / spanning tree non valido. Normalmente ho trovato gli utenti che collegano entrambe le schede di rete sul proprio computer "per ottenere più throughput".

Normalmente per i problemi di Spanning tree è possibile attivare il rilevamento loop o la trasmissione limitando per porta dal proprio fornitore. Questo ucciderà qualsiasi porta con un loop trovato. Puoi anche attivare la "protezione bpdu" che significa disabilitare la porta su cui è stato ricevuto bpdu e lanciare un errore ai ricevitori trap syslog / snmp.

Joe


1

Ho già visto problemi simili a questo ed è stato un loop nella LAN, che causa caos e saturazione dell'intera sottorete (presumibilmente dal traffico di trasmissione a causa dello switch che vede il proprio MAC su una porta aggiuntiva).

EDIT: Inoltre, questo è comune negli istituti scolastici (due dei miei precedenti lavori di amministratore di sistema) poiché ai piccoli cari piace scherzare con cavi / prese patch ...


Abbiamo passato molto tempo a controllare esattamente questo, ma alla fine lo abbiamo escluso.
Joel Coel,

0

Mi sembra che tu abbia dell'hardware difettoso che causa tempeste di trasmissione. Usa Wireshark per guardare le trasmissioni e trovare un host che ti dia problemi ...


È molto improbabile che ciò avvenga se alcune macchine funzionano bene e altre no. Una tempesta di trasmissione metterà in ginocchio l'intera VLAN in pochissimo tempo.
Paul Gear,

0

L'idea di Joe è buona, ma dato che non è probabile che si tratti di una tempesta di trasmissione che crea il tuo problema (penso che tu sia sulla buona strada con avvelenamento da cache ARP o un problema simile; potrebbe anche essere un conflitto di indirizzi IP), probabilmente non risolverà il problema.

Una tecnica correlata per utilizzare l'ispezione dinamica ARP e DHCP, se i tuoi switch lo supportano. Se lo si attiva, gli switch controlleranno le transazioni DHCP e consentiranno solo le voci ARP che corrispondono alle voci conosciute nel database DHCP o a quelle che sono state specificate manualmente.

Se i tuoi switch non hanno questa funzione, un'altra opzione per rintracciarla è l'utility Linux arpwatch: tiene traccia di tutte le richieste ARP e ti dice quando nota una modifica della mappatura IP-MAC.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.