Lenovo RackSwitch G8124E weigert een generieke 10G SR SFP+ met UNAPPROVED - SR SFP+ is DISABLED
We hebben een paar G8124E's uit een uitgefaseerd rack gehaald en ik bouw ze om tot de aggregatielaag voor een interne testomgeving. Budget voor branded optiek is nul, dus gaat alles erin met generieke 10G SR-modules van het type dat we elders al draaien.
- Lenovo RackSwitch G8124E, ex-IBM branded chassis
- generieke 10G SR SFP+, duplex LC, zelfde batch als degene die in onze productie-top-of-rack werken
- OM3-patch naar een server-NIC die op 10G linkt met precies hetzelfde moduletype
De poort komt even tot leven en dan sluit de switch hem af:
UNAPPROVED - SR SFP+ is DISABLED
Daarna komt de link nooit tot stand en blijft de poort down.
Wat ik al geprobeerd heb:
- de module door vier verschillende cages gehaald, elke keer dezelfde melding
- een tweede module uit dezelfde batch geplaatst en een derde van een andere leverancier
- de interface-config doorgespit op zoek naar iets als een allow-unsupported-knop en niets gevonden
Is er een manier om deze box third-party optiek te laten accepteren, of is de approval check iets wat je alleen met Lenovo-gecodeerde modules kunt voldoen?
Comments 5
Voordat iemand je een commando in handen duwt, wat meldt
show version? Bij deze familie is het middel niet één commando, het splitst per code train: wat je doet op een 7.x-image is niet wat je doet op 8.x, dus de versie moet eerst vaststaan.Zeg ook of de modules gewoon generiek zijn of een herkenbare vendor-string in de EEPROM dragen. De firmware beoordeelt elke module op die string, en mensen met Intel-gecodeerde SFP+ in precies deze switch krijgen ook de unapproved-transceiverwaarschuwing, dus de melding alleen zegt niet veel over de optiek zelf.
show versionzet hem op een 7.x-image, dus de oudere train en niet de huidige.De modules zijn gewoon generiek, geen Intel- of Cisco-codering erin, ze identificeren zich als de OEM die ze gebouwd heeft. Ik heb de derde module ook in een ernaast staande IBM RackSwitch G8124 gezet en kreeg daar hetzelfde gedrag, dus dit is niet één kapotte cage of één kapotte optiek.
Op de oudere streams is er een boot-loadervariabele die de approval check uitzet. Hij staat beschreven voor 5.x, 6.x, 7.x en 8.3.x of lager, dus een 7.x-box valt binnen bereik.
Daarvoor heb je de seriële console nodig, de mini-USB RS232-poort, niet het netwerk. Herstart de switch en houd Shift+M ingedrukt tijdens de geheugentest tot de boot loader je de
=>-prompt geeft, dan:De waarde is hoofdlettergevoelig,
Overridemet een hoofdletter O. Draaiprintenvvoorbootzodat je echt kunt zien dat de variabele is opgeslagen. Zodra de switch klaar is met opstarten, stopt hij met het uitschakelen van unapproved SFP+-modules en komen de poorten gewoon op.Twee kanttekeningen. Dit is een lab- en noodmaatregel, Lenovo ondersteunt geen third-party optiek en niets hierin is officieel. En blijf bij dual-rate optiek uit de buurt op deze oudere boxen, die veroorzaken problemen zelfs nadat de check eruit is.
Het is hetzelfde verhaal over de hele Lenovo-switchlijn, niet alleen de G8124E. Ik heb hier een G8272 die een Cisco-Finisar
SFP-10G-LR-Sals Unapproved beoordeelt, de poort als Disabled toont en de link down laat. Een echte Cisco-optiek, simpelweg niet op Lenovo's lijst.Aan de ThinkSystem-kant, NE1032 en NE1032T, is het CNOS in plaats van ENOS, en daar loop je binnen via een platformcommando om unsupported transceivers toe te staan in plaats van de boot-loadertruc. Ik heb dat zelf niet uitgeprobeerd, dus verifieer de syntax op je eigen box voordat je er een venster omheen plant. Het onderliggende patroon verandert niet: de firmware vergelijkt de vendor-string uit de EEPROM met een lijst en schakelt uit wat hij niet herkent.
Eén ding om daaraan toe te voegen: de override overleeft een firmware-upgrade niet per se. Push je een nieuw image en gaan de poorten weer dood, ga dan terug naar de seriële console en check
printenvvoordat je modules gaat trekken, de variabele kan gewoon weg zijn.En behandel vendor-unlockschakelaars in het algemeen niet als betrouwbaar. Op Catalyst 9200 met IOS-XE 16.9.x heeft
service unsupported-transceiverdankzij CSCvk03296 helemaal geen effect, en wat mensen in plaats daarvan gebruikten wasno errdisable recovery cause gbic-invalidin de global config, wat de poorten behoedde voor err-disable en FS- en Cables and Kits-modules liet draaien. Andere vendor, zelfde les: de gedocumenteerde knop en de knop die echt werkt zijn niet altijd dezelfde.