Menemukan penyebab pengiriman ulang TCP dalam LAN


25

Halo penghuni dari Kesalahan Server

Saya memiliki masalah menjengkelkan dengan LAN sekitar 100 komputer, 2 server domain Windows, dan 12 telepon VoIP. Sejak instalasi mereka sekitar setahun yang lalu, setiap minggu atau lebih, kami melihat telepon VoIP me-reset sendiri - kadang-kadang di tengah panggilan. Secara bersamaan sering ada tanda-tanda kehilangan koneksi sementara pada komputer: membeku di explorer saat mengakses saham jaringan, kesalahan dalam perangkat lunak administrasi kami karena kehilangan koneksi ke server database.

Saya telah melakukan beberapa pemantauan Wireshark pada koneksi antara VoIP PBX dan seluruh jaringan. Wireshark mengambil setumpuk paket TCP yang dikirimkan kembali pada saat kami merekam telepon restart. Log Wireshark menunjukkan sekitar 2 cluster pengiriman ulang sehari mulai dari 5 paket hingga ratusan. Yang ada di setiap cluster terutama antara PBX dan beberapa set telepon VoIP, tetapi tidak selalu set yang sama. Seringkali transmisi ulang pada saat yang sama ditujukan ke telepon yang terhubung ke sakelar yang sama, tetapi kadang-kadang transmisi ulang terjadi bersamaan pada ponsel di ujung jaringan yang berlawanan. Biasanya ada beberapa transmisi ulang bertepatan dalam melewati lalu lintas TCP, misalnya antara mesin klien dan server file.

Lonjakan transmisi ulang dan reset telepon tidak berkorelasi dengan baik ketika jaringan dimuat dengan berat. Mereka tampaknya terjadi sedikit lebih banyak pada siang hari, tetapi sebagian besar di malam hari, ketika lalu lintas harus menurun. Mereka terjadi cukup sering larut malam ketika sebagian besar komputer dimatikan dan lalu lintas harus terendah.

Apakah Anda punya ide yang dapat membantu mendiagnosis penyebab masalah seperti ini? Satu hal yang belum saya coba, tetapi seharusnya saya lakukan adalah memperbarui firmware semua sakelar.


1
Apa model yang beralih? Bagaimana tampilan statistik proses, memeory, dll? Apakah Anda menggunakan satu domain siaran? seberapa dekat dengan throughput maks yang Anda lihat di jaringan?
Zypher

Protokol VoIP apa yang Anda gunakan? Juga, menggunakan UDP atau TCP?
Chris S

Semua sakelar adalah 3Com: Baseline 2924 - PWR Plus (3CBLSG24PWR) x 2, 4200 (3C17304A) x 3, 4200 (3C17304) x 2, 2824-SPF Plus (3C16487), 2250 plus (3C16476CS). Saya tidak berpikir mereka memberikan statistik pada prosesor atau memori, tetapi saya akan sangat senang mengetahui sebaliknya. Ya, kami berada di satu domain siaran. Saya tidak tahu tentang throughput, saya akan melihat ke mengukurnya.
Surreal

Jawaban:


17

Transmisi ulang TCP biasanya disebabkan oleh kemacetan jaringan. Cari sejumlah besar paket siaran pada saat masalah terjadi. Jika persentase lalu lintas siaran dalam tangkapan Anda di atas sekitar 3% dari total lalu lintas yang ditangkap, maka Anda pasti mengalami kemacetan. Cari siaran layer fisik (ARP) dan layer jaringan (resolusi nama) di jaringan. Jika Anda menemukan volume lalu lintas siaran yang tinggi, Anda dapat melacaknya ke sumber dari data penangkapan.


9
Selain itu, transmisi ulang TCP bukanlah penyebab masalah Anda, itu adalah gejala dari masalah tersebut.
joeqwerty

Saya seharusnya menyebutkan bahwa saya telah melihat siaran UDP dan mereka tidak berkorelasi dengan transmisi ulang. Beberapa acara pengiriman ulang bertepatan dengan lonjakan siaran UDP, tetapi sebagian besar tidak. Saya telah melihat lagi dan menemukan bahwa siaran UDP tidak melebihi 1,5% dari lalu lintas (sekitar 350 paket) dalam segmen waktu 10 menit, dan mencapai tingkat itu jarang terjadi. Namun saya belum melihat siaran ethernet. Saya menjalankan skrip sekarang untuk memfilter semua log wireshark saya. Apakah 3% aturan praktis untuk siaran UDP dan siaran ethernet secara individual atau gabungan?
Surreal

1
3% bukanlah aturan praktis. Itu yang saya tahu dan lihat di lingkungan saya sendiri. Saya pernah mendengar angka mulai dari 10 hingga 20% tetapi saya menemukan bahwa setelah melebihi 3 hingga 5% biasanya menyebabkan masalah. Anda perlu melihat semua lalu lintas siaran: ethernet, jaringan, dan siaran multicast, karena semuanya dapat menyebabkan kemacetan. Pada dasarnya setiap lalu lintas yang disiarkan ke semua port switch adalah lalu lintas yang perlu dianalisis dan dikurangi atau dihilangkan.
joeqwerty

Saya masih belum mendapatkan grafik yang bagus untuk memeriksa korelasi yang baik dalam jangka waktu yang lama, tetapi siaran ethernet terlihat cukup menjanjikan. Satu log di mana ada pengiriman ulang hanya di atas 3% siaran, yang lain sekitar 6%. Saya telah menemukan satu masalah setidaknya: server lama mengeluarkan aliran konstan paket ARP serampangan.
Surreal

1
Saya menemukan entri ARP yang berlebihan menggunakan filter Wireshark arp- dan untuk melihat yang siaran saja, menggunakan filtereth.addr==ff:ff:ff:ff:ff:ff
mlhDev

2

Mengumpulkan statistik lalu lintas untuk sakelar Anda mungkin menunjukkan bahwa Anda memiliki periode di mana Anda menjalankan pada atau mendekati kapasitas. Ini dapat menyebabkan pengulangan ketika respons tidak kembali dalam batas waktu inital (sering 3 detik). Ini meningkatkan kemacetan sejenak sampai mekanisme mitigasi kemacetan dimulai

Cari orang yang menggunakan media streaming karena dapat menyerap bandwidth dengan cepat.

Anda mungkin dapat mengurangi masalah untuk ponsel dengan membentuk lalu lintas. Ini hanya akan memindahkan masalah ke pengguna lain.


2

Kedengarannya seperti spanning tree loop atau badai siaran kepada saya, terutama jika transmisi ulang dan masalah dilokalkan ke saklar yang sama (yang berbeda). Ketika itu terjadi, apa status port pada perangkat L2 Anda? Mungkin saklar buruk atau prioritas jembatan akar buruk? Masalah menarik.


Terima kasih telah mendorong saya untuk membaca tentang merentangkan pohon, tentang yang saya sangat memalukan. Namun saya tidak berpikir itu bisa menjadi spanning tree loop, karena kami tidak memiliki tautan yang berlebihan di jaringan kami (mungkin masalah itu sendiri). Dengan "status port pada perangkat L2 Anda", apakah saya benar maksud Anda port mana yang diaktifkan sebagai akibat dari algoritma spanning tree? Kami belum mengkonfigurasi jembatan root secara manual, apakah itu ide yang baik untuk melakukannya?
Surreal

Membiasakan diri dengan STP adalah ide yang bagus, tetapi jika Anda yakin tidak memiliki tautan yang berlebihan, maka STP tidak akan menjadi masalah.
joeqwerty

Ya, jika Anda tidak memiliki tautan berlebihan, itu tidak akan menjadi masalah. Dengan status port, ya, maksud saya yang maju / diblokir / belajar.
McJeff

2

Anda mungkin telah memecahkan ini karena sudah begitu lama tetapi pada dasarnya Anda perlu mengaktifkan "port fast" pada port yang memiliki titik akhir (telepon voip, workstation, server). Telepon dapat mengirim PDU jadi jika orang itu reboot, itu akan menyebabkan konvergensi STP terjadi sehingga menyebabkan tabel FDB memerah dan semua perangkat melalui 4/5 langkah STP menyenangkan. Dengan menempatkan port dengan titik akhir di "port fast", mereka melewatkan waktu tunggu dan langsung ke mode penerusan.


1

Semoga ponsel Anda menggunakan subnet dan VLAN yang berbeda dari komputer lain?


Tidak, mereka berada di subnet IP yang sama, dan saya cukup yakin VLAN yang sama juga. Apakah ini masalah serius? Sepertinya itu ide yang bagus. Saya bisa melihatnya akan memisahkan domain siaran untuk ponsel dan yang lainnya. Apakah ada kelebihan lain?
Surreal

Ya saya pasti akan meletakkan ponsel pada VLAN khusus.
Greg Askew

1

Itu juga bisa menjadi peralatan yang rusak seperti sakelar yang rusak. Apakah pengiriman ulang berkorelasi dengan telepon / komputer pada satu saklar tertentu atau bagian dari jaringan?

Hanya untuk sedikit memperluas jawaban saya. Tidak semua switch dibuat sama, bahkan jika mereka memiliki spesifikasi yang sama. Beberapa mampu mengatasi beban yang jauh lebih tinggi daripada yang lain karena mereka memiliki prosesor yang lebih cepat di dalam. Bisa jadi sakelar Anda tidak cukup bagus.

Saya akan mulai dengan meletakkan beberapa telepon VOIP Anda yang paling menyusahkan ke saklar fisik mereka sendiri dan melihat apakah pengaturan ulang pada mereka berlanjut. Jika itu hilang maka Anda akan segera menyelesaikannya.


Saya berharap mereka melakukannya. Tampaknya ada sebagian besar masalah dengan perangkat yang terhubung ke dua switch, yang berada di ujung jaringan. Namun ada transmisi ulang yang signifikan ke ponsel di bagian lain jaringan juga.
Surreal
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.