Packet loss sekitar 15% lewat SFP+ tembaga S+RJ10 di CRS518-16XS-2XQ, padahal jalur 100G langsung bersih
Kami mendorong traffic dari server lab ke CRS518-16XS-2XQ lewat uplink 100G QSFP28, dan keluar dari switch lewat SFP+ tembaga MikroTik S+RJ10 ke host RJ45 1G biasa. Sisi penerima kehilangan sebagian besar paketnya dan saya tidak bisa menunjuk penyebabnya ke sesuatu yang jelas.
Setup:
- MikroTik CRS518-16XS-2XQ, uplink 100G QSFP28 dari sumber traffic
- SFP+ tembaga MikroTik S+RJ10 di salah satu cage, perangkat RJ45 1G di ujung satunya
- capture berjalan di host penerima
Yang ditunjukkan capture-nya:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Yang sudah dicoba sejauh ini:
- sambungkan sumber yang sama langsung di 100G, tidak ada loss sama sekali, jadi sender-nya sendiri baik-baik saja
- turunkan CPU switch-nya, sekarang diam di 1% sementara loss-nya masih terjadi
- pasang ulang S+RJ10-nya dan ganti patch cord ke perangkat 1G-nya
Modul tembaga ini jadi tersangka utama saya sekarang, tapi link-nya bersih dan interface-nya sama sekali tidak menunjukkan error. Apa S+RJ10 memang dikenal suka memakan traffic seperti ini, atau saya harus mencari di tempat lain di dalam switch-nya?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Rata-rata 400-500 Mbps dengan sender yang bursty, itu keseluruhan ceritanya. Traffic kamu tidak tersebar merata: burst pendek keluar dari source lebih cepat dari 1 Gbps, dan semua yang di atas garis itu harus duduk di egress buffer port sampai sisi 1G-nya mengurasnya. Waktu buffer-nya penuh, switch-nya drop. Itu persis yang diberitahukan pergerakan rx-overflow, dan itu kenapa koneksi 100G langsung tidak menunjukkan apa-apa - tidak ada speed step down di situ untuk di-buffer.
Transceiver-nya tidak bersalah. Apa pun yang ada di cage itu, tembaga atau fiber, akan berperilaku sama, karena drop-nya terjadi di step down dari 100G ke 1G, bukan di dalam modulnya.
Dua hal yang harus dilakukan. Perbaikan sebenarnya ada di sender: atur pacing-nya supaya paketnya tersebar merata, bukannya ditulis dalam bentuk burst. Begitu source-nya berhenti menghasilkan burst di atas egress rate, loss-nya hilang.
Di switch-nya kamu bisa bikin situasi buffer-nya tidak seganas itu:
Itu membeli headroom dan membiarkan satu burst bertahan lebih lama, tapi tidak menghilangkan penyebabnya - kalau sender-nya burst cukup keras dalam waktu yang cukup lama, ukuran buffer sebesar apa pun tidak akan menyelamatkan kamu. Terus pantau statistik QoS switch dan counter rx-overflow setelah perubahan ini, supaya kamu bisa lihat apakah kamu masih menabrak plafonnya atau cuma menyentuhnya sesekali.
Pelajaran umumnya layak diingat: port dengan link yang bersih, tanpa error, dan modul yang sehat tetap bisa men-drop traffic sampai dua digit persen murni karena speed step down antar port.
Sebelum menyalahkan modulnya, lihat dulu apa sebenarnya yang dikatakan counter port-nya. Jalankan
di port ingress 100G dan di cage yang ada S+RJ10-nya, dan cari khusus baris rx-overflow, bukan counter error rx/tx yang biasa. SFP+ tembaga yang benar-benar rusak mengumumkan dirinya lewat FCS error atau link yang flapping, bukan lewat potongan rapi 15% dari stream yang kalau tidak begitu sehat-sehat saja.
Pertanyaan kedua: berapa rate rata-rata lewat jalur itu, dan apa kamu punya gambaran soal puncaknya? Kehilangan satu dari tujuh paket dengan CPU di 1% baunya jauh lebih mirip egress port kehabisan buffer daripada transceiver yang rusak.
Counter dulu: tidak ada error di kedua port, link-nya tetap up sepanjang waktu dan modulnya tidak melaporkan apa pun yang aneh. rx-overflow satu-satunya tempat di mana angkanya bergerak sama sekali.
Soal rate, jalurnya rata-rata 400-500 Mbps, jadi di atas kertas itu jauh dari menyaturasi sisi 1G-nya. Saya tidak punya pengukuran puncak, tapi traffic-nya memang bursty dari sananya - sender-nya menulis satu chunk lalu diam sebentar. CPU tetap di 1% sementara paketnya terus hilang.
Kegagalan yang berbeda, pelajaran yang sama soal mempercayai counter dibanding intuisi. Saya pernah punya CRS354-48G-4S+2Q+RM di SwOS 2.18 dengan Rx FCS Errors yang terus naik stabil di kedua port QSFP+, dan Rx MAC Errors dengan rate yang lebih rendah. Kedua port itu duduk di 40G full duplex dengan MTU 1500, dan di sisi seberangnya ada host ESXi dengan kartu Mellanox ConnectX-3 Pro CX324A.
Bagian yang menarik: sisi NIC-nya sama sekali tidak melaporkan apa-apa.
Bersih. Kabel yang sudah diketahui bagus tidak mengubah apa-apa, dan port SFP+ 10G di box yang sama tetap bebas error sepanjang waktu. Saya tidak pernah dapat diagnosis yang sebenarnya - memindahkan switch-nya dari SwOS ke RouterOS bikin counter-nya menghilang, yang saya anggap menyembunyikan masalahnya, bukan menyelesaikannya.
Metode yang tetap bertahan: bersihkan counter-nya, baca lagi setelah interval tetap, dan lihat apakah error-nya mengikuti volume traffic. Di kasus kamu error-nya akan mengikuti burst-nya, di kasus saya tidak mengikuti apa pun yang berguna, dan perbedaan itu saja sudah memberi tahu sisi mana yang harus terus digali.
Satu hal yang perlu diingat selagi kamu bereksperimen di port itu: jangan langsung lari ke forced speed dan duplex sebagai jalan keluar. Perilaku yang terdokumentasi dari modul tembaga MikroTik, baik S-RJ01 maupun S+RJ10, adalah mereka cuma bekerja dengan auto-negotiation aktif - pin rate-nya secara statis dan link-nya sama sekali tidak akan naik. Praktiknya sebagian bertentangan dengan itu, karena beberapa pemilik RB5009 dan RB4011 melaporkan sebaliknya dan cuma berhasil membuat S-RJ01 stabil dengan memaksa 1G full duplex, jadi ini soal "coba dua-duanya di hardware kamu sendiri", bukan aturan baku. Bagaimanapun ini jalan memutar dari masalah sebenarnya, yang ada di sisi buffer.
Detail S+RJ10 lain yang perlu diketahui untuk nanti: modul ini menarik daya jauh lebih banyak dibanding optik normal dan panas, jadi tidak disarankan di perangkat berpendingin pasif tanpa airflow tambahan. Kalau modul itu mulai berulah di chassis yang hangat, suhu adalah hal pertama yang akan saya cek.