Quali sono le cause dei record ACK duplicati?

19

Stiamo esaminando le acquisizioni di Wireshark da alcuni computer client che mostrano più record ACK duplicati che innesca pacchetti di ritrasmissione e fuori sequenza.

Questi sono mostrati nella seguente schermata. .26 è client e .252 è server.

inserisci qui la descrizione dell'immagine

Cosa causa i record ACK duplicati?

Più background se aiuta:

Stiamo esaminando i problemi di throughput di rete in un determinato sito client. Il problema percepito dal punto di vista dell'interfaccia utente è che i dati vengono trasmessi lentamente nonostante una connessione WAN sottoutilizzata da 1 gbps.

Quasi tutte le macchine client hanno lo stesso problema, testate su più di 20 macchine. Abbiamo trovato due macchine che non presentano il problema. Stiamo identificando ciò che è diverso nella loro configurazione. Abbiamo notato che nelle due macchine che non presentano il problema, abbiamo mai visto al massimo un record ACK duplicato. Le macchine che presentano il problema in genere hanno tre record ACK duplicati. Una notevole differenza è che le macchine che funzionano bene appartengono tutte ai membri del team operativo della rete e tutte le altre macchine sono destinate a dipendenti "regolari". Le macchine dovrebbero essere standard ma gli amministratori di rete potrebbero aver apportato modifiche ai loro sistemi locali, che è un altro aspetto che stiamo cercando.

Abbiamo provato a modificare l' impostazione TcpMaxDupAcks sul server ma il valore di cui abbiamo davvero bisogno è 5 e l'intervallo valido è solo 1-3.

Il server è Windows Server 2003. I client sono tutti Windows XP gestiti dall'azienda. Tutti i client, inclusi i due funzionanti, hanno installato l'antivirus Symantec.

Questo è l'unico sito client su centinaia che ha mostrato questo problema.

pathping mostra 56 ms RTT e costante perdita di pacchetti 0/100 anche dalle macchine problematiche.

Grazie,

Sam

— Sam
fonte

Che tipo di hardware di commutazione del routing è tra i due endpoint?

— SpacemanSpiff

@SpacemanSpiff, c'è un router Cisco ASR 1006.

— Sam,

Il personale IT e i clienti si trovano sulla stessa apparecchiatura di commutazione? Riesci a portare una delle loro macchine nell'area IT e vedere il problema scomparire?

— SpacemanSpiff

25

Nota: suppongo che questa acquisizione sia stata eseguita sul computer client.

Un breve riepilogo sul sequenziamento TCP: TCP fornisce in modo affidabile flussi di byte tra due applicazioni. "In modo affidabile" in questo caso significa che, tra le altre cose, TCP garantisce di non inviare mai dati fuori ordine a un'applicazione in ascolto.

La consegna affidabile e in ordine viene implementata mediante l'uso di numeri progressivi. A ciascun pacchetto in ogni flusso viene assegnato un numero di sequenza a 32 bit (ricordare che TCP è effettivamente due flussi di dati indipendenti, A-> B e B-> A). Se A invia un ACK a B, il valore nel campo ACK è il successivo numero di sequenza A che prevede di vedere da B.

Da quanto sopra, sembra che almeno un segmento TCP inviato dal server al client sia stato perso. I tre ACK duplicati in sequenza sono un tentativo da parte del client di attivare una ritrasmissione rapida . Quando un mittente TCP riceve 3 riconoscimenti duplicati per lo stesso pezzo di dati (ovvero 4 ACK per lo stesso segmento, che non è il pezzo di dati inviato più di recente), si può ragionevolmente supporre che il segmento immediatamente dopo la perdita del segmento ACKed nella rete e si traduce in una ritrasmissione immediata.

In questo caso, la ritrasmissione passa e viene identificata da Wireshark come fuori servizio.

Come menzionato da joeqwerty , la perdita di pacchetti è spesso causata dalla congestione. Potrebbe anche essere il risultato di CRC o altri errori su un collegamento, a causa di una scheda di interfaccia errata, cavo allentato, ecc. Guarderei le statistiche di ogni collegamento lungo il percorso per vedere se ne sono molto utilizzate e / o si verificano numerosi errori.

Se non riesci a vedere nessun candidato ovvio, esegui acquisizioni di pacchetti simultanee in più punti lungo il percorso per cercare di isolare dove si sta verificando la perdita.

Che tipo di connessione WAN è in uso qui? È una linea dedicata? Collegamento VPN MPLS? VPN IPsec su Internet pubblico? Qualcos'altro?

— Murali Suriar
fonte

Grazie per i tuoi commenti Hai ragione, l'acquisizione dei pacchetti viene dal client. Se capisco cosa stai dicendo, gli ACK duplicati non sono il client che fa qualcosa di sbagliato ma in realtà sono un trigger dal client che non ha ricevuto un record diverso (quello dopo gli ACK). È corretto? Quali cose posso esaminare sul PC client che potrebbero causare questo? Se non si tratta di un problema con il PC client, perché dovrebbe apparire in modo coerente su alcuni client e non su altri?

— Sam,

La WAN è "due circuiti punto a punto" tra tre siti sulla costa orientale e il centro-ovest degli Stati Uniti.

— Sam,

È corretto; i DUPACK sono un sintomo della perdita di pacchetti. Per quanto riguarda il motivo per cui il problema si verificherebbe su alcuni client e non su altri, è necessario capire cosa è comune ai client interessati. Sono tutti nello stesso ufficio? Passando attraverso l'infrastruttura di rete comune? (Uno switch o un link?). Una cosa che vale la pena fare è usare mtr(o pathpingsu Windows) su ciascuna delle macchine interessate e vedere se ci sono salti comuni lungo il percorso verso il server che sembrano perdere i pacchetti. Hai un sistema di monitoraggio della rete che puoi utilizzare per esaminare i dati della porta dello switch?

— Murali Suriar,

4

Mentre stai isolando dove si trova il problema, pensa a un dump di pacchetti come solo uno dei sintomi ... Come analogia, se qualcuno entra nell'ufficio del medico con dolori al petto, il dottore non passerà tre ore a indagare sulla natura di il dolore. Trascorre circa due minuti su questo e poi sa che il 95% delle cause sono bruciori di stomaco o angina ... Allo stesso modo, se vedi ACK duplicati, non buca di topo sulle erbacce della traccia immediatamente .

Una volta stabilita la connessione, le prestazioni TCP lente non sono sempre dovute a problemi di rete di transito; a volte viene a causa di limitazioni della CPU del server o del disco ... e occasionalmente a causa di qualche problema su un PC client. Ho inseguito la mia coda per settimane scavando nelle erbacce delle tracce di wirehark solo per arrendermi e trovare il problema relativamente rapidamente con mtr , o guardando altre metriche host come CPU e I / O del disco.

Il primo compito è dimostrare se si tratta di un problema di rete o di livello host. Concentrati sull'invio di traffico reale attraverso la tua rete e dimostra se stai accodando / perdendo / riordinando ^{Nota 1} esso; questa è sempre la linea di fondo per un potenziale problema di rete come questo .

Farei un pingcampionamento per un lungo periodo di tempo (in genere un'ora per me) tra il client e il server mentre si verifica il problema di throughput; per questo puoi usare freeware mtr o ping plotter . Se perdi costantemente pacchetti a un certo punto, e in seguito tutti i luppoli perdono altrettanto o più , allora hai un potenziale sospetto di rete. Tieni presente che il limite di velocità ICMP del dispositivo può far apparire alcuni hop saltando pacchetti in perdita ... ecco perché vuoi cercare una tendenza a partire da quel hop e quelli seguenti.

^{Nota 1} Se si riordina il traffico, questo verrà visualizzato piuttosto rapidamente nel campo Informazioni esperto fornito da WireShark

— Mike Pennington
fonte

Concordo sul fatto che incolpare la rete per impostazione predefinita non sia un buon approccio. La strumentazione in tutto lo stack è sempre una buona pratica. Tuttavia, in questo caso, i DUPACK, i segmenti fuori servizio e quelli ritrasmessi sembrano essere indicativi di una sorta di perdita di rete tra i due endpoint.

— Murali Suriar,

@Murali Suriar, andiamo con la tua affermazione (che ha buone possibilità di avere ragione) ... e poi? Devi isolare perché c'è una perdita di pacchetti. Noi IT siamo misteriosamente innamorati wiresharkal punto che ci piace guardare il microscopio troppo a lungo. Il punto che sto facendo è dare una rapida occhiata a pcap, dopo che è meglio spendere cicli per strumentare la perdita di pacchetti, i cicli della CPU e l'I / O del disco piuttosto che approfondire gli annali di TCP. C'è un tempo per farlo, ma normalmente non è in questa fase di analisi.

— Mike Pennington,

@Mike ha concordato, motivo per cui ho suggerito di cercare errori / informazioni di utilizzo per i dispositivi lungo il percorso come primo passo. Non sono un grande fan della diagnostica basata su ICMP se non per la raggiungibilità. Come dici tu, la limitazione della velocità e ACL / firewall configurati in modo errato possono renderlo inaffidabile; sebbene in una rete aziendale (che suona così), MTR può spesso indicarti la giusta direzione. L'altro problema con MTR è che spesso indica solo un problema; è del tutto possibile che ci siano più guasti lungo il percorso, che non sarai in grado di trovare fino a quando non risolvi il primo.

— Murali Suriar,

Non siamo in disaccordo, ICMP con TTL-stepping non è una panacea e possono esserci più guasti. Tuttavia, nonostante tutti i difetti relativi ai firewall e ai sistemi di bilanciamento del carico, ICMP è la migliore diagnostica remota che abbiamo a meno che non sia possibile eseguire sessioni TCP / UDP strumentate a livello di host sulle porte specifiche dell'applicazione in questione ... anche allora si può solo dire , questa presa sta ritrasmettendo molto ... ma perché? Il 70% delle volte, mi sto ritirando mtro è un problema, e ho risolto i problemi allo stesso modo negli ultimi 15 anni. Una volta che mi sono concentrato su un dispositivo specifico, allora possiamo guardare i contatori di cadute

— Mike Pennington,

1

@Sam: solo un punto relativo alla risoluzione dei problemi di rete: ogni rete ha "problemi". La chiave è determinare se questi problemi stanno causando problemi di prestazioni e / o connettività. Troverai ACK duplicati, ritrasmissioni TCP, trasmissioni, protocolli erranti, ecc. Su ogni rete. Dovresti concentrarti sul volume di ACK duplicati e sugli host più coinvolti nell'invio degli ACK duplicati per determinare se questo è davvero un sintomo di un problema più grande o solo il naturale funzionamento della rete. Se vedo 5 ACK duplicati su 1.000 pacchetti non ho intenzione di pensarci due volte.

— joeqwerty,

3

Vedendo un sacco di [segmento TCP di PDU riassemblata] senza ACK - direi che quegli ACK sono probabilmente mostrati come [TCP Dup ACK ...] a causa del comportamento del riconoscimento selettivo (aka SACK) .

Esempio:

il client invia parti di dati (..., 0,1,2,3,4,5,6, ...)
server acked (0), quindi ricevuto (2,4,3), quindi (5), quindi (6) e mai ottenuto (1)

Nello scenario precedente, il server può legittimamente scegliere di intercettare prima (2-4) intervallo, quindi (2-5) intervallo, quindi (2-6) intervallo. Durante la formazione del pacchetto "(AB) range ack" - il server deve specificare l'ultima parte (0) acked nell'intestazione TCP. Wireshark contrassegna i range-acks (SACK) come [TCP Dup ACK ...] perché tutti quei range-ack hanno lo stesso valore di parte dell'ultimockck nell'intestazione TCP (Ack = 872619 nel tuo caso).

— dubrov
fonte

1

Gli ACK duplicati in combinazione con prestazioni di rete lente mi sembrano un problema di congestione della rete. Guarda il volume e la velocità del traffico di trasmissione sulla rete. Assicurati di guardare le trasmissioni del livello fisico e del livello di rete nonché i multicast.

— joeqwerty
fonte