Link DAC 25G Fortinet nyala antar unit FortiSwitch yang identik, tapi tidak antara FS2048 dan FS648
Kita lagi menggabungkan dua baris agregasi ke FortiSwitch, dan bagian terakhir adalah interkoneksi 25G antara FS2048 dan FS648 di rack yang bersebelahan. Semua bagian lain pada desain ini langsung nyala di percobaan pertama; cuma link yang satu ini yang menolak nyala.
- FortiSwitch 2048, port front-panel 25G
- FortiSwitch 648, port front-panel 25G
- DAC pasif Fortinet FN-CABLE-SFP28-5, kabel vendor, bukan pihak ketiga
- Kedua port lainnya tidak disentuh sama sekali selain konfigurasi VLAN
Yang saya dapat:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableYang sudah dicoba:
- ganti dengan FN-CABLE-SFP28-5 kedua dari box yang sama, tidak ada perubahan
- pindahkan kedua ujung ke port 25G lain di tiap chassis, tidak ada perubahan
- buktikan kabel ini bagus dengan mencolokkannya antar dua unit FS648 yang identik, di situ langsung nyala
Jadi kabelnya oke, port-nya juga oke, tapi kombinasinya enggak. Ada sesuatu di port 25G yang harus cocok antar kedua model ini sebelum link-nya bisa training?
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 6
Itu tepat sekali penyebabnya. Kedua chassis ini dibangun di atas generasi ASIC dan PHY yang berbeda, dan error correction yang dipilih sendiri oleh masing-masing di 25G tidak sama di kedua sisi, jadi link-nya tidak pernah selesai training. Hasilnya cuma down/down bersih, tanpa apa-apa di log yang bisa dijadikan pegangan.
Kunci mode FEC yang sama secara manual di kedua port:
Lakukan ini di FS2048 dan di FS648, pakai nama port masing-masing sisi. CL91 adalah varian Reed-Solomon dan membersihkan error jauh lebih banyak dibanding opsi firecode CL74, tapi mana pun yang dipilih jauh lebih tidak penting dibanding memilih yang sama di kedua sisi: kedua PHY harus encode dan decode dengan skema yang identik atau training tidak akan pernah selesai, dan "auto" di dua PHY family yang berbeda bukan skema yang identik.
Port-nya harus langsung nyala begitu sisi kedua di-commit. Kalau nanti ada model ketiga yang masuk ke kombinasi ini, set eksplisit juga di situ, jangan asumsikan default-nya ikut terbawa.
Kabel yang bisa konek antar unit yang identik tapi mati antar model yang berbeda itu tandanya physical layer gagal sepakat soal sesuatu, dan di tembaga 25G itu nyaris selalu FEC.
Sebelum apa-apa lagi, posting dulu fec-state yang saat ini terkonfigurasi di kedua port. Default-nya tidak sama antar generasi FortiSwitch, dan kedua model yang kamu sambungkan ini bukan ASIC/PHY family yang sama, jadi "pengaturan pabrik di kedua sisi" tidak berarti "pengaturan yang sama di kedua sisi".
Kalau kedua port itu menunjukkan nilai yang berbeda, kamu sudah dapat jawabannya sebelum menyentuh apa pun yang lain.
Tidak ada yang disentuh di kedua sisi, jadi kedua port jalan dengan apa pun yang di-set default oleh image-nya. Sisi FS2048 kosong:
Sama di FS648. Speed dan auto-negotiation juga tidak disentuh, saya cuma masukkan port ke VLAN yang benar. Kalau default-nya beda per model, itu bisa menjelaskan kenapa kabel yang sama adem ayem saja antar dua unit yang identik.
Kelas masalah yang sama, jauh di luar Fortinet, kalau itu ada gunanya. Saya pernah punya DAC pasif SFP28 25G yang konek mulus antara UniFi USW-Pro-Aggregation dan server dengan kartu Intel SFP28, tapi sama sekali tidak jalan di sfp28-2 punya MikroTik CCR2004-1G-12S+2XS - tidak ada error di kedua sisi, cuma tidak ada link. Sudah coba Ubiquiti UACC-DAC-SFP28-3M dan Lenovo 7Z57A03558, hasilnya sama. Sempat sekali port-nya nyala terus drop lagi setelah sekitar dua detik, itu yang jadi petunjuk kalau ada yang gagal training, bukan kabelnya yang mati.
FEC lagi: sisi Ubiquiti menjaga FEC tetap on tanpa cara resmi untuk mengubahnya, dan RouterOS memindahkan default dari fec91 ke no FEC di 6.49. Yang berhasil di sini adalah naik ke RouterOS 7.4, di situ opsi FEC-nya kebuka, jalankan
terus set port ke fec74 dengan auto-negotiation off, flow control off di kedua arah, 25 Gbps full duplex, ditambah port profile override di sisi UniFi yang mengunci 25G FDX. Itu hardware dan firmware saya sendiri, jadi anggap saja resep persisnya sebagai titik awal dan verifikasi lagi di punya kamu.
Perlu ditambahkan, knob yang sama ini punya nama berbeda tergantung CLI siapa yang kamu pakai, dan itu yang bikin runyam begitu satu rack isinya lebih dari satu vendor. Di link 25G Cisco antara Catalyst 9300 stack dan sepasang Catalyst 9500, fec cl108 di kedua ujung yang bikin nyala; di 100G antara pasangan 9500 itu dan Nexus 9000, yang berhasil malah fec off di kedua sisi. Keputusan yang sama, keyword yang beda.
Dan FEC bukan selalu sesuatu yang harus dinyalakan. Di Nexus 93180YC-EX dengan SFP-H25GB-SR ke adapter Cavium 25G, port switch-nya diam di FEC auto dan mengharapkan FEC gara-gara optiknya, sementara NIC-nya melaporkan tidak ada kapabilitas FEC sama sekali, jadi kedua ujung tidak pernah sepakat dan interface-nya tetap down meski modulnya terdeteksi. Di situ, fec off di interface switch yang jadi solusinya, dan show interface mengonfirmasi mode-nya pindah dari Auto ke Off.
Jadi aturannya bukan "pakai cl91", tapi "tentukan mode-nya, lalu set eksplisit di kedua ujung".
Konfirmasi. set fec-state cl91 di port FS2048 sendirian tidak mengubah apa-apa, lalu yang sama di port FS648 dan link-nya nyala dalam beberapa detik. Counter-nya jalan di kedua sisi, dan tetap bertahan setelah reboot masing-masing chassis.
Mulai sekarang setting-nya tetap eksplisit di setiap port 25G pada pasangan ini, bukan mengandalkan default. Dua malam tukar-tukar kabel yang sebenarnya bagus-bagus saja, cuma gara-gara satu baris konfigurasi.