Third-party DWDM SFP+ blijft down op Arista 7050T met EOS 4.10.6 - kan dat ook zonder de image te patchen?

Voordat iemand je richting de image stuurt, twee dingen.

Aan welke EOS-train zit je op die 7050T eigenlijk vast? Als hij op 4.10.6 moet blijven staan is een build-specifieke hack in elk geval consistent met zichzelf. Kun je wel opschuiven, besef dan dat de transceiver-afhandeling in latere releases is gereorganiseerd en geen enkel recept voor 4.10.6 overdraagbaar is.

En wat kan die leverancier er eigenlijk in branden? Het is de moeite waard om te vragen of hun programmer überhaupt een Arista-profiel heeft, of alleen de per-platform Cisco-codering die de meeste van hen aanhouden - ASR9K-onderdelen bijvoorbeeld hebben hun eigen profiel nodig en de optics-leveranciers onderhouden er wel een. De batch laten hercoderen is een stuk goedkoper dan leven met een aangepaste image. Los daarvan: heb je je accountteam al om de unsupported-transceiver-key gevraagd, of ligt dat om commerciële redenen niet op tafel?

De image-patch werkt op precies die build, en het is niet veel werk - maar doe het op een lab- of reservebox, nooit op iets dat verkeer draagt.

In het kort: unzip EOS-4.10.6.swi en bewaar de members, dat zijn boot0, initrd-i386, linux-i386, rootfs-i386.sqsh en version. Pak het rootfilesystem uit als root, bewerk de agent, pak opnieuw in:

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

De aanpassing zelf zit in squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: commentarieer de vier regels rond regel 172 uit die de presence-status controleren en daarna de transceiver-authenticatie draaien. De -Z store bij de zip is niet optioneel, de swi moet ongecomprimeerd blijven of de box boot hem niet.

Daarna komen de poorten op met wat je er ook in stopt, omdat er niets meer gevalideerd wordt. Twee prijzen: je hebt geen vendor-support meer op een aangepaste image, en de patch is aan deze build gebonden, dus bewaar de stock .swi op flash om op terug te vallen als er iets misgaat.

Om de vragen hierboven te beantwoorden: de box is een reserve-unit zonder supportcontract, en de leverancier heeft helemaal geen Arista-profiel in hun programmer - ze coderen voor Cisco-platforms en daar houdt de lijst op, dus deze batch laten hercoderen wordt niet aangeboden. De accountteam-route ligt niet van tafel, die helpt me deze week alleen niet.

Ik heb 4.10.6 herbouwd zoals beschreven, de gepatchte image opgestart, en beide DWDM-poorten kwamen bij de eerste poging op. De stock image staat nog steeds op flash. De link is sindsdien stabiel, en de andere kant ziet niets ongewoons.

Fijn dat het werkte, maar wees eerlijk tegen jezelf over de houdbaarheid van die patch, want de thread hierboven doet het algemener klinken dan het is.

Hij is geschreven voor 4.10.6 en niets anders. Mensen hebben gevraagd hoe je dit herhaalt op 4.14.5F, 4.14.7M en 4.23.8M en niemand heeft ooit een werkend antwoord gepost, omdat de transceiver manager in de latere releases is gereorganiseerd en die vier regels daar niet meer op je liggen te wachten. Elke upgrade vervangt ook de image, dus de patch is weg en de poorten vallen de volgende keer dat iemand routine-onderhoud doet.

De routes die een upgrade overleven zijn de klantspecifieke service unsupported-transceiver-key die het accountteam uitgeeft, en op de oudere platforms het enable3px-markerbestand. Gebruik de gepatchte image om een oude box bruikbaar te houden, niet als standaard voor het netwerk.

Zelfde gevecht aan de Cisco-kant, met een detail dat de moeite waard is om mee te nemen. Third-party 80 km DWDM SFP+ (Pro10Optix, gelabeld SFP-10G-DWDM-192) draaide zonder klachten in Catalyst 6500-switches. Verplaatst naar de ingebouwde SFP+-poorten van een ASR 9001 op IOS XR 5.3.3 gaven ze:

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

Rode poort-LED, interface down, status gemeld als link loss of low light zonder loopback, golflengte teruggelezen als 0 nm en de laser die nooit vuurt. transceiver permit pid all op de interface veranderde op zichzelf niets, en de globale service unsupported-transceiver daarbovenop redde die batch ook niet. Het platform verwacht een partnummer in de vorm DWDM-SFP10G-xx.yy uit zijn eigen optics-matrix, en een generieke PID mapt naar helemaal geen ondersteunde optic, dus is er niets voor de override om te versoepelen.

Iemand anders op dezelfde release kreeg Skylane SPDTU080100D139 80 km modules werkend op een 9001 - maar alleen met beide commando's geconfigureerd, anders herstelde de interface niet na een link bounce. De falende batch is uiteindelijk omgeruild voor correct gecodeerde modules.

Nog iets dat je een retourtje naar de leverancier bespaart: laat ze coderen voor het platform, niet voor het merk. Een groot deel van deze threads gaat over modules die zich als de juiste vendor identificeren maar een partnummer dragen waar de matrix van het platform nog nooit van gehoord heeft, en permit-achtige overrides versoepelen de check alleen voor modules die de box verder als correct ziet.

Laat ze, zolang de modules toch op de bank liggen, bevestigen dat de EEPROM strikt SFF-8472-conform is. Slordige A2h-data leest terug als onzin - de 0 nm golflengte hierboven is precies van dat soort - en zodra de uitlezing schoon is en het platform het onderdeel nog steeds weigert, heb je iets concreets voor vendor support in plaats van een algemeen argument over third-party optics.