EX4200 meldt de SFP+-EEPROM als verkeerd geprogrammeerd na een Junos-upgrade, terwijl een MX960 nog steeds DOM toont
We draaien een handvol DWDM-trajecten van 80 km via EX4200's met optiek van derden aan beide kanten, omdat de DWDM-onderdelen van de eigen vendor nooit binnen het budget zouden passen. Dat ging jarenlang goed. Nadat de EX-boxen naar Junos 12.3 zijn overgezet, zitten de optieken nog in dezelfde poorten en bestaan de trajecten nog steeds, maar de switch erkent niet meer dat de modules optiek zijn.
- EX4200, Junos 12.3 (DOM werkte prima op 11.4 in hetzelfde chassis)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- MX960 aan het verre uiteinde van hetzelfde traject, identiek onderdeelnummer, DOM nog steeds volledig
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableHet messages-log drukt precies één regel af zodra de module wordt geplaatst: SFP+ of type 0 EEPROM is Mis Programmed.
Wat ik al heb uitgesloten:
- de optiek opnieuw geplaatst en verhuisd naar een andere poort in hetzelfde chassis, geen verandering;
- een reserve-EX3300 en een QFX5100 in het lab geprobeerd, beide gedragen zich hetzelfde, dus dit is niet één kapotte doos;
- het verre uiteinde nogmaals gecontroleerd, de MX960 geeft volledige diagnostiek voor hetzelfde onderdeel uit dezelfde bestelling.
Handhaaft de EX-driver dus iets in de EEPROM dat de oudere release gewoon negeerde? En als dat zo is, kan er dan iets aan de optiek zelf gedaan worden, of is dit een gesprek voor de leverancier?
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 6
Die logregel is geen generiek gemopper, het is de driver die je vertelt welke check faalde.
Bytes 3 tot en met 10 van pagina A0 bevatten de transceiver-compliancecodes die in SFF-8472 beschreven staan - de bits die 10GBASE-SR, LR, ER, de SONET-codes, de Fibre Channel-codes enzovoort aangeven. Bij dit soort optiek zijn alle acht bytes nul, en daarom noemt de melding het type 0. De spec verwacht dat ergens in dat veld minstens één bit gezet is; een compliance-veld dat volledig nul is, is geen geldige modulebeschrijving. Oudere EX-code keek daar nooit naar en ging direct de diagnostiekpagina parsen; de nieuwere driver valideert het veld eerst en weigert de module vervolgens als bekende 10G-optiek te behandelen. Vandaar de Unknown cable en de ontbrekende DOM. De MX-lijn voert die check niet uit op hetzelfde pad, en juist daarom werkt hetzelfde onderdeel daar nog steeds.
Bewijs het voor je met iemand in discussie gaat: ga naar de shell en doe xcvrpeek page A0 op die poort, en bekijk dan offsets 3 tot en met 10. Allemaal nullen sluit de zaak.
Het ter plekke repareren is waar het meestal misloopt. In theorie schrijft xcvrpoke diezelfde bytes terug. In de praktijk vergrendelen veel vendors de A0-pagina en komt de write terug met EIO, en daar kun je vanaf de switch niets aan doen. Wat overblijft is de leverancier: of ze leveren optiek geprogrammeerd met echte compliancecodes, of ze leveren hem met A0 ontgrendeld zodat je de bits zelf kunt zetten. Kunnen ze geen van beide, dan is dat een leveranciersprobleem in een Junos-jasje.
Twee dingen die je moet vastpinnen voordat iemand begint te gokken.
Ten eerste, de exacte release op elke box. Je zegt dat de EX naar 12.3 ging, maar wat draait de MX960? Als die nog op een oudere train zit, zijn de twee boxen niet echt vergelijkbaar en zegt het verschil nog niets.
Ten tweede, is het onderdeel aan de MX-kant letterlijk dezelfde SFPP-C51-80-10GD uit dezelfde batch, of hetzelfde model uit een andere bestelling? Batches verschillen meer dan iedereen zou willen.
Post
show interfaces diagnostics opticsvan beide kanten, plus alles wat het messages-log afdrukt wanneer je de optiek eruit haalt en opnieuw plaatst, niet alleen de ene regel die je al citeerde.Zelfde onderdeel aan beide kanten, SFPP-C51-80-10GD, dezelfde bestelling, opeenvolgende serienummers.
Op de MX960 geeft
show interfaces diagnostics opticsde volledige set: temperatuur, laserbiasstroom, TX-vermogen, RX-vermogen. Op de EX4200 drukt hetzelfde commando de interface-header af en dan de Unknown cable-regel, verder niets. De optiek opnieuw plaatsen levertSFP+ of type 0 EEPROM is Mis Programmedop in het log en verder niets, ongeacht welke poort ik gebruik.Wat me dwarszit is dat deze exacte optiek in dit exacte chassis en deze exacte poort vóór de upgrade DOM rapporteerde zonder een woord van klacht.
Het is de moeite waard om toe te voegen dat de read-only helft hiervan ook aan de andere kant van het hek bestaat. Bij Cisco dumpt
show idprom interface <if> detailde identificatiebytes zonder enige shell-acrobatiek, wat handig is om een batch op een reserveswitch te controleren voordat de modules ook maar in de buurt van een Juniper-box komen.Lezen is overal onschadelijk. Schrijven vanaf de host is een ander verhaal: xcvrpoke is een intern tool, het wordt niet ondersteund als manier om modules te repareren, en zoals al gezegd wordt het toch al ongeveer de helft van de tijd geblokkeerd door de vendor lock. Gebruik het om aan te tonen wat er mis is met de EEPROM, en geef dat bewijs dan door aan wie je de optiek ook verkocht heeft.
Zelfde soort probleem, compleet ander symptoom, voor het geval iemand hier via een zoekopdracht terechtkomt.
We staken een no-name 1G BiDi WDM SFP in ge-0/0/1 van een EX4600 en de interface bestond gewoon niet. Ontbrak in
show interfaces terse, en elk commando ertegen kwam terug meterror: device ge-0/0/1 not found. Het log zeiOPTIC State changed for port: 0/0/1en daarnaFibre channel transceiver plugged in without Fibre channel configuration!!. De EEPROM was zo gecodeerd dat Junos de module classificeerde als Fibre Channel-transceiver in plaats van Gigabit Ethernet, dus werd er nooit een Ethernet-interface voor aangemaakt. Geen enkele configuratie lost dat op; een correct gecodeerde module wel.En het is niet alleen het goedkope segment van de markt. Er was een batch Citrix-merk 10G SFP+ die NetScaler MPX- en SDX-appliances bij het opstarten
*** Unsupported SFP+/SFP type !liet loggen, en dat op de eigen onderdelen van de vendor. De goede exemplaren hebben een A2-revisiemarkering op het label, de slechte gingen terug op RMA. Verkeerde codering gebeurt op elk prijsniveau.Bevestigd, en bedankt voor de precieze offsets.
xcvrpeek op pagina A0 toont offsets 3 tot en met 10 als nullen bij elk van deze SFPP-C51-80-10GD-units die ik gecontroleerd heb, inclusief de exemplaren die nog in de doos zitten. xcvrpoke komt meteen terug met EIO, dus A0 is vergrendeld en er valt aan onze kant niets te redden.
Ik ben teruggegaan naar de leverancier met de byte-offsets en de geciteerde logregel. Ze hebben het geaccepteerd en hercoderen de batch met echte compliancecodes; de exemplaren in de MX960 blijven zitten waar ze zitten, aangezien dat platform nergens over klaagt. Ik markeer de uitleg hierboven als het antwoord.