Port RJ45/SFP shared 17-20 di FortiGate 101F mati total setelah upgrade FortiOS
Kami menjalankan sepasang FortiGate 101F untuk kantor 40 orang, tidak ada yang aneh-aneh. port17 membawa uplink SFP ke core switch, port19 jalur RJ45 ke server room, keduanya ada di dalam blok RJ45/SFP shared (port 17-20). Di maintenance window bulan lalu kami upgrade sepasang unit itu ke FortiOS 7.4.4, dan sejak itu blok tersebut mati.
- FortiGate 101F, dan FortiGate 100F di site kedua berperilaku sama
- port17: modul SFP 1G ke access switch yang di-stack
- port19: RJ45 ke port switch 1G
- FortiOS 7.4.4, upgrade dari build 7.2
Port 1-16 baik-baik saja, cuma yang shared yang mati. Yang menarik perhatian saya, opsi speed di GUI sekarang tidak terlihat seperti sebelum upgrade, dan running config sekarang begini:
config system interface
edit "port17"
set speed 1000full
next
endTidak ada satu pun orang di sini yang mengetik itu. Semua port di kotak ini ada di auto sebelum upgrade.
Yang sudah dicoba:
- cabut pasang lagi SFP-nya dan ganti dengan yang sudah terbukti baik, tidak berubah
- pindahkan ujung seberang ke port switch lain
- cold reboot firewall-nya, config tetap seperti di atas
Apakah blok RJ45/SFP shared di 100F/101F memang wajar kehilangan auto waktu upgrade, atau config kami rusak di suatu tempat? Dan apa cara yang benar untuk mengembalikannya?
Comments 5
Config kamu tidak dirusak siapa pun di kantor, upgrade-nya yang melakukan itu. Di 100F dan 101F, upgrade diam-diam menempelkan 1000full tetap ke port RJ45/SFP shared yang tadinya auto, tanpa bertanya dulu apakah peer-nya bisa hidup dengan rate itu. Tergantung ujung seberangnya, kamu jadi dapat port yang link di rate yang salah, atau yang tidak pernah link sama sekali, dan itu persis kenapa 17-20 mati sementara port dedicated tidak tersentuh. Fortinet sudah mencatat ini sebagai known issue 989629, ditulis di release notes untuk 7.2.9; train yang terdampak adalah v7.2.8 ke atas, v7.4.2 ke atas, dan v7.6.0 ke atas.
Kembalikan speed-nya secara manual, per port:
Di v7.2.8 dan di v7.4.2 sampai v7.4.4, auto biasa tidak ditawarkan di daftar, dan itu persis kenapa GUI-nya terlihat beda buat kamu, jadi pakai 1000auto di situ. Di v7.2.9, v7.4.5, v7.6.0 ke atas, opsi normalnya sudah kembali dan kamu mau:
Ulangi untuk port18 sampai port20 kalau memang dipakai. Dan untuk window berikutnya: cek dulu tidak ada bagian dari management path kamu yang mendarat di port 17-20, kalau tidak, kotaknya bakal balik dengan access port kamu terpaksa 1000full dan kamu harus ke site untuk membetulkannya dari console.
Kamu sebenarnya datang dari build yang mana? "build 7.2" itu cakupannya luas, dan apa yang harus kamu ketik untuk memperbaiki ini beda-beda antar train. Hal lain yang perlu diketahui apakah ujung seberang menawarkan autonegotiation atau memang dipin sendiri: peer yang cuma bisa autonegotiate akan diam saja tidak ngapa-ngapain menghadapi port yang dipatok di rate tetap.
Satu hal yang perlu dipastikan sebelum kamu ubah apa pun: apakah management path kamu lewat salah satu dari port 17-20? Kalau iya, lakukan perubahan berikutnya dari console, bukan lewat jaringan.
Perlu ditambahkan bagian umumnya untuk siapa pun yang mendarat di sini dengan port shared yang bermasalah: di kebanyakan kotak, pasangan itu memang saling eksklusif. NETGEAR menyebutnya dual personality di GS716T-200, di mana masing-masing dari dua cage SFP dipasangkan dengan salah satu port copper terakhir, dan cuma satu sisi dari pasangan itu yang bisa hidup dalam satu waktu, jadi memasukkan modul diam-diam membuat RJ-45 pasangannya keluar dari layanan. Toh semua port di model itu gigabit, jadi uplink optiknya cuma membeli kamu jalur kabel, bukan bandwidth.
Ide yang sama di blok FortiGate, jadi pastikan sisi mana dari port17 yang sebenarnya kamu lihat. Modul di cage ditambah patch cord di sisi copper dari port yang sama itu own goal klasik, dan dari CLI kelihatannya persis seperti masalah speed.
Vendor beda, rasa sakit yang sama. EX4200 dengan modul uplink EX-UM-2X4SFP: xe-0/1/0 jalan 10G dengan senang, xe-0/1/1 bahkan tidak bisa dimasukkan ke VLAN dan tidak lewat traffic sama sekali. Kedua port jalan di 1G, SFP+-nya terlihat penuh di show chassis hardware, saya ganti-ganti modul, coba EX-UM-2X4SFP cadangan, dan factory reset sebelum ada yang bilang ke saya modul itu sebenarnya apa.
Tidak ada yang rusak. Modul itu cuma menerima SFP+ di dua dari cage-nya, yang bernomor 0 dan 2 di hardware; pasangan yang lain cuma bisa bawa optik 1G dan tidak lebih cepat dari itu. Jadi interface 10G yang kamu dapat pada akhirnya xe-0/1/0 plus xe-0/1/2, dan xe-0/1/1, yang saya perjuangkan mati-matian, memang tidak akan pernah jalan di 10G apa pun yang saya colok ke situ. Pindahkan optiknya satu cage sebelah, konfigurasi xe-0/1/2, selesai. Dengan cage mixed-mode, baca dulu apa yang didukung blok itu sebelum kamu RMA apa pun.
Hati-hati dengan sudut pandang combo-exclusivity, itu tidak menjelaskan kasus ini. Port-portnya jalan sebelum upgrade, cuma blok shared yang rusak sesudahnya, dan ada baris speed di config yang tidak ada yang ketik. Itu rewrite dari upgrade, bukan prioritas cage.
Tapi kesalahan sebaliknya juga sering menjebak orang. Saya pernah habiskan seminggu di switch D-Link DES-1210-52 yang di-uplink lewat fiber ke OSNOVO NS-SW-8GX2G: indikasi link ada di port optik, tidak ada LAN, tidak ada internet sama sekali, sementara switch yang sama jalan baik-baik saja waktu dirantai lewat copper, dan update firmware tidak mengubah apa-apa. Combo port jadi tersangka utama selama berhari-hari. Fault sebenarnya ada di ujung seberang: port OSNOVO yang membawa modul SFP itu mati di dalam, terbakar, dengan optiknya sendiri yang duduk di situ sehat sempurna.
Jadi begitu config lokal sudah benar, pasang modul yang sudah terbukti baik ke port yang sudah terbukti baik di sisi seberang sebelum kamu menyimpulkan apa pun soal kotak kamu sendiri.