Third-party DWDM SFP+ stays down on an Arista 7050T with EOS 4.10.6 - anything short of patching the image?

Before anyone points you at the image, two things.

Which EOS train are you actually tied to on that 7050T? If it has to stay on 4.10.6 then a build-specific hack is at least self-consistent. If you can move it, understand that the transceiver handling was reorganised in later releases and no recipe written for 4.10.6 transfers.

And what can that supplier actually burn into them? Worth asking whether their programmer carries an Arista profile at all, or only the per-platform Cisco coding most of them keep - ASR9K parts, for instance, need their own profile and the optics vendors do maintain one. Getting the batch recoded is a lot cheaper than living on a modified image. Separately: have you asked your account team for the unsupported-transceiver key yet, or is that off the table for commercial reasons?

The image patch does work on that exact build, and it is not much work - but do it on a lab or spare box, never on anything carrying traffic.

Shape of it: unzip EOS-4.10.6.swi and keep the members, which are boot0, initrd-i386, linux-i386, rootfs-i386.sqsh and version. Unpack the root filesystem as root, edit the agent, repack:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

The edit itself is in squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: comment out the four lines near line 172 that assert the presence state and then run the transceiver authentication. The -Z store on the zip is not optional, the swi has to stay uncompressed or the box will not boot it.

After that the ports come up with whatever you plug in, because nothing is validating any more. Two prices: you have no vendor support on a modified image, and the patch is tied to this build, so keep the stock .swi on flash to boot back into when something goes sideways.

To answer the questions above: the box is a spare with no support contract on it, and the supplier has no Arista profile in their programmer at all - they code for Cisco platforms and that is the end of the list, so recoding this batch is not on offer. The account team route is not off the table, it just does not help me this week.

I rebuilt 4.10.6 as described, booted the patched image, and both DWDM ports came up on the first attempt. Stock image is still sitting on flash. Link has been steady since, and the far end sees nothing unusual.

Glad it worked, but be blunt with yourself about the shelf life of thhat patch, because the thread above makes it sound more general than it is.

It is written for 4.10.6 and nothing else. People have asked how to repeat it on 4.14.5F, 4.14.7M and 4.23.8M and nobody ever posted a working answer, because the transceiver manager was reorganised in the later releases and those four lines are not sitting there waiting for you. Every upgrade also replaces the image, so the patch is gone and the ports drop the next tmie someone does routine maintenance.

The routes that survive an upgrade are the customer-specific service unsupported-transceiver key that the account team issues, and on the older platforms the enable3px marker file. Use the patched image to keep an old box useful, not as a standard for the network.

Same fight on the Cisco side, with a detail worth carrying over. Third-party 80 km DWDM SFP+ (Pro10Optix, labelled SFP-10G-DWDM-192) had been running in Catalyst 6500 switches without complaint. Moved into the built-in SFP+ ports of an ASR 9001 on IOS XR 5.3.3 they gave:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

Red port LED, interface down, state reported as link loss or low light with no loopback, wavelength read back as 0 nm and the laser never firing. transceiver permit pid all on the interface changed nothinng on its own, and the global service unsupported-transceiver on top of it did not rescue that batch either. The platform expects a part number in the DWDM-SFP10G-xx.yy shape from its own optics matrix, and a generic PID maps to no supported optic at all, so there is nothing for the override to relax.

Someone else on the same release had Skylane SPDTU080100D139 80 km modules working on a 9001 - but only with both commands configured, otherwise the interface would not recover after a link bounce. The failing batch was eventually exchanged for properly coded modules.

Adding one thing that saves a round trip when you go back to a supplier: ask them to code for the platform, not for the brand. A large share of these threads are modules that identify as the right vendor but carry a part number the platform's matrix has never heard of, and permit-style overrides only relax the check for modules that otherwise look right to the box.

While they have the modules on the bench, have them confirm the EEPROM is strictly SFF-8472 conformant. Sloppy A2h data reads back as nonsense - the 0 nm wavelength mentioned above is exactly that flavour - and once the readout is clean and the platform still refuses the part, you have something concrete for vendor support instead of a general argument about third-party optics.