Individuazione della causa della ritrasmissione TCP all'interno di una LAN

25

Ciao abitanti del Server Fault

Ho un problema irritante con una LAN di circa 100 computer, 2 server di dominio Windows e 12 telefoni VoIP. Dalla loro installazione circa un anno fa, ogni settimana o giù di lì, notiamo un telefono VoIP che si ripristina da solo, a volte nel mezzo di una chiamata. Contemporaneamente ci sono spesso segni di temporanea perdita di connessione sui computer: si blocca in explorer durante l'accesso alle condivisioni di rete, errori nel nostro software di amministrazione a causa della perdita di connessione al server di database.

Ho monitorato Wireshark sulla connessione tra il centralino VoIP e il resto della rete. Wireshark raccoglie un gruppo di pacchetti TCP ritrasmessi nei momenti in cui registriamo i riavvii del telefono. Il registro di Wireshark mostra circa 2 gruppi di ritrasmissioni al giorno che vanno da 5 pacchetti a centinaia. Quelli in ciascun cluster sono principalmente tra il PBX e alcuni set di telefoni VoIP, ma non sempre lo stesso set. Spesso le ritrasmissioni contemporaneamente sono verso telefoni collegati allo stesso switch, ma a volte si verificano ritrasmissioni insieme a telefoni alle estremità opposte della rete. Di solito ci sono ritrasmissioni coincidenti nel passaggio del traffico TCP, ad esempio tra macchine client e file server.

I picchi nelle ritrasmissioni e nei ripristini del telefono non sono correlati con quando la rete è pesantemente caricata. Sembrano verificarsi leggermente di più durante il giorno, ma la maggior parte la sera, quando il traffico dovrebbe diminuire. Si verificano ragionevolmente spesso a tarda notte quando la maggior parte dei computer è spenta e il traffico dovrebbe essere più basso.

Hai idee che potrebbero aiutare a diagnosticare la causa di problemi come questo? Una cosa che non ho ancora provato, ma che avrei dovuto, è aggiornare il firmware di tutti gli switch.

networking tcp voip

— surreale
fonte

1

Quale modello cambia? Che aspetto hanno le statistiche sul procuratore, sulla memoria, ecc.? Sei su un dominio di trasmissione? quanto vicino alla velocità massima stai vedendo sulla rete?

— Zypher,

Quale protocollo VoIP stai usando? Inoltre, usando UDP o TCP?

— Chris S,

Tutti gli interruttori sono 3Com: Baseline 2924 - PWR Plus (3CBLSG24PWR) x 2, 4200 (3C17304A) x 3, 4200 (3C17304) x 2, 2824-SPF Plus (3C16487), 2250 plus (3C16476CS). Non credo che forniscano statistiche sul processore o sulla memoria, ma sarei molto felice di imparare diversamente. Sì, siamo su un dominio di trasmissione. Non conosco il throughput, cercherò di misurarlo.

— Surreale,

17

Le ritrasmissioni TCP sono generalmente dovute alla congestione della rete. Cerca un gran numero di pacchetti di trasmissione nel momento in cui si verifica il problema. Se la percentuale di traffico di trasmissione nella tua acquisizione è superiore a circa il 3% del traffico totale catturato, allora hai sicuramente la congestione. Cerca trasmissioni sia a livello fisico (ARP) che a livello di rete (risoluzione dei nomi) sulla rete. Se trovi un volume elevato di traffico di trasmissione, puoi rintracciarlo alla fonte dai dati di acquisizione.

— joeqwerty
fonte

9

Inoltre, le ritrasmissioni TCP non sono la causa del tuo problema, sono un sintomo del problema.

— joeqwerty,

Avrei dovuto menzionare che avevo dato un'occhiata alle trasmissioni UDP e che non erano correlate alle ritrasmissioni. Alcuni degli eventi di ritrasmissione coincidono con picchi nelle trasmissioni UDP, ma la maggior parte no. Ho dato un'altra occhiata e ho scoperto che le trasmissioni UDP non superano l'1,5% del traffico (circa 350 pacchetti) in un intervallo di tempo di 10 minuti, e raggiungere quel livello è raro. Tuttavia, non avevo esaminato le trasmissioni Ethernet. Ora sto eseguendo uno script per filtrare tutti i miei log di WireShark. La regola empirica del 3% per le trasmissioni UDP e le trasmissioni Ethernet è individuale o combinata?

— Surreale,

1

Il 3% non è in realtà una regola empirica. È ciò che mi è stato detto e ciò che ho visto nel mio ambiente. Ho sentito numeri che vanno dal 10 al 20%, ma ho scoperto che una volta che supera il 3 al 5% di solito causa problemi. È necessario esaminare tutto il traffico di trasmissione: Ethernet, rete e trasmissioni multicast, poiché possono causare congestione. Fondamentalmente, il traffico che viene trasmesso a tutte le porte dello switch è il traffico che deve essere analizzato, ridotto o eliminato.

— joeqwerty,

Non ho ancora un bel grafico insieme per verificare una buona correlazione per un lungo periodo, ma le trasmissioni Ethernet sembrano piuttosto promettenti. Un registro in cui vi era la ritrasmissione aveva trasmissioni appena superiori al 3%, un altro circa il 6%. Ho riscontrato almeno un problema: un vecchio server sta emettendo un flusso costante di pacchetti ARP gratuiti.

— Surreale,

1

Ho trovato le voci ARP eccessive usando il filtro Wireshark di arp- e per vedere solo quelle trasmesse, usando un filtro dieth.addr==ff:ff:ff:ff:ff:ff

— mlhDev

2

La raccolta di statistiche sul traffico per i tuoi switch potrebbe mostrare che hai periodi in cui stai funzionando a capacità o quasi. Questo può portare a nuovi tentativi quando le risposte non ritornano entro il timeout iniziale (spesso 3 secondi). Ciò aumenta momentaneamente la congestione fino a quando non entrano in azione i meccanismi di mitigazione della congestione.

Cerca persone che utilizzano streaming media in quanto possono assorbire rapidamente la banda.

Potresti essere in grado di mitigare il problema dei telefoni modellando il traffico. Questo sposta il problema ad altri utenti.

— BillThor
fonte

2

Suona come un loop di spanning tree o una tempesta di trasmissione per me, specialmente se le ritrasmissioni e i problemi sono localizzati nello stesso interruttore (che differisce). Quando succede, quali sono gli stati delle porte sul tuo dispositivo L2? Probabilmente un interruttore difettoso o priorità del bridge radice errate? Problema interessante.

— McJeff
fonte

Grazie per avermi spinto a leggere su spanning tree, di cui sono imbarazzantemente ignaro. Tuttavia, non penso che potrebbe essere un loop spanning tree, perché non abbiamo collegamenti ridondanti nella nostra rete (probabilmente un problema in sé). Per "stati delle porte sul tuo dispositivo L2", ho ragione intendi quali porte sono state abilitate dagli switch come risultato dell'algoritmo spanning tree? Non abbiamo configurato manualmente un root bridge, sarebbe una buona idea farlo?

— Surreale,

Familiarizzare con STP è una buona idea, ma se sei sicuro di non avere collegamenti ridondanti, allora STP non sarà il problema.

— joeqwerty,

Sì, se non si dispone di collegamenti ridondanti, non sarebbe un problema. Per stato delle porte, sì, intendo dire che sono in avanti / bloccati / in fase di apprendimento.

— McJeff,

2

Probabilmente hai risolto questo problema da quando è passato così tanto tempo, ma essenzialmente devi abilitare "port fast" sulle porte che hanno endpoint (telefoni voip, workstation, server). Un telefono può inviare PDU, quindi se quel tipo si riavvia, si verificherà una convergenza STP causando lo svuotamento della tabella FDB e tutti i dispositivi che passano attraverso il divertimento STP a 4/5 fasi. Mettendo le porte con endpoint in "porta veloce" saltano l'attesa e passano direttamente alla modalità di inoltro.

— barak s.
fonte

1

Spero che i tuoi telefoni siano su una sottorete e VLAN diverse dagli altri computer?

— Greg Askew
fonte

No, si trovano sulla stessa sottorete IP e sono abbastanza sicuro anche della stessa VLAN. Questo è un problema serio? Sembra certamente che sarebbe una buona idea. Vedo che separerebbe i domini di trasmissione per i telefoni e tutto il resto. Avrebbe qualche altro vantaggio?

— Surreale,

Sì, metterei sicuramente i telefoni su una VLAN dedicata.

— Greg Askew,

1

Potrebbe anche essere un apparecchio difettoso come un interruttore difettoso. Le ritrasmissioni sono correlate a telefoni / computer su un particolare switch o parte della rete?

Solo per estendere un po 'la mia risposta. Non tutti gli switch sono creati uguali, anche se hanno le stesse specifiche. Alcuni sono in grado di far fronte a un carico molto più elevato rispetto ad altri perché hanno processori più veloci all'interno. È possibile che i tuoi interruttori non siano del tutto all'altezza.

Vorrei iniziare mettendo alcuni dei tuoi telefoni VOIP più problematici sul proprio interruttore fisico e vedere se i ripristini su quelli continuano. Se scompare, sei sulla strada per risolverlo molto presto.

— opaco
fonte

Vorrei che lo facessero. Sembra esserci la maggior parte dei problemi con i dispositivi collegati a due switch, che si trovano alle estremità opposte della rete. Tuttavia, ci sono ritrasmissioni significative ai telefoni anche in altre parti della rete.

— Surreale,