Originele 160-9103-900 SFP+ komt op als UCTF op een Ciena 3930 - waar staat de lijst met gecertificeerde modules
Bezig met de oplevering van een 10G-overdracht voor een klant op een 3930 die al op locatie stond. De module is van Ciena zelf, uit onze eigen voorraad, en de poort komt wel op, maar de operationele status is UCTF in plaats van Ena en het alarm voor niet-gecertificeerde transceiver blijft permanent staan. De acceptatietest vereist een schone alarmlijst, dus zo kan ik dit niet opleveren.
- Ciena 3930, software zoals bij levering op locatie
- Ciena 160-9103-900 SFP+ 10G
- singlemode-paar naar de NTU van de klant, korte afstand
> port xcvr show
Port 1 ... Oper State: UCTFWat ik geprobeerd heb:
- de module opnieuw gezet en naar een andere poort verplaatst, zelfde resultaat
- een tweede 160-9103-900 uit dezelfde voorraad geplaatst, identiek UCTF
- bevestigd dat de link verkeer forwardt, dus dit is geen optisch probleem
Ik verwachtte dat een Ciena-merkmodule in een Ciena-switch nu juist de ene combinatie zou zijn die nooit tegenspreekt. Hoe kom ik erachter welke transceivermodellen de draaiende software daadwerkelijk certificeert, en waardoor verdwijnt die niet-gecertificeerde status?
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 4
Dat is precies het punt, en het verrast mensen omdat iedereen aanneemt dat de controle over de fabrikant gaat. Dat is niet zo. Wat de switch vergelijkt is de codering die de module draagt tegen de lijst met modellen die de eigen softwarerelease certificeert. Een door Ciena gebouwde module waarvan het model niet op die lijst staat komt op als UCTF, en een module van een leverancier van compatibele optiek waarvan de codering met een item op de lijst overeenkomt komt schoon op.
De werkwijze is dus:
Neem een item uit het eerste commando dat bij de snelheid en reikwijdte past die je nodig hebt, en betrek modules die daarop gecodeerd zijn. Wij hadden dezelfde UCTF op een 3930 en plaatsten een ModuleTek 10G LR SFP+ gecodeerd als XCVR-S10V31, die op de supported-lijst staat: de poort kwam op met operationele status Ena en zonder aanduiding van niet-gecertificeerd, en er is verder niets aan de switch aangeraakt.
Kanttekeningen die het waard zijn om te noemen vóór een oplevering aan de klant: dit is een codematch, geen supportuitspraak van de leverancier, dus als de doos onder contract valt, controleer dan wat de overeenkomst zegt over niet-Ciena-optiek voordat je het zo ontwerpt. De andere route is een softwarerelease die 160-9103-900 wel op de lijst heeft staan, maar op een live klantdienst is een upgrade meestal de duurdere van de twee.
Draai
port xcvr show supporteden zoek je model in de output. Dat dumpt de modellen en linksnelheden die de release op de doos bereid is te certificeren, en die lijst is het enige dat telt: niet wat er op de cage gestempeld staat.Post wat eruit komt, of in elk geval of 160-9103-900 erin voorkomt. Zo niet, dan heb je je antwoord al, en dat de module echte Ciena is doet er dan niet toe. Ook de moeite waard om te vermelden op welke SAOS-release de 3930 draait: de lijst is per release, en een doos die al een tijdje op locatie staat kan gemakkelijk van vóór een partnummer dateren dat latere software wel vermeldt.
Gedraaid. De lijst is lang, maar 160-9103-900 staat er niet in: ik heb hem twee keer doorgenomen. De software is wat de doos van fabriek meekreeg, niemand heeft sinds de installatie aan de release gezeten, en
port xcvr showzet de poort nog steeds op UCTF.Dus een echt Ciena-onderdeel is niet-gecertificeerd op een Ciena-switch omdat deze release het niet vermeldt. Niet het antwoord dat ik verwachtte, maar het verklaart wel waarom de tweede module uit dezelfde voorraad zich identiek gedroeg.
Het is de moeite waard om er het faalscenario bij te zetten waarin codering niet het probleem is, want codering najagen is duur. Op een ME3600X met 15.3(1)S had ik
%PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supporteden een gbic-invalid err-disable op 10G-modules.service unsupported-transceiverenno errdisable detect cause gbic-invalidveranderden niets, de modules verschenen nooit inshow inventory,show interfaceprintte helemaal geen mediatype, en een optisch meetinstrument zag geen licht uit ze komen. Het was een dode batch: modules uit een andere, al in dienst zijnde ME3600 werkten meteen. Geen mediatype plus geen Tx-licht betekent hardware, en geen enkel unlock-commando redt dat.Het andere uiterste is codering die specifiek verkeerd is voor het platform: DWDM-SFP+ van derden voor 80 km bleef in een ASR 9001 down met een generieke PID, en
transceiver permit pid allredde ze niet, omdat IOS XR een PID wilde in de vorm DWDM-SFP10G-xx.yy uit de optiekmatrix van dat platform. De leverancier herkodeerde de batch en ze kwamen op. Jouw geval zit ertussenin: de codering is geldig, hij staat alleen niet op de lijst van de release.