Fortinet 25G DAC identical FortiSwitch units के बीच link होता है पर FS2048 से FS648 तक नहीं
हम दो aggregation rows को FortiSwitch पर collapse कर रहे हैं, और आखिरी हिस्सा है adjacent racks में एक FS2048 और एक FS648 के बीच 25G interconnect। बाकी सब कुछ design में पहली ही कोशिश में up हो गया; बस यही एक link मानने को तैयार नहीं है।
- FortiSwitch 2048, 25G front-panel port
- FortiSwitch 648, 25G front-panel port
- Fortinet FN-CABLE-SFP28-5 passive DAC, vendor cable, third party नहीं
- VLAN config के अलावा दोनों ports पर कुछ और touch नहीं किया
मुझे क्या मिल रहा है:
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, stableपहले से किया हुआ:
- same box से दूसरा FN-CABLE-SFP28-5 लगाकर देखा, कोई फर्क नहीं
- दोनों ends को हर chassis के अलग-अलग 25G ports पर move किया, कोई फर्क नहीं
- cable को दो identical FS648 units के बीच लगाकर prove किया कि वो सही है, वहाँ तुरंत up हो जाता है
तो cable ठीक है और ports भी ठीक हैं, बस combination नहीं चल रहा। क्या 25G ports पर कुछ ऐसा है जो link train होने से पहले दोनों models के बीच match होना चाहिए?
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
बिल्कुल यही बात है। दोनों chassis अलग-अलग ASIC और PHY generations पर बने हैं, और 25G पर हर एक जो error correction खुद-ब-खुद चुनता है वो दोनों तरफ same नहीं है, इसलिए link कभी training पूरी नहीं कर पाता। आपके हाथ में बस एक साफ-सुथरा down/down रह जाता है और logs में चबाने को कुछ नहीं।
दोनों ports पर हाथ से same FEC mode pin करें:
FS2048 और FS648 दोनों पर करें, हर तरफ के अपने port name के साथ। CL91 Reed-Solomon variant है और CL74 firecode option से काफी ज्यादा clean करता है, पर दोनों में से कौन सा चुनते हैं ये उतना मायने नहीं रखता जितना दोनों जगह same चुनना: दोनों PHYs को identical scheme से encode-decode करना ही होगा वरना training कभी पूरी नहीं होगी, और दो अलग PHY families पर "auto" कोई identical scheme नहीं है।
दूसरी तरफ commit होते ही port up हो जाना चाहिए। बाद में अगर कोई तीसरा model इसमें mix करें, तो वहाँ भी explicitly set करें, ये मानकर मत चलें कि default वही carry हो गया।
जो cable identical units के बीच link करता है और अलग-अलग models के बीच मर जाता है, वो physical layer का किसी बात पर agree न कर पाना है, और 25G copper पर ये लगभग हमेशा FEC ही होता है।
कुछ और करने से पहले, post करें कि दोनों ports पर अभी fec-state क्या configured है। FortiSwitch generations में default same नहीं होता, और जो दो models आप जोड़ रहे हैं वो same ASIC/PHY family के नहीं हैं, इसलिए "दोनों तरफ factory settings" का मतलब "दोनों तरफ same setting" नहीं होता।
अगर दोनों ports अलग-अलग values के साथ आते हैं, तो बाकी कुछ भी touch करने से पहले आपको जवाब मिल गया।
किसी भी तरफ कुछ touch नहीं किया, तो दोनों ports वही चला रहे हैं जो image default से set करती है। FS2048 वाली side बिल्कुल bare है:
FS648 पर भी same। Speed और auto-negotiation भी untouched हैं, मैंने बस ports को सही VLAN में डाला है। अगर defaults हर model पर अलग हैं, तो यही explain कर देगा कि same cable दो identical boxes के बीच बिल्कुल खुश क्यों रहता है।
Fortinet से बिल्कुल बाहर भी same class की problem मिलती है, बताने लायक बात है। मेरे पास एक 25G SFP28 passive DAC था जो UniFi USW-Pro-Aggregation और Intel SFP28 card वाले server के बीच खुशी-खुशी link हो जाता था, और MikroTik CCR2004-1G-12S+2XS के sfp28-2 पर कुछ भी नहीं देता था - किसी भी तरफ error नहीं, बस link नहीं। Ubiquiti UACC-DAC-SFP28-3M और Lenovo 7Z57A03558 try किया, same result। एक बार port up हुआ भी और लगभग दो second बाद फिर drop हो गया, जिससे लगा कि cable dead नहीं बल्कि कुछ train होने में fail हो रहा है।
फिर से FEC: Ubiquiti वाली side FEC को on रखती है और उसे बदलने का कोई supported तरीका नहीं है, और RouterOS ने 6.49 में default को fec91 से no FEC कर दिया। यहाँ जो काम आया वो था RouterOS 7.4 पर जाना, जहाँ FEC options expose होते हैं,
चलाकर, और फिर port को fec74 पर set करना, auto-negotiation off, दोनों directions में flow control off, 25 Gbps full duplex, साथ ही UniFi side पर एक port profile override जो 25G FDX pin करता है। ये मेरा hardware और मेरा firmware है, तो इस exact recipe को शुरुआती बिंदु समझें और अपने पर verify करें।
जोड़ने लायक बात: same knob का नाम इस पर depend करता है कि आप किसकी CLI में खड़े हैं, और यही चीज़ तकलीफ देती है जब rack में एक से ज्यादा vendor हों। Cisco पर एक Catalyst 9300 stack और Catalyst 9500 pair के बीच 25G links में, दोनों ends पर fec cl108 लगाने से वो up हुए; उस 9500 pair और एक Nexus 9000 के बीच 100G पर, दोनों sides पर fec off काम आया। decision same, keywords अलग।
और FEC हमेशा ऐसी चीज़ नहीं जिसे on करना है। SFP-H25GB-SR वाले Nexus 93180YC-EX पर, जो एक Cavium 25G adapter में जा रहा था, switch port FEC auto पर बैठा था और optic की वजह से FEC expect कर रहा था, जबकि NIC ने कोई FEC capability report ही नहीं की, तो दोनों ends कभी agree नहीं हुए और interfaces down रहे जबकि modules recognised थे। वहाँ, switch interface पर fec off ही fix था, और show interface confirm करता है कि mode Auto से Off पर move हुआ।
तो rule "cl91 use करो" नहीं है, rule है "mode decide करो, फिर दोनों ends पर explicitly set करो"।
Confirm हो गया। सिर्फ FS2048 port पर set fec-state cl91 करने से अकेले कुछ नहीं बदला, फिर FS648 port पर भी same किया और कुछ ही second में link up हो गया। दोनों sides पर counters move कर रहे हैं, और दोनों chassis के reboot के बाद भी टिका रहा।
अब से इस pair के हर 25G port पर setting explicit रहेगी, default पर भरोसा नहीं करेंगे। बिल्कुल सही cables बदलते-बदलते दो शामें गईं, आखिर में बात एक line के config की निकली।