Apa yang menyebabkan duplikat ACK record?

19

Kami sedang meninjau penangkapan Wireshark dari beberapa mesin klien yang menunjukkan beberapa catatan ACK duplikat yang kemudian memicu pengiriman ulang dan paket tidak sesuai urutan.

Ini ditunjukkan dalam cuplikan layar berikut. .26 adalah klien dan .252 adalah server.

masukkan deskripsi gambar di sini

Apa yang menyebabkan catatan ACK duplikat?

Lebih banyak latar belakang jika membantu:

Kami sedang menyelidiki masalah throughput jaringan di satu situs klien tertentu. Masalah yang dirasakan dari perspektif antarmuka pengguna adalah bahwa data sedang ditransmisikan secara lambat meskipun koneksi WAN 1gbps kurang dimanfaatkan.

Hampir semua mesin klien memiliki masalah yang sama, diuji di lebih dari 20 mesin. Kami memang menemukan dua mesin yang tidak memiliki masalah. Kami sedang dalam proses mengidentifikasi apa yang berbeda dalam konfigurasi mereka. Kami memang memperhatikan bahwa di dua mesin yang tidak memiliki masalah, kami hanya pernah melihat paling banyak satu rekaman ACK duplikat. Mesin yang memiliki masalah biasanya memiliki tiga catatan ACK duplikat. Satu perbedaan penting adalah bahwa mesin yang bekerja dengan baik semuanya milik anggota tim operasi jaringan dan semua mesin lain adalah untuk karyawan "biasa". Mesin-mesin itu seharusnya standar tetapi admin jaringan bisa membuat perubahan pada sistem lokal mereka, yang merupakan aspek lain yang sedang kami teliti.

Kami mencoba mengubah pengaturan TcpMaxDupAcks di server tetapi nilai yang benar-benar kami butuhkan adalah 5 dan rentang yang valid hanya 1-3.

Server adalah Windows Server 2003. Klien adalah semua perusahaan yang dikelola Windows XP. Semua klien, termasuk dua yang bekerja, sudah menginstal anti-virus Symantec.

Ini adalah satu-satunya situs klien dari ratusan yang telah menunjukkan masalah ini.

pathping menunjukkan 56ms RTT dan kehilangan paket 0/100 secara konsisten bahkan dari mesin yang bermasalah.

Terima kasih,

Sam

— Sam
sumber

Apa jenis perangkat keras peralihan yang berada di antara kedua titik akhir?

— SpacemanSpiff

@SpacemanSpiff, ada router Cisco ASR 1006.

— Sam

Apakah staf TI dan klien pada peralatan switching yang sama? Bisakah Anda membawa salah satu mesin mereka ke bidang TI dan melihat masalahnya hilang?

— SpacemanSpiff

25

Catatan: Saya berasumsi bahwa tangkapan ini diambil pada mesin klien.

Ringkasan singkat tentang pengurutan TCP: TCP andal mengirimkan aliran byte antara dua aplikasi. "Andal" dalam hal ini berarti, antara lain, TCP menjamin untuk tidak pernah mengirimkan data yang tidak sesuai pesanan ke aplikasi yang mendengarkan.

Pengiriman pesanan yang andal dilakukan melalui penggunaan nomor urut. Setiap paket dalam setiap aliran diberi nomor urut 32 bit (ingat bahwa TCP secara efektif adalah dua aliran data independen, A-> B dan B-> A). Jika A mengirimkan ACK ke B, nilai dalam bidang ACK adalah urutan nomor A yang diharapkan untuk dilihat dari B.

Dari penjelasan di atas, tampak bahwa setidaknya satu segmen TCP yang dikirim dari server ke klien hilang. Tiga duplikat ACK secara berurutan adalah upaya klien untuk memicu pengiriman ulang cepat . Ketika pengirim TCP menerima 3 duplikat ucapan terima kasih untuk bagian data yang sama (yaitu 4 ACK untuk segmen yang sama, yang bukan bagian data yang terakhir dikirim), ia dapat mengasumsikan bahwa segmen segera setelah segmen ACKed hilang dalam jaringan, dan menghasilkan transmisi ulang segera.

Dalam hal ini, transmisi ulang akan melalui, dan diidentifikasi oleh Wireshark sebagai rusak.

Seperti yang disebutkan oleh joeqwerty , packet loss paling sering disebabkan oleh kemacetan. Mungkin juga merupakan hasil dari CRC atau kesalahan lain pada suatu tautan, karena kartu antarmuka yang buruk, kabel yang longgar, dll. Saya akan melihat statistik setiap tautan di sepanjang jalan untuk melihat apakah ada yang sangat dimanfaatkan dan / atau sedang mengalami sejumlah besar kesalahan.

Jika Anda tidak dapat melihat kandidat yang jelas, lakukan penangkapan paket bersamaan di beberapa titik di sepanjang jalan untuk mencoba dan mengisolasi di mana kerugian terjadi.

Koneksi WAN macam apa yang digunakan di sini? Apakah ini saluran khusus? Tautan MPLS VPN? IPsec VPN melalui internet publik? Sesuatu yang lain

— Murali Suriar
sumber

Terima kasih atas komentar anda Anda benar, paket capture dari klien. Jika saya mengerti apa yang Anda katakan, duplikat ACK bukan klien melakukan sesuatu yang salah tetapi sebenarnya pemicu dari klien bahwa itu tidak menerima catatan yang berbeda (yang setelah ACK). Apakah itu benar? Hal-hal apa yang dapat saya lihat pada PC klien yang akan menyebabkan ini? Jika ini bukan masalah PC klien mengapa itu akan muncul secara konsisten pada beberapa klien dan bukan yang lain?

— Sam

WAN adalah "sirkuit dua titik ke titik" antara tiga lokasi di pantai timur dan Amerika Serikat bagian barat tengah.

— Sam

Itu benar; DUPACK adalah gejala hilangnya paket. Mengenai mengapa masalah ini terjadi pada beberapa klien dan bukan pada yang lain, Anda perlu mencari tahu apa yang umum bagi klien yang terpengaruh. Apakah mereka semua ada di kantor yang sama? Akan melalui infrastruktur jaringan umum? (Sakelar atau tautan?). Satu hal yang patut dilakukan adalah menggunakan mtr(atau pathpingpada Windows) pada masing-masing mesin yang terkena dampak dan melihat apakah ada lompatan umum di sepanjang jalan ke server yang tampaknya mengalami kehilangan paket. Apakah Anda memiliki sistem pemantauan jaringan yang dapat Anda gunakan untuk melihat data port switch?

— Murali Suriar

4

Ketika Anda mengisolasi di mana masalahnya, pikirkan paket dump hanya sebagai salah satu gejala ... Sebagai analogi, jika seseorang berjalan ke kantor dokter dengan sakit dada, dokter tidak akan menghabiskan tiga jam menyelidiki sifat dari rasa sakit. Dia menghabiskan sekitar dua menit untuk itu dan kemudian tahu bahwa 95% penyebabnya adalah mulas atau angina ... Dengan cara yang sama, jika Anda melihat duplikat ACK, jangan langsung berlubang pada gulma jejak segera. .

Setelah koneksi terbentuk, kinerja TCP yang lambat tidak selalu karena masalah jaringan transit; kadang-kadang muncul sebagai akibat dari keterbatasan server CPU atau disk ... dan kadang-kadang karena beberapa masalah pada PC klien. Saya telah mengejar ekor saya selama berminggu-minggu menggali ke dalam gulma jejak wireshark hanya untuk menyerah dan menemukan masalah relatif cepat dengan mtr , atau dengan melihat metrik host lain seperti CPU dan disk I / O.

Tugas pertama Anda adalah membuktikan apakah ini masalah jaringan atau masalah tingkat host. Fokus pada pengiriman lalu lintas nyata melalui jaringan Anda dan buktikan apakah Anda sedang antri / kehilangan / memesan kembali ^{Catatan 1} itu; yang selalu merupakan bottom-line untuk masalah jaringan potensial seperti ini .

Saya akan melakukan pingsampling untuk periode waktu yang lama (biasanya satu jam untuk saya) antara klien dan server sementara masalah throughput terjadi; Anda dapat menggunakan freeware mtr atau ping plotter untuk ini. Jika Anda secara konsisten kehilangan paket pada beberapa hop, dan semua hop kemudian kehilangan sebanyak atau lebih , maka Anda memiliki jaringan yang dicurigai. Ingatlah bahwa pembatasan ICMP perangkat dapat menyebabkan beberapa hop muncul sehingga mereka kehilangan paket ... itu sebabnya Anda ingin mencari tren mulai dari kenaikan itu, dan yang mengikuti.

^{Catatan 1} Jika Anda memesan kembali lalu lintas, itu akan muncul agak cepat di bidang info ahli yang disediakan wireshark

— Mike Pennington
sumber

Setuju bahwa menyalahkan jaringan secara default bukanlah pendekatan yang baik. Menginstruksikan seluruh tumpukan selalu merupakan praktik yang baik. Namun dalam kasus ini, DUPACKs, out-of-order, dan segmen yang ditransmisikan ulang tampaknya menunjukkan semacam kehilangan jaringan antara kedua titik akhir.

— Murali Suriar

@ Surali Suriar, mari kita pergi dengan pernyataan Anda (yang memiliki peluang bagus untuk menjadi benar) ... lalu apa selanjutnya? Anda harus mengisolasi mengapa ada paket yang hilang. Kami, orang-orang IT, secara misterius telah jatuh cinta wiresharksampai-sampai kami sangat suka melihat mikroskop terlalu lama. Poin yang saya buat adalah melihat sekilas pada pcap, setelah itu Anda lebih baik menghabiskan siklus untuk menginstruksikan hilangnya paket, siklus CPU, dan disk I / O daripada mempelajari jauh ke dalam catatan sejarah TCP. Ada waktu untuk melakukan itu, tetapi biasanya tidak pada tahap analisis ini.

— Mike Pennington

@ Mike setuju, itulah sebabnya saya menyarankan mencari kesalahan / informasi pemanfaatan untuk perangkat di sepanjang jalan sebagai langkah pertama. Saya bukan penggemar berat diagnostik berbasis ICMP selain untuk jangkauan. Seperti yang Anda katakan, pembatasan tingkat dan ACL / firewall yang dikonfigurasi secara salah dapat membuatnya tidak dapat diandalkan; meskipun dalam jaringan perusahaan (yang kedengarannya seperti ini), MTR sering dapat mengarahkan Anda ke arah yang benar. Masalah lain dengan MTR adalah bahwa hal itu sering hanya menunjuk pada satu masalah; sangat mungkin bahwa ada beberapa kesalahan di sepanjang jalan, yang Anda tidak akan dapat menemukannya sampai Anda memperbaiki yang pertama.

— Murali Suriar

Kami tidak setuju, ICMP dengan TTL-stepping bukan obat mujarab dan bisa ada banyak kesalahan. Namun, untuk semua kekurangan yang berhubungan dengan firewall dan load-balancers, ICMP adalah diagnostik jarak jauh terbaik yang kami miliki kecuali Anda dapat menjalankan sesi instrument TCP / UDP tingkat host pada port aplikasi tertentu yang dipermasalahkan ... bahkan kemudian Anda hanya bisa mengatakan , soket ini sedang mengirim ulang banyak ... tapi mengapa? 70% dari waktu, saya menarik mtratau itu sejenisnya, dan saya telah memecahkan masalah dengan cara yang sama selama 15 tahun terakhir. Setelah saya fokus pada perangkat tertentu, maka kita dapat melihat penghitung drop

— Mike Pennington

1

@ Sam: Hanya satu hal tentang pemecahan masalah jaringan: setiap jaringan memiliki "masalah". Kuncinya adalah menentukan apakah masalah itu menyebabkan masalah kinerja dan / atau konektivitas. Anda akan menemukan duplikat ACK, TCP Retransmits, siaran, protokol yang salah, dll di setiap jaringan. Anda harus fokus pada volume ACK duplikat dan host yang paling terlibat dalam mengirimkan ACK duplikat untuk menentukan apakah itu benar-benar merupakan gejala dari masalah yang lebih besar atau hanya operasi alami jaringan. Jika saya melihat 5 duplikat ACK dari 1.000 paket saya tidak akan memikirkannya lagi.

— joeqwerty

3

Dengan melihat banyak [segmen TCP dari PDU yang dipasang kembali] tanpa ACK - Saya akan mengatakan bahwa ACK tersebut kemungkinan ditampilkan sebagai [TCP Dup ACK ...] karena perilaku Pengakuan Selektif (alias SACK) .

Contoh:

klien mengirimkan bagian data (..., 0,1,2,3,4,5,6, ...)
server menerima (0), lalu menerima (2,4,3), lalu (5), lalu (6) dan tidak pernah mendapat (1)

Dalam skenario di atas - server dapat secara sah memilih untuk mengambil rentang (2-4) pertama, kemudian kisaran (2-5), kemudian (2-6) kisaran. Ketika membentuk paket "(AB) range ack" - server harus menentukan bagian terakhir yang diakhiri (0) di header TCP. Wireshark menandai rentang-acks (SACK) sebagai [TCP Dup ACK ...] karena semua rentang-acks tersebut memiliki nilai bagian yang terakhir-acked yang sama di tajuk TCP (Ack = 872619 dalam kasus Anda).

— dubrov
sumber

1

Duplikat ACK dalam kombinasi dengan kinerja jaringan yang lambat terdengar seperti masalah kemacetan jaringan bagi saya. Lihatlah volume dan tingkat lalu lintas siaran di jaringan. Pastikan untuk melihat siaran layer fisik dan layer jaringan serta multicast.

— joeqwerty
sumber