Masalah throughput jaringan (terkait ARP)

Perguruan kecil tempat saya bekerja mengalami beberapa masalah jaringan yang sangat aneh. Saya mencari saran atau ide di sini. Kami baik-baik saja selama musim panas, tetapi masalah mulai beberapa hari setelah mahasiswa kembali ke kampus untuk musim gugur.

Gejala

Gejala utama adalah bahwa akses internet akan berfungsi, tetapi sangat lambat ... sering sampai batas waktu. Sebagai contoh, hasil khas dari Speedtest.net akan mengembalikan unduhan .4Mbps, tetapi memungkinkan kecepatan unggah 3 hingga 8 Mbps. Gejala yang lebih kecil dapat mencakup kinerja yang sangat terbatas mentransfer data ke dan dari server file kami, atau bahkan dalam beberapa kasus ketidakmampuan untuk masuk ke komputer (tidak dapat mencapai pengontrol domain). Masalahnya melintasi beberapa vlan, dan telah mempengaruhi perangkat di hampir setiap vlan yang kami operasikan.

Masalah ini tidak berdampak pada semua mesin di jaringan. Mesin yang tidak terpengaruh biasanya akan melihat setidaknya 11Mbps unduhan dari speedtest.net, dan mungkin lebih tergantung pada pola lalu lintas kampus yang lebih besar pada saat itu.

Ada satu variasi pada masalah yang lebih besar. Kami memiliki satu vlan di mana pengguna tidak dapat masuk ke hampir semua mesin sama sekali. Staf TI akan masuk menggunakan akun administrator lokal (atau dalam beberapa kasus kredensial di-cache), dan dari sana rilis / perpanjang atau ping gateway akan memungkinkan mesin bekerja ... untuk sementara waktu. Yang menyulitkan masalah ini adalah bahwa vlan ini mencakup laboratorium komputer kami, yang menggunakan perangkat lunak bernama Deep Freeze untuk sepenuhnya mereset hard drive setelah reboot. Itu bisa saja masalah yang sama memanifestasikan berbeda karena data basi pada mesin yang belum secara permanen mengubah informasi tingkat rendah selama berminggu-minggu. Kami dapat menyelesaikan ini, bagaimanapun, dengan menciptakan vlan baru dan memindahkan laboratorium ke grosir vlan baru.

Hasutan

Akhirnya kami memperhatikan bahwa semua mesin yang terkena dampak memiliki sewa dhcp baru-baru ini. Kita bisa memprediksi kapan mesin akan menjadi "lambat" dengan menonton ketika sewa dhcp muncul untuk pembaruan. Kami bermain dengan mengatur waktu sewa sangat singkat untuk test vlan, tetapi semua yang dilakukan adalah menghilangkan kemampuan kami untuk memprediksi kapan mesin akan menjadi lambat. Mesin dengan IP statis hampir selalu berfungsi dengan normal. Secara manual melepaskan / memperbarui alamat tidak akan pernah menyebabkan mesin menjadi lambat. Bahkan, dalam beberapa kasus proses ini telah diperbaikisebuah mesin di negara itu. Namun, sebagian besar waktu, itu tidak membantu. Kami juga memperhatikan bahwa mesin seluler seperti laptop cenderung menjadi lambat ketika mereka beralih ke vlan baru. Nirkabel di kampus dibagi menjadi "zona", di mana setiap zona memetakan ke sekelompok kecil bangunan. Pindah ke gedung baru dapat menempatkan Anda di zona, sehingga menyebabkan Anda mendapatkan alamat baru. Mesin yang melanjutkan dari mode tidur juga sangat mungkin lambat.

Mitigasi

Kadang-kadang, tetapi tidak selalu, membersihkan cache arp pada mesin yang terpengaruh akan memungkinkannya berfungsi secara normal lagi. Seperti yang telah disebutkan, melepaskan / memperbarui alamat IP mesin lokal dapat memperbaiki mesin itu, tetapi tidak dijamin. Ping gateway default juga kadang-kadang dapat membantu dengan mesin yang lambat.

Apa yang tampaknya paling membantu mengurangi masalah ini adalah membersihkan cache arp pada switch layer 3 inti kami. Switch ini digunakan untuk sistem dhcp kami sebagai gateway default pada semua vlan, dan menangani perutean antar-vlan. Model ini adalah 3Com 4900SX. Untuk mencoba mengurangi masalah ini, kami memiliki batas waktu cache yang disetel pada sakelar sepenuhnya ke waktu serendah mungkin, tetapi itu tidak membantu. Saya juga mengumpulkan skrip yang berjalan setiap beberapa menit untuk terhubung secara otomatis ke sakelar dan mengatur ulang cache. Sayangnya, ini tidak selalu berhasil, dan bahkan dapat menyebabkan beberapa mesin berakhir dalam keadaan lambat untuk waktu yang singkat (meskipun ini tampaknya dapat memperbaiki diri sendiri setelah beberapa menit). Kami saat ini memiliki pekerjaan terjadwal yang berjalan setiap 10 menit untuk memaksa sakelar inti menghapus cache ARP-nya, tetapi ini masih jauh dari sempurna atau diinginkan.

Reproduksi

Kami sekarang memiliki mesin uji yang dapat kami paksa masuk ke kondisi lambat sesuai keinginan. Terhubung ke switch dengan port yang diatur untuk masing-masing vlan kami. Kami membuat mesin lambat dengan menghubungkan ke vlan yang berbeda, dan setelah satu atau dua koneksi baru itu akan lambat.

Penting juga dicatat di bagian ini bahwa ini telah terjadi sebelumnya pada awal persyaratan sebelumnya, tetapi di masa lalu masalahnya telah hilang dengan sendirinya setelah beberapa hari. Itu memecahkan sendiri sebelum kami memiliki kesempatan untuk melakukan banyak pekerjaan diagnostik ... karena itu mengapa kami membiarkannya begitu lama dalam jangka waktu kali ini; harapannya adalah ini akan menjadi situasi yang berumur pendek.

Faktor lain

Perlu disebutkan bahwa kami memiliki sekitar setengah lusin switch yang gagal total selama setahun terakhir. Ini terutama 3Com era 2003/2004 (kebanyakan 4200-an) yang semuanya dimasukkan pada waktu yang hampir bersamaan. Mereka masih harus dicakup dalam garansi, membeli HP telah membuat mendapatkan layanan agak sulit. Sebagian besar pasokan listrik telah gagal, tetapi dalam beberapa kasus kami telah menggunakan catu daya dari sakelar dengan mainboard yang gagal untuk menghidupkan kembali catu daya yang gagal. Kami memiliki perangkat UPS pada semua kecuali tiga dari empat sakelar sekarang, tetapi itu tidak terjadi ketika saya memulai dua setengah tahun yang lalu. Kendala anggaran yang parah (kami berada di Dept dari daftar lembaga yang mengalami kesulitan keuangan Ed beberapa tahun yang lalu) telah memaksa saya untuk mencari orang-orang seperti Netgear dan TrendNet untuk penggantian,

Perlu juga disebutkan bahwa perubahan besar pada jaringan kami musim panas ini bermigrasi dari SSID nirkabel lintas-kampus tunggal ke pendekatan yang dikategorikan sebelumnya. Saya kira ini bukan sumber masalahnya, seperti yang saya katakan: kita pernah melihat ini sebelumnya. Namun, mungkin ini memperburuk masalah ini, dan mungkin banyak alasan mengapa sangat sulit untuk diisolasi.

Diagnosa

Pada awalnya tampak jelas bagi kami, mengingat waktu dan sifat masalah yang terus-menerus, bahwa sumber masalah adalah mesin siswa yang terinfeksi (atau jahat) yang melakukan keracunan cache ARP. Namun, upaya berulang untuk mengisolasi sumber telah gagal. Upaya-upaya itu termasuk banyak jejak paket wireshark, dan bahkan membuat seluruh bangunan offline untuk periode singkat. Kami bahkan belum dapat menemukan entri ARP yang buruk untuk merokok. Tebakan terbaik saya saat ini adalah sakelar inti yang kelebihan beban atau gagal, tetapi saya tidak yakin bagaimana cara menguji ini, dan biaya untuk menggantinya secara membabi buta adalah curam.

Sekali lagi, setiap ide dihargai.

Pembaruan:
Sakelar inti diganti. Setelah 4 hari, semuanya berjalan dengan baik ... tapi saya akan menunggu tanda dua minggu sebelum menyelesaikan masalah.

Joel,

Karena Anda memiliki pengaturan batang dan dapat menduplikasi masalah sesuka hati. Instal Wireshark di laptop dan mirror / span port uplink. Jika Anda melihat kecepatan paket lebih dari 10.000 atau pemanfaatan port mendekati kecepatan maksimal, Anda memiliki masalah.

Anda mungkin memiliki masalah perangkat keras / spanning tree yang buruk. Biasanya saya telah menemukan pengguna memasukkan kedua NIC di mesin mereka "untuk mendapatkan lebih banyak throughput".

Biasanya untuk masalah Spanning tree Anda dapat mengaktifkan Loop detect atau broadcast limiting on per port dari vendor Anda. Ini akan membunuh port apa pun dengan loop ditemukan. Anda juga dapat mengaktifkan "perlindungan bpdu" yang berarti untuk menonaktifkan port tempat bpdu diterima dan melempar kesalahan ke penerima perangkap syslog / snmp.

Joe

Saya telah melihat masalah yang mirip dengan ini sebelumnya dan telah menjadi loop di LAN, yang menyebabkan kekacauan dan saturasi seluruh subnet (mungkin dari lalu lintas siaran karena saklar melihat MAC itu sendiri pada port tambahan).

SUNTING: Juga, ini biasa terjadi di lembaga pendidikan (dua dari pekerjaan sysadmin saya sebelumnya) karena kesayangan kecil suka dipusingkan dengan kabel patch / soket ...

Kedengarannya bagi saya ketika Anda memiliki beberapa perangkat keras yang buruk yang menyebabkan badai siaran. Gunakan Wireshark untuk menonton siaran dan menemukan host yang membuat Anda kesulitan ...

Ide Joe adalah ide yang bagus, tetapi mengingat bahwa itu bukan badai penyiaran yang menyebabkan masalah Anda (saya pikir Anda berada di jalur yang benar dengan keracunan cache ARP atau masalah serupa; bahkan mungkin konflik alamat IP), mungkin tidak akan menyelesaikan masalah.

Teknik terkait untuk menggunakan pemeriksaan ARP dan DHCP dinamis, jika sakelar Anda mendukungnya. Jika Anda mengaktifkan ini, sakelar akan menonton transaksi DHCP, dan hanya mengizinkan entri ARP yang cocok dengan entri yang dikenal dalam basis data DHCP, atau yang Anda tentukan secara manual.

Jika sakelar Anda tidak memiliki fitur ini, opsi lain untuk melacaknya adalah arpwatch utilitas Linux - ia melacak semua permintaan ARP dan memberi tahu Anda saat pemberitahuan perubahan pemetaan IP-MAC.