EX4200 reports the SFP+ EEPROM as mis-programmed after a Junos upgrade while an MX960 still shows DOM
We run a handful of 80 km DWDM spans off EX4200s with third-party optics on both ends, because the vendor-branded DWDM parts were never going to fit the budget. That was fine for years. After the EX boxes were moved to Junos 12.3 the optics still sit in the same ports and the spans still exist, but the switch has stopped admitting that the modules are optics at all.
- EX4200, Junos 12.3 (DOM worked fine on 11.4 in the same chassis)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- MX960 at the far end of the same span, identical part number, DOM still complete
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableThe messages log prints exactly one line when the module is inserted: SFP+ of type 0 EEPROM is Mis Programmed.
What I have already ruled out:
- reseated the optic and moved it to another port on the same chassis, no change;
- tried a spare EX3300 and a QFX5100 in the lab, both behave the same way, so this is not one broken box;
- checked the far end again, the MX960 gives full diagnostics for the same part from the same order.
So is the EX driver enforcing something in the EEPROM that the older release simply ignored? And if it is, can anything be done to the optic itself, or is this a conversation to have with the supplier?
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
That log line is not a generic grumble, it is the driver telling you which check failed.
Bytes 3 to 10 of page A0 hold the transceiver compliance codes described in SFF-8472 - the bits that say 10GBASE-SR, LR, ER, the SONET codes, the Fibre Channel ones and so on. On this kind of optic all eight bytes are zero, which is why the message calls it type 0. The spec expects at least one bit somewhere in that field to be set; an all-zero compliance field is not a valid module description. Older EX code never looked and went straight to parsing the diagnostics page, the newer driver validates the field first and then refuses to treat the module as a known 10G optic. Hence the unknown cable and the missing DOM. The MX line does not run that check on the same path, which is exactly why the identical part still works there.
Prove it before you argue with anybody: drop to the shell and xcvrpeek page A0 on that port, then look at offsets 3 through 10. All zeros closes the case.
Repairing it in place is where this usually falls apart. In theory xcvrpoke writes those same bytes back. In practice a lot of vendors lock the A0 page and the write returns EIO, and there is nothing you can do about that from the switch side. What is left is the supplier: either they ship optics programmed with real compliance codes, or they ship them with A0 unlocked so you can set the bits yourself. If they can do neither, that is a supplier problem wearing a Junos costume.
Two things worth pinning down before anyone starts guessing.
First, the exact release on each box. You say the EX went to 12.3, but what is the MX960 running? If it is still on an older train then the two boxes are not really comparable and the difference tells you nothing yet.
Second, is the part on the MX side literally the same SFPP-C51-80-10GD from the same batch, or the saame moedl out of a different order? Batches differ more than anyone would like.
Post
show interfaces diagnostics opticsfrom both ends, plus everything the messages log prints when you pull and reinsert the optic, not just the one line you already quoted.Same part on both ends, SFPP-C51-80-10GD, same order, consecutive serials.
On the MX960
show interfaces diagnostics opticsgives the full set: temperature, laser bias current, TX power, RX power. On the EX4200 the same command prints the interface header and then the unknown cable line, nothing else. Reinserting the optic producesSFP+ of type 0 EEPROM is Mis Programmedin the log and nothing more, no matter which port I use.The part that bothers me is that before the upgrade this exact optic in this exact chassis and port reported DOM without a word of complaint.
Worth adding that the read-only half of this exists on the other side of the fence too. On Cisco,
show idprom interface <if> detaildumps the identification bytes with no shell gymnastics at all, which is handy for checking a batch on a spare switch before the modules go anywhere near a Juniper box.Reading is harmless everywhere. Writing from the host is a different animal: xcvrpoke is an internal tool, it is not supported as a way to repair modules, and as noted it is blocked by the vendor lock about half the time anyway. Use it to prove what is wrong with the EEPROM, then hand that proof to whoever sold you the optics.
Same class of problem, completely different symptom, in case someone lands here from a search.
We put a no-name 1G BiDi WDM SFP into ge-0/0/1 of an EX4600 and the interface simply did not exist. Missing from
show interfaces terse, and any command against it came back witherror: device ge-0/0/1 not found. The log saidOPTIC State changed for port: 0/0/1and thenFibre channel transceiver plugged in without Fibre channel configuration!!. The EEPROM was coded so that Junos classified the module as a Fibre Channel transceiver rather than Gigabit Ethernet, so no Ethernet interface was ever created for it. No amount of configuration fixes that; a correctly coded module does.And it is not only the cheap end of the market. There was a batch of Citrix-branded 10G SFP+ that made NetScaler MPX and SDX appliances log
*** Unsupported SFP+/SFP type !at boot on the vendor's own parts. The good units carry an A2 revision marking on the label, the bad ones went back on RMA. Bad coding happens at every price point.Confirmed, and thanks for the precise offsets.
xcvrpeek on paage A0 shows offsets 3 through 10 as zeros on every one of these SFPP-C51-80-10GD units I checked, including the ones still boxed. xcvrpoke comes staright back with EIO, so A0 is locked and there is nothing to salvage on our side.
Went back to the supplier with the byte offsets and the log line quoted. They accepted it and are re-coding the batch with real compliance codes; the ones sitting in the MX960 stay where they are, since nothing on that platform complains. Marking the explanation above as the answer.