QSA-adapter in een SONiC QSFP28-cage: de 10G optic linkt maar rapporteert geen DDM
We hergebruiken een stapel 10G optics op een whitebox-switch met SONiC, dus zijn een paar QSFP28-cages voorzien van QSA-achtige adapters (10GTek QSA-100A) met gewone 10G SFP+-modules erin. Mechanisch en elektrisch is dit prima. Aan de managementkant valt het uit elkaar.
- switch: 1U whitebox, SONiC gebouwd voor dat platform
- adapters: 10GTek QSA-100A, QSFP28-cage naar SFP+
- optics: 10G SFP+-modules gehaald uit een uitgefaseerde accessswitch
- dezelfde optics lezen normaal uit in een native SFP+-cage op een andere box
Wat ik zie op de geadapteerde poorten:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portTot nu toe geprobeerd:
- een tweede adapter en een tweede optic ingezet, identiek gedrag;
- het paar naar een andere QSFP28-cage verplaatst, zelfde resultaat;
- geverifieerd dat de optics elders in een native SFP+-poort volledige diagnostiek rapporteren.
Is die ontbrekende diagnostiekdata iets wat een passieve adapter simpelweg niet kan doorgeven, of ligt dit aan de switchsoftwarekant? En als het software is, waar hoort de fix dan thuis: de platformlaag of de generieke transceivercode?
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 7
Voor iemand zich in platformcode verdiept: één vraag die dit in tweeën splitst. Stop een native QSFP28-module in diezelfde cage: krijg je daar diagnostiek uit, of is DDM dood op die poort ongeacht wat je erin stopt?
Leest het native onderdeel goed uit, dan zijn de cage en het I2C-pad gezond en komt het hele verhaal neer op hoe de portdriver interpreteert wat er via de adapter binnenkomt. Komt het native onderdeel ook leeg terug, stop dan met de rest van de thread te lezen, je hebt een andere storing en die heeft niets met adapters te maken.
Bekend en behoorlijk saai verschil in de managementinterface, en de adapter is hier niet de schuldige.
Aan de SFP-kant zijn twee I2C-adressen in het spel: identificatiedata woont op 0x50, de diagnostiekmap op 0x51. Een QSFP-onderdeel houdt alles onder 0x50 en bereikt de rest door pagina's te wisselen. Dus een driver die verteld is dat de cage QSFP is, gaat op zoek naar pagina's op één enkel adres en vraagt 0x51 nooit iets. Identificatie komt aannemelijk genoeg terug voor de poort om op te komen, diagnostiek lost gewoon nooit op, en dat is precies de vorm van wat jij hebt gepost.
De fix hoort thuis in de platformlaag, niet in de optic en niet in de adapter. Elk platform levert zijn eigen SfpUtil-implementatie; in de jouwe moet die poort verklaard worden als een SFP-cage in plaats van een QSFP-cage. Totdat iemand dat doet, blijft DDM/DOM op geadapteerde poorten leeg. Daarna wordt de module uitgelezen zoals hij dat in een native SFP+-cage zou zijn.
Een live link met niets erachter in de diagnostiek is hoe verkeerde software eruitziet op deze poorten. Het is niet hoe een marginale optic eruitziet.
De moeite waard om de standaarden te noemen, want dan is de scheidslijn duidelijk. De SFP-kant is SFF-8472, waar diagnostiek in zijn eigen geheugenmap woont, bereikt via het tweede adres. QSFP en QSFP28 volgen SFF-8636, en nieuwere onderdelen CMIS, waar alles onder één enkel adres hangt achter een page select.
De adapter kan dat niet overbruggen. Het is een passief mechanisch en elektrisch onderdeel, de managementdraden lopen er recht doorheen en niets vertaalt ze onderweg. Dus moet de host verteld worden welk van de twee geheugenmodellen van toepassing is voordat hij ook maar één byte leest, en de adapter heeft geen manier om hem dat te vertellen.
Ter vergelijking: dezelfde klasse probleem bijt harder op Dell ONIE-hardware. Een 407-BBRO QSA met een 407-BBOU 10GBASE-SR SFP+ erin (SFP-10GSR-85), in de 40G-poorten van een S4048-ON en in elke poort van een S6010-ON, beide met OpenSwitch OPX 3.1 dev2:
opx-ethtool identificeert het medium correct, markeert de transceiver enabled en qualified, admin state up, ondersteunde snelheden 1000, 10000 en 40000 Mbps, en de poort komt nog steeds nooit op, wat je ook aan speed, duplex of autoneg configureert, defaults inbegrepen. Iemand heeft het geopend op de OPX platform-config-repository als een enhancement request, please make the QSA work here, en niemand heeft ooit geantwoord. Hij staat nog steeds open.
Geen vendor lock en geen slechte optic. Die cage wordt door het network OS simpelweg nooit in adaptermodus gezet, en geen enkele combinatie van interface-instellingen doet dat voor je.
Verwant, maar vouw de twee gevallen alsjeblieft niet in elkaar. Wat de oorspronkelijke post heeft is een werkende link met ontbrekende diagnostiek: het datapad is prima, alleen de managementuitlezing is fout, en het patchen van de platform-SfpUtil verhelpt het. Het Dell-geval is een poort die helemaal nooit opkomt, omdat het poortprofiel voor die cage om te beginnen al nooit wordt toegepast. Dat zit een laag lager en heeft zijn eigen fix nodig.
Iemand die in de haast symptomen matcht kan een hele dag verbranden aan het herschrijven van transceivercode terwijl hun poort om een compleet ongerelateerde reden down is.
Nog een variant van "de adapter is een softwarefunctie" in plaats van een mechanische. Op een Z9264F-ON onder OS10 10.5.2.7 betekent het gebruik van QSA28-adapters voor 10G SFP+-media dat je de poort in hetzelfde port-group-profiel zet dat een 4x10G-breakoutkabel gebruikt:
Port-group-profielen op dat platform werken op paren QSFP28-poorten, dus toepassen ervan schakelt de partnerpoort van elk paar uit. Een QSA28 is een enkele interface en je betaalt toch de prijs van een breakout: 64 bruikbare poorten worden er 32. Noch de OS10-gebruikershandleidingen, noch het Dell-optics-datasheet documenteren een single-port QSA-modus.
Heb je veel native 10G nodig op die box, reken dan vooraf op het 2:1-verlies of zet een aparte 10G-switch in het rack.
Voor iemand een tray van deze dingen bestelt, zou ik twee controles op de lijst zetten. Verklaart het network OS überhaupt QSA-support voor dat exacte platform, en zo ja, wat kost het inschakelen ervan je: poorten, diagnostiek, of een profiel dat de aangrenzende cage mee omlaag trekt. Pasvorm is nooit het probleem, elk van deze adapters gaat zonder klagen in de cage.
De gevallen in deze thread verschillen alleen in hoe ver de software gaat. Op SONiC krijg je iets wat je zelf kunt fixen, verklaar de poort als SFP en de diagnostiek komt terug. Op de Dell-platforms hierboven wacht je op andermans platformcode, en adapters of optics verwisselen beweegt daar helemaal niets aan.