EX4200 meldet das SFP+-EEPROM nach einem Junos-Upgrade als falsch programmiert, während eine MX960 weiterhin DOM zeigt
Wir betreiben eine Handvoll 80-km-DWDM-Strecken über EX4200 mit Drittanbieter-Optiken an beiden Enden, weil die herstellergebrandeten DWDM-Teile budgetmäßig nie infrage kamen. Das lief jahrelang gut. Nachdem die EX-Boxen auf Junos 12.3 gezogen wurden, sitzen die Optiken noch in denselben Ports und die Strecken existieren noch, aber der Switch gibt nicht mehr zu, dass die Module überhaupt Optiken sind.
- EX4200, Junos 12.3 (DOM lief auf 11.4 im selben Chassis einwandfrei)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- MX960 am anderen Ende derselben Strecke, identische Teilenummer, DOM weiterhin vollständig
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableDas Meldungslog druckt genau eine Zeile, wenn das Modul gesteckt wird: SFP+ of type 0 EEPROM is Mis Programmed.
Was ich schon ausgeschlossen habe:
- die Optik neu eingesetzt und auf einen anderen Port am selben Chassis verschoben, keine Änderung;
- eine Ersatz-EX3300 und eine QFX5100 im Labor probiert, beide verhalten sich gleich, das ist also keine einzelne kaputte Box;
- das andere Ende erneut geprüft, die MX960 liefert für dasselbe Teil aus derselben Bestellung volle Diagnostik.
Erzwingt der EX-Treiber also etwas im EEPROM, was das ältere Release einfach ignoriert hat? Und falls ja, lässt sich an der Optik selbst etwas machen, oder ist das ein Gespräch, das man mit dem Lieferanten führen muss?
Comments 6
Diese Log-Zeile ist keine allgemeine Nörgelei, sie ist der Treiber, der sagt, welche Prüfung fehlgeschlagen ist.
Bytes 3 bis 10 von Seite A0 enthalten die Transceiver-Compliance-Codes aus SFF-8472 - die Bits, die 10GBASE-SR, LR, ER, die SONET-Codes, die Fibre-Channel-Codes und so weiter angeben. Bei dieser Art Optik sind alle acht Bytes null, weshalb die Meldung sie type 0 nennt. Die Spezifikation erwartet, dass irgendwo in diesem Feld mindestens ein Bit gesetzt ist; ein komplett auf null stehendes Compliance-Feld ist keine gültige Modulbeschreibung. Älterer EX-Code hat nie hingeschaut und ist direkt zum Parsen der Diagnostikseite übergegangen, der neuere Treiber validiert das Feld zuerst und weigert sich dann, das Modul als bekannte 10G-Optik zu behandeln. Daher das unknown cable und das fehlende DOM. Die MX-Linie führt diese Prüfung auf demselben Pfad nicht aus, genau deshalb funktioniert dasselbe Teil dort weiterhin.
Beweisen, bevor man mit irgendwem streitet: in die Shell wechseln und auf diesem Port xcvrpeek page A0 ausführen, dann die Offsets 3 bis 10 ansehen. Lauter Nullen schließt den Fall.
Das Reparieren vor Ort ist der Punkt, an dem es meistens scheitert. Theoretisch schreibt xcvrpoke dieselben Bytes zurück. In der Praxis sperren viele Hersteller die A0-Seite, und der Schreibzugriff liefert EIO, und von der Switch-Seite aus lässt sich daran nichts ändern. Was bleibt, ist der Lieferant: Entweder er liefert Optiken mit echten Compliance-Codes programmiert, oder er liefert sie mit entsperrter A0-Seite, sodass man die Bits selbst setzen kann. Kann er keines von beidem, ist das ein Lieferantenproblem im Junos-Kostüm.
Zwei Dinge, die man festnageln sollte, bevor jemand zu raten anfängt.
Erstens das genaue Release auf jeder Box. Du sagst, die EX ist auf 12.3 gegangen, aber was läuft auf der MX960? Wenn die noch auf einem älteren Zweig ist, sind die beiden Boxen nicht wirklich vergleichbar, und der Unterschied sagt vorerst nichts.
Zweitens: Ist das Teil auf der MX-Seite buchstäblich dasselbe SFPP-C51-80-10GD aus derselben Charge, oder dasselbe Modell aus einer anderen Bestellung? Chargen unterscheiden sich mehr, als es jedem lieb wäre.
show interfaces diagnostics opticsvon beiden Enden posten, dazu alles, was das Meldungslog beim Ziehen und erneuten Stecken der Optik druckt, nicht nur die eine Zeile, die du schon zitiert hast.Gleiches Teil an beiden Enden, SFPP-C51-80-10GD, gleiche Bestellung, fortlaufende Seriennummern.
Auf der MX960 liefert
show interfaces diagnostics opticsden vollen Satz: Temperatur, Laser-Biasstrom, TX-Power, RX-Power. Auf der EX4200 druckt derselbe Befehl den Interface-Header und dann die unknown-cable-Zeile, sonst nichts. Erneutes Stecken der Optik erzeugtSFP+ of type 0 EEPROM is Mis Programmedim Log und nichts weiter, egal welchen Port ich nehme.Was mich stört: Vor dem Upgrade hat genau diese Optik in genau diesem Chassis und Port DOM gemeldet, ohne ein Wort der Klage.
Ergänzend: Die reine Lesehälfte davon gibt es auch auf der anderen Seite des Zauns. Bei Cisco kippt
show idprom interface <if> detaildie Identifikationsbytes aus, ganz ohne Shell-Verrenkungen, praktisch, um eine Charge an einem Ersatzswitch zu prüfen, bevor die Module überhaupt in die Nähe einer Juniper-Box kommen.Lesen ist überall harmlos. Schreiben vom Host aus ist ein anderes Tier: xcvrpoke ist ein internes Tool, nicht als Weg unterstützt, Module zu reparieren, und wie schon gesagt, etwa die Hälfte der Zeit ohnehin vom Vendor Lock blockiert. Damit beweisen, was am EEPROM falsch ist, und den Beweis dann an den weiterreichen, der einem die Optiken verkauft hat.
Gleiche Problemklasse, ganz anderes Symptom, für den Fall, dass jemand über eine Suche hier landet.
Wir haben ein No-Name-1G-BiDi-WDM-SFP in ge-0/0/1 eines EX4600 gesteckt, und das Interface existierte schlicht nicht. Fehlte in
show interfaces terse, und jeder Befehl dagegen kam miterror: device ge-0/0/1 not foundzurück. Das Log sagteOPTIC State changed for port: 0/0/1und dannFibre channel transceiver plugged in without Fibre channel configuration!!. Das EEPROM war so codiert, dass Junos das Modul als Fibre-Channel-Transceiver statt als Gigabit Ethernet einstufte, es wurde also nie ein Ethernet-Interface dafür angelegt. Keine noch so große Konfiguration behebt das; ein korrekt codiertes Modul schon.Und das ist nicht nur am billigen Ende des Marktes so. Es gab eine Charge Citrix-gebrandeter 10G-SFP+, die NetScaler-MPX- und SDX-Appliances beim Booten
*** Unsupported SFP+/SFP type !loggen ließ, und zwar auf den eigenen Teilen des Herstellers. Die guten Einheiten tragen eine A2-Revisionsmarkierung auf dem Etikett, die schlechten gingen per RMA zurück. Schlechte Codierung passiert auf jedem Preisniveau.Bestätigt, und danke für die genauen Offsets.
xcvrpeek auf Seite A0 zeigt bei jeder dieser SFPP-C51-80-10GD-Einheiten, die ich geprüft habe, einschließlich der noch verpackten, die Offsets 3 bis 10 als Nullen. xcvrpoke kommt sofort mit EIO zurück, A0 ist also gesperrt, und auf unserer Seite gibt es nichts zu retten.
Bin mit den Byte-Offsets und der zitierten Log-Zeile zum Lieferanten zurück. Er hat es akzeptiert und codiert die Charge mit echten Compliance-Codes neu; die Einheiten, die in der MX960 stecken, bleiben, wo sie sind, weil auf dieser Plattform nichts meckert. Markiere die Erklärung oben als Antwort.