जब ThinkSystem SR650, Lenovo 46C3447 SR optics इस्तेमाल करता है तो Catalyst 3850 port को err-disable कर देता है
एक नया ESXi host उस rack में जा रहा है जो campus वाले 3850 से लटका है। copper पर management बिना किसी drama के up हो गया, 10G uplinks नहीं हुए: server boot होते ही switch port err-disable में चला जाता है और host को उस vmnic पर कुछ नहीं दिखता।
- Lenovo ThinkSystem SR650, 7X06CTO1WW, साथ में Emulex VFA5.2 2x10GbE SFP+ adapter
- adapter में Lenovo 10GBASE-SR modules, 46C3447
- switch side पर Cisco WS-C3850-24XS-S, साथ में Cisco SFP-10G-SR
- दोनों के बीच OM3 LC-LC patch
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableपहले से try किया:
- server को उसी switch के दूसरे port पर लगाया, वही व्यवहार
- 46C3447 को दूसरे adapter port वाले उसके twin से बदला
- नया patch cord, दोनों ends साफ करके reseat किए
fibre और switch-side वाली optic साफ तौर पर ठीक हैं, तो किसी को Lenovo module से ऐतराज़ है। यहां ऐतराज़ कौन कर रहा है, server या switch, और क्या कोई तरीका है जिससे 3850 इसके साथ जी ले?
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
वह log ही तय कर देता है।
gbic-invalidका मतलब है switch किसी ऐसे module को मना कर रहा है जिसे वह unauthorised पढ़ता है, और जो check चलता है वह Cisco की तरफ है, न कि SR650 पर और न ही ESXi में। यह उस link में Lenovo-coded SR optic पर ऐतराज़ करता है और link को evaluate किए जाने से पहले ही port को मार देता है, यही वजह है कि ports बदलना और cords बदलना आपके लिए कुछ नहीं बदला।Global configuration में दो lines:
पहली switch को बताती है कि जो module वह नहीं पहचानता उसके साथ भी चलता रहे, दूसरी err-disable को उस CRC check के fail होने पर port को शूट करने से रोकती है। दोनों में से कोई भी retroactive नहीं है, तो उसके बाद port को bounce कीजिए और वह down हो तब fibre को reseat कीजिए:
up होने के बाद configuration save कीजिए। अगर यह सिर्फ running config में रहा, तो अगले reload के बाद port वापस err-disabled होकर आएगा और आपको इसे कहीं ज्यादा बुरे मौके पर फिर से debug करना पड़ेगा।
दो caveats। अब आप Cisco की supported configuration से बाहर हैं: वे third-party optics को untested मानते हैं और TAC ऐसा कोई interoperability case मना कर सकता है जिसमें एक शामिल हो, जो मायने रखता है अगर यह link किसी contract के नीचे बैठा हो। और
service unsupported-transceiverकोई universal fix नहीं है। वही bad crc message तब भी बचा रहता है जब रुकावट खुद port हो, मसलन कोई 1G-only SFP slot जिसमें 10G module ठूंसा गया हो, तो अगर bounce के बाद भी port down रहे, तो optic को दोबारा दोष देने से पहले चेक कीजिए कि हर end असल में किस speed पर चल रहा है।कोई अंदाज़ा लगाए उससे पहले: port down होने पर switch असल में क्या log करता है? Err-disable हमेशा अपना cause बताता है, और cause पूरा जवाब बदल देता है। किसी module के बारे में security या CRC वाली शिकायत, किसी flap या protocol trip से बिल्कुल अलग problem है, और एक का इलाज दूसरे के लिए कुछ नहीं करता।
server के power on होने के आस-पास का
show loggingनिकालिए और उस port की lines post कीजिए। यह भी confirm कीजिए कि Te1/0/7 में physically क्या बैठा है, आप कहते हैं Cisco SFP-10G-SR, तो क्या उस पूरे path में 46C3447 ही एकमात्र non-Cisco part है?जिस पल यह गिरता है उसका log, उस port की दो lines:
यानी यह security check चल रहा है, कोई flap नहीं। और हां, switch वाला सिरा एक genuine Cisco SFP-10G-SR है जो Cisco के box से आया है, server में लगा 46C3447 ही उस path में एकमात्र Lenovo-coded part है। यही बात मुझे confuse कर रही थी, क्योंकि message switch पर मौजूद port का नाम लेता है, server side की किसी चीज़ का नहीं।