Huawei CE6800 का 100GE uplink Profitap XX-3200G तक SR4 optics के साथ कभी up नहीं होता
किसी customer के incumbent aggregation pair को CloudEngine kit से replace कर रहा हूं, और जो अकेला link up होने से मना कर रहा है वह उनके packet broker में जाने वाला 100GE feed है। switch पर बाकी सब कुछ बिना किसी drama के चढ़ गया।
- Huawei CloudEngine 6800, 100GE port
- 100GBASE-SR4 QSFP28 modules, Huawei parts, एक-एक हर सिरे पर
- Profitap XX-3200G packet broker दूसरी तरफ
दोनों सिरे अपना module देखते हैं। switch log में transceiver insert और remove की entries के अलावा कुछ नहीं है, जो reseat करते वक्त बनी थीं, कोई alarm बिल्कुल नहीं, और interface बस down बैठा रहता है:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECअब तक क्या किया:
- दोनों modules को spares से बदला और MPO ends साफ किए, कोई फर्क नहीं;
- link को switch पर किसी दूसरे 100GE port पर move किया;
- broker side चेक की, वह अपना module detect करता है और कुछ भी गलत report नहीं करता।
तो optics दोनों सिरों पर recognise हो रहे हैं, कुछ भी complain नहीं कर रहा, और link नहीं है। CloudEngine के 100GE port और किसी third-party box के बीच link train होने से पहले और क्या 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 3
यह एक FEC mismatch है। CloudEngine SR4 optics वाले 100GE ports पर default से RS-FEC enable करता है, broker में कोई FEC setting नहीं है इसलिए वह उसके बिना चलता है, और जो दो सिरे FEC पर सहमत नहीं होते वे कभी training पूरी नहीं करते। कुछ भी टूटा नहीं है, इसलिए कुछ भी log नहीं होता, यही वजह है कि log में सिर्फ तुम्हारे insert और remove messages हैं।
switch पर इसे बंद करो, interface view में:
undo fec modeभी वही काम करता है। दूसरी line ही असल में मायने रखती है। CE two-stage configuration है, और एक uncommittedfec mode noneconfig वापस पढ़ने पर बिल्कुल सही लगता है जबकि port ठीक पहले जितना ही down रहता है। मैंने इसी वजह से एक customer case को एक दिन ज्यादा चलते देखा है, जबकि सब यही मान बैठे थे कि FEC पहले ही disable हो चुका है।commit के बाद,
display interfaceमें FEC: NONE दिखना चाहिए और port train हो जाना चाहिए।अगर दूर वाला सिरा कभी कोई FEC setting पाता भी है, तो बेहतर fix यह है कि वहां RS-FEC enable कर दो और switch को उसके default पर छोड़ दो, क्योंकि 100G पर correction असल में चाहिए ही होता है। दो अलग vendors के बीच मैं दोनों तरफ FEC explicitly set करूंगा, बजाय इसके कि किसी negotiation पर भरोसा किया जाए।
broker अपनी तरफ FEC के बारे में क्या कहता है, अगर कुछ कहता भी है तो? interesting आधा हिस्सा तुम खुद ही पोस्ट कर चुके हो: switch port RS-FEC पर चल रहा है। Huawei साफ कहता है कि 100GE link के दोनों सिरों को एक ही FEC mode इस्तेमाल करना होता है, वरना interfaces कभी up नहीं होते, और वह failure बिल्कुल तुम्हारे जैसी दिखती है, दोनों modules healthy, कोई alarm नहीं, कोई log नहीं, port down।
ज्यादातर packet brokers और taps जिनके साथ मैंने काम किया है, कोई FEC knob देते ही नहीं, मतलब वे उसके बिना चलते हैं और switch वाली साइड को ही झुकना पड़ता है। पहले यह confirm करो, फिर एक चीज़ बदलो।
यह जोड़ना ज़रूरी है कि CloudEngine का default कोई एक value नहीं है, यह module पर निर्भर करता है। QSFP28-100G-LR4 और QSFP28-100G-LR1 IEEE 802.3 के हिसाब से FEC off के साथ चलते हैं, जबकि बाकी सभी QSFP28 types default से FEC on रखते हैं। तो सिर्फ disable कर देने की सलाह एक LR4 link पर गलत है, जहां switch पहले से ही off है और mismatch दूसरे सिरे पर बैठा है।
इसी chapter के दो और rules जिन्होंने मुझे पकड़ा है:
तो FEC किस तरफ push करना है यह तय करने से पहले
display transceiver interface 100GE1/0/1 verboseसे देखो कि असल में हाथ में क्या है, और दोनों ही सूरत में commit याद रखो।