FortiOS upgrade के बाद FortiGate 101F के shared RJ45/SFP ports 17-20 बुझ जाते हैं
हम 40 लोगों के office के लिए FortiGate 101F की एक जोड़ी चलाते हैं, कुछ खास नहीं। port17 core switch तक SFP uplink ले जाता है, port19 server room तक RJ45 run है, दोनों shared RJ45/SFP block (ports 17-20) के अंदर हैं। पिछले महीने maintenance window में हमने जोड़ी को FortiOS 7.4.4 पर ले गए, और तब से वो block मरा हुआ है।
- FortiGate 101F, और दूसरी site पर एक FortiGate 100F भी वैसा ही व्यवहार करता है
- port17: एक stacked access switch तक 1G SFP module
- port19: एक 1G switch port तक RJ45
- FortiOS 7.4.4, एक 7.2 build से upgrade किया
Ports 1-16 ठीक हैं, सिर्फ shared वाले ही down हुए। जो चीज़ मेरी नज़र में आई वो यह कि GUI में speed options अब upgrade से पहले जैसे नहीं दिखते, और running config में अब यह है:
config system interface
edit "port17"
set speed 1000full
next
endयहां किसी ने यह type नहीं किया। upgrade से पहले इस box का हर port auto पर था।
अब तक जो आज़माया:
- SFP reseat किया और उसे किसी known good वाले से बदला, कोई फर्क नहीं
- दूर वाले सिरे को दूसरे switch port पर ले गया
- firewall का cold reboot, config ऊपर जैसा ही बना रहता है
क्या 100F/101F पर shared RJ45/SFP block से upgrade के दौरान auto खोना expected है, या हमारा config कहीं गड़बड़ हो गया? और इसे वापस ठीक करने का सही तरीका क्या है?
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
तुम्हारा config office में किसी ने नहीं गड़बड़ाया, upgrade ने किया। 100F और 101F पर upgrade चुपचाप shared RJ45/SFP ports पर एक fixed 1000full थोप देता है जहां पहले auto हुआ करता था, बिना यह पूछे कि क्या peer उस rate के साथ चल पाएगा। दूर वाले सिरे के हिसाब से फिर या तो port गलत rate पर link करता है, या कभी link ही नहीं करता, और यही वजह है कि 17-20 बुझे हुए हैं जबकि dedicated ports अछूते हैं। Fortinet के यहां यह known issue 989629 के तौर पर दर्ज है, 7.2.9 के release notes में लिखा गया; असर वाले trains हैं v7.2.8 और उसके बाद, v7.4.2 और उसके बाद, और v7.6.0 और उसके बाद।
speed को हाथ से वापस डालो, per port:
v7.2.8 पर और v7.4.2 से v7.4.4 तक plain auto list में मिलता ही नहीं, इसीलिए तो तुम्हें GUI अलग दिखता है, तो वहां 1000auto इस्तेमाल करो। v7.2.9, v7.4.5, v7.6.0 और उसके बाद पर normal option वापस है और तुम्हें चाहिए:
port18 से port20 तक दोहराओ अगर वो इस्तेमाल में हैं। और अगली window के लिए: पहले चेक कर लो कि तुम्हारा management path ports 17-20 पर तो नहीं टिका, वरना box तुम्हारे access port को 1000full पर forced लेकर वापस आएगा और तुम्हें console से ठीक करने के लिए site तक ड्राइव करना पड़ेगा।
तुम असल में किस build से आए थे? "a 7.2 build" में बहुत कुछ समा सकता है, और इसे fix करने के लिए क्या type करना है यह trains के बीच अलग होता है। जानने लायक दूसरी बात यह है कि दूर वाले सिरे autonegotiation offer करते हैं या खुद pinned हैं: जो peer हमेशा सिर्फ autonegotiate करता है वो एक fixed rate पर पकड़े गए port के सामने कुछ नहीं करता बैठा रहेगा।
कुछ भी बदलने से पहले एक बात सुलझा लो: क्या तुम्हारा management path ports 17-20 में से किसी से होकर जाता है? अगर हां, तो अगला बदलाव network की बजाय console से करो।
यहां किसी misbehaving shared port के साथ आने वाले किसी भी व्यक्ति के लिए general बात जोड़ना ठीक रहेगा: ज्यादातर boxes पर वो जोड़ी सच में exclusive होती है। NETGEAR इसे GS716T-200 पर dual personality कहता है, जहां दोनों SFP cages में से हर एक आखिरी copper ports में से किसी एक के साथ जोड़ा गया है, और उस जोड़ी का सिर्फ आधा हिस्सा ही किसी एक वक्त live रह सकता है, तो कोई module डालना चुपचाप matching RJ-45 को service से बाहर कर देता है। उस model पर वैसे भी हर port gigabit ही है, तो optical uplink तुम्हें bandwidth नहीं, बस एक cable route देता है।
FortiGate वाले block पर भी यही सोच लागू होती है, तो confirm कर लो कि तुम असल में port17 के किस आधे हिस्से को देख रहे हो। cage में module और उसी port के copper आधे हिस्से में patch cord एक classic own goal है, और CLI से यह काफी हद तक speed problem जैसा दिखता है।
अलग vendor, दर्द का वही स्वाद। EX-UM-2X4SFP uplink module वाला EX4200: xe-0/1/0 खुशी-खुशी 10G चलाता था, xe-0/1/1 को VLAN में जोड़ा तक नहीं जा सकता था और कोई traffic पास नहीं होता था। दोनों ports 1G पर काम करते थे, SFP+ show chassis hardware में पूरी तरह दिखता था, मैंने modules बदले, एक spare EX-UM-2X4SFP आज़माया और factory reset किया, इससे पहले कि किसी ने मुझे बताया कि वो module असल में है क्या।
कुछ भी defective नहीं था। वो module अपने cages में से सिर्फ दो में SFP+ लेता है, hardware में जो 0 और 2 नंबर वाले हैं; बाकी जोड़ी 1G optic ले सकती है, इससे तेज़ कुछ नहीं। तो जो 10G interfaces हाथ लगते हैं वो हैं xe-0/1/0 और xe-0/1/2, और xe-0/1/1, जिससे मैं जूझ रहा था, वो चाहे जो भी लगाओ कभी 10G पर चलने वाला था ही नहीं। optic को एक cage आगे ले गया, xe-0/1/2 configure किया, हो गया। mixed-mode cages के साथ, कुछ भी RMA करने से पहले पढ़ लो कि वो block क्या support करता है।
combo-exclusivity वाले angle से सावधान, यह इस case को समझाता नहीं। ports upgrade से पहले काम करते थे, बाद में सिर्फ shared block टूटा, और config में एक speed line है जो किसी ने type नहीं की। यह rewrite है, cage priority नहीं।
पर उल्टी गलती भी लोगों को जलाती है। मैंने एक बार D-Link DES-1210-52 switches पर एक हफ्ता बिताया जो fibre पर एक OSNOVO NS-SW-8GX2G से uplinked थे: optical ports पर link indication, कोई LAN नहीं, बिल्कुल कोई internet नहीं, जबकि वही switches copper पर chained होकर ठीक काम करते थे, और एक firmware update से कुछ नहीं बदला। कई दिनों तक combo port ही मुख्य शक था। असली fault दूर वाले सिरे पर था: वो OSNOVO ports जो उन SFP modules को carry कर रहे थे internally dead थे, जले हुए, और उनमें बैठे optics बिल्कुल healthy थे।
तो एक बार local config ठीक हो जाए, अपने box के बारे में कुछ भी नतीजा निकालने से पहले दूसरी तरफ किसी known-good port में एक known-good module डालो।