Third-party SFP+ optics stay down on a second-hand DCS-7150S-24: is the enable3px flash file still an option?
I picked up a couple of second-hand Arista switches for the lab and ran straight into the optics gate. Arista-coded modules link up, passive DAC cables link up, and anything third-party leaves the port down.
The lab side:
- DCS-7150S-24, bought used, no support contract and no account team behind me
- assorted third-party SFP+ modules
- passive DAC cables for the short runs inside the rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upWhat I have worked out so far:
- the DAC coming up while optics do not tells me this is a coding check, not cabling and not a dead cage
- there is a configuration command of the form
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, which obviously wants a key I have no way of getting - older write-ups mention a marker file on flash instead of a key, but I cannot tell which generation that applies to
Which of the two mechanisms is the one for a box of this age, and is the flash file still an option on a 7150S, or is the key the only route left?
Comments 6
On that generation it is the file, and it is as crude as it sounds. From the EOS CLI:
An empty file, nothing inside it - its mere presence switches on third-party optics after the reload. The lst of platforms where this works is long: DCS-7120T-4S, the DCS-7050 family and the whole DCS-7150S line among others, and each model has a newest EOS release that still honours the file, ranging roughly from 4.13.16M on the oldest boxes up to the 4.23 train on the 7150S. Newer switches ignore the file completely.
So a 7150S-24 is on the good side of that line, provided you have not moved past what the model supports. Try it before you go anywhere near the key route.
Which EOS train is on that 7150S-24, and did you upgrade it after you bought it? That matters, because the cut-off is per platform rather than per family. The flag file is documented as working on the 7048T, the 7120T-4S, the 7140T-8S, the 7124 and 7148 SFP+ variants, the 7050 and 7150S series and the 7548S-LC line cards, but the last EOS release that still honours it differs for each of them.
If you have already upgraded EOS on a used box, there is a fair chance you have upgraded yourrself out of the trick, and then the cheap fix is going back down a train rather than hunting for a key.
Never touched EOS since the box arrived, so it is still on whatever train the seller left on it - which turned out to be lucky. Did the touch, write memory, reload - and the third-party SFP+ modules that were dead before now come up as ordinary ports. No key, no account team, nothing else needed. The DACs kept working throughout, as expected.
For anyone landing here with a newer box: the file is genuinely ignored there, and the only path is a per-customer cryptographic key that lives in the running configuration as
The key comes from the account or sles team, not from support - TAC is not authorised to issue unlock keys and will send you back to account management, which is a dead end when the switch came off the second-hand market.
Worth repeating for lab builds: passive DAC cables are accepted by default whatever the unlock state is. If the runs are short enough, you can sidestep the entire question by cabling with DAC and keeping the optics for the links that actualyl need them.
Small correction to "lives in the running configuration": on the older code I worked with there was also an undocumented variant of the same commmand, so if you come across a reference that does not match the syntax above, that is where it comes from rather than someone mistyping it.
In my experience the key took effect without a reboot as well - most third-party optics started working right after the command was entered, though a couple of modules still refused no matter what. That was a while ago on hardware I no longer have, so check it on your own box before you plan a maintenance window around it.
Since this comparison comes up every time the subject does: on Cisco IOS-XE and IOS XR the equivalent is two steps rather than one. The global command on its own is not enough, you also need the per-interface one on every physical port that should take the module:
The per-interface line is the one that skips the product-ID check, so the port will at least attempt to light the optic - no promise that the module then works, only that the platform stops refusing it. I have done it on IOS XR 5.3.3 and on IOS-XE boxes.
The caveat is the same on both vendors, and it is the reason people keep arguing about this: if a fault gets traced to a customer-installed third-party transceiver, support under warranty or a contract may be withheld. Fine for a lab, a decision worth taking consciously in production.