Catalyst 3850 zet de poort in err-disable zodra een ThinkSystem SR650 Lenovo 46C3447 SR-optiek gebruikt
Nieuwe ESXi-host die in een rack komt dat aan een campus-3850 hangt. Management via koper kwam zonder gedoe op, de 10G-uplinks niet: zodra de server opstart valt de switchpoort in err-disable en ziet de host niets op die vmnic.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, met een Emulex VFA5.2 2x10GbE SFP+-adapter
- Lenovo 10GBASE-SR-modules, 46C3447, in de adapter
- Cisco WS-C3850-24XS-S met Cisco SFP-10G-SR aan de switchkant
- OM3 LC-LC-patch ertussen
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 stableAl geprobeerd:
- server naar een andere poort op dezelfde switch verplaatst, zelfde gedrag
- de 46C3447 verwisseld met zijn tweeling uit de andere adapterpoort
- nieuwe patchkabel, beide uiteinden schoongemaakt en opnieuw ingestoken
De fiber en de optiek aan de switchkant zijn duidelijk in orde, dus er is iets dat bezwaar maakt tegen de Lenovo-module. Welke kant maakt hier bezwaar, de server of de switch, en is er een manier om de 3850 daarmee te laten leven?
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
Dat logje maakt het duidelijk.
gbic-invalidis de switch die weigert wat hij leest als een niet-geautoriseerde module, en de check die afgaat zit aan de Cisco-kant, niet in de SR650 en niet in ESXi. Hij maakt bezwaar tegen de Lenovo-gecodeerde SR-optiek in die link en killt de poort voordat de link ooit geëvalueerd wordt, en dat is ook waarom poorten verplaatsen en kabels wisselen niets voor je veranderde.Twee regels in de global configuratie:
De eerste zegt tegen de switch dat hij door moet gaan met een module die hij niet herkent, de tweede voorkomt dat err-disable de poort neerschiet zodra die CRC-check faalt. Geen van beide is retroactief, dus bounce de poort daarna en steek de fiber opnieuw in terwijl hij down is:
Sla de configuratie op zodra hij up is. Staat het alleen in de running config, dan komt de poort na de volgende reload weer err-disabled terug en mag je dit op een veel slechter moment opnieuw uitzoeken.
Twee kanttekeningen. Je zit nu buiten Cisco's supported configuration: zij beschouwen third-party optiek als ongetest en TAC kan een interoperability case met zo'n module weigeren, wat ertoe doet als deze link onder een contract valt. En
service unsupported-transceiveris geen universele oplossing. Diezelfde bad crc-melding overleeft het wanneer de poort zelf het probleem is, bijvoorbeeld een 1G-only SFP-slot met een 10G-module erin geduwd, dus blijft de poort down na de bounce, check dan eerst welke snelheid elke kant echt draait voordat je opnieuw de optiek de schuld geeft.Voordat iemand gaat gokken: wat logt de switch eigenlijk als de poort down gaat? Err-disable noemt altijd zijn cause, en die cause verandert het antwoord volledig. Een security- of CRC-klacht over een module is een ander probleem dan een flap of een protocol-trip, en het middel voor de ene doet niets voor de andere.
Trek
show loggingerbij vanaf het moment dat de server opstart en post de regels voor die poort. Bevestig ook wat er fysiek in Te1/0/7 zit, je zegt Cisco SFP-10G-SR, dus is de 46C3447 het enige non-Cisco-onderdeel in dat hele pad?Log vanaf het moment dat hij valt, twee regels voor die poort:
Dus het is de security-check die afgaat, geen flap. En ja, de switchkant is een echte Cisco SFP-10G-SR uit een Cisco-doos, de 46C3447 in de server is het enige Lenovo-gecodeerde onderdeel in het pad. Wat mij juist in verwarring bracht, want de melding noemt de poort op de switch en niets aan de serverkant.