Third-Party-DWDM-SFP+ bleibt auf einem Arista 7050T mit EOS 4.10.6 unten: gibt es etwas Milderes als das Image zu patchen

Bevor dich jemand aufs Image schickt, zwei Dinge.

An welchen EOS-Zweig bist du auf diesem 7050T eigentlich gebunden? Muss er auf 4.10.6 bleiben, ist ein build-spezifischer Hack wenigstens in sich konsistent. Kannst du ihn bewegen, dann bedenke, dass die Transceiver-Behandlung in späteren Releases umgebaut wurde und kein für 4.10.6 geschriebenes Rezept übertragbar ist.

Und was kann dieser Lieferant den Modulen überhaupt einbrennen? Fragen würde ich, ob sein Programmiergerät überhaupt ein Arista-Profil kennt, oder nur die plattformspezifische Cisco-Codierung, die die meisten von ihnen führen - ASR9K-Teile zum Beispiel brauchen ihr eigenes Profil, und die Optik-Hersteller pflegen eines. Die Charge umcodieren zu lassen ist deutlich billiger, als mit einem modifizierten Image zu leben. Getrennt davon: hast du dein Account-Team schon nach dem unsupported-transceiver-Key gefragt, oder ist das aus kommerziellen Gründen vom Tisch?

Der Image-Patch funktioniert tatsächlich auf genau diesem Build, und viel Arbeit ist es nicht - aber mach das auf einer Labor- oder Ersatzbox, nie auf etwas, das Traffic trägt.

So läuft es ab: EOS-4.10.6.swi entpacken und die Bestandteile behalten, das sind boot0, initrd-i386, linux-i386, rootfs-i386.sqsh und version. Das Root-Dateisystem als root entpacken, den Agent bearbeiten, wieder packen:

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

Die eigentliche Änderung liegt in squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: die vier Zeilen nahe Zeile 172 auskommentieren, die den Presence-Status prüfen und danach die Transceiver-Authentifizierung ausführen. Das -Z store beim zip ist nicht optional, die swi muss unkomprimiert bleiben, sonst bootet die Box sie nicht.

Danach kommen die Ports mit allem hoch, was man einsteckt, weil nichts mehr validiert. Zwei Preise dafür: kein Hersteller-Support mehr auf einem modifizierten Image, und der Patch ist an diesen Build gebunden, also die Stock-.swi auf dem Flash behalten, um zurückzubooten, wenn etwas schiefgeht.

Um die Fragen oben zu beantworten: die Box ist eine Reserve ohne Support-Vertrag, und der Lieferant hat überhaupt kein Arista-Profil in seinem Programmiergerät - er codiert für Cisco-Plattformen, und das ist das Ende der Liste, ein Umcodieren dieser Charge steht also nicht im Angebot. Die Account-Team-Route ist nicht vom Tisch, sie hilft mir nur diese Woche nicht.

Ich habe 4.10.6 wie beschrieben neu gebaut, das gepatchte Image gebootet, und beide DWDM-Ports kamen beim ersten Versuch hoch. Das Stock-Image liegt noch auf dem Flash. Der Link ist seitdem stabil, und das ferne Ende sieht nichts Ungewöhnliches.

Schön, dass es funktioniert hat, aber sei ehrlich mit dir selbst über die Haltbarkeit dieses Patches, denn der Thread oben klingt allgemeiner, als er ist.

Er ist für 4.10.6 geschrieben und für nichts sonst. Leute haben gefragt, wie man das auf 4.14.5F, 4.14.7M und 4.23.8M wiederholt, und niemand hat je eine funktionierende Antwort gepostet, weil der Transceiver-Manager in den späteren Releases umgebaut wurde und diese vier Zeilen dort nicht mehr auf dich warten. Jedes Upgrade ersetzt außerdem das Image, der Patch ist also weg, und die Ports fallen beim nächsten Routine-Wartungstermin.

Die Wege, die ein Upgrade überleben, sind der kundenspezifische service unsupported-transceiver-Key, den das Account-Team ausstellt, und auf den älteren Plattformen die enable3px-Markierungsdatei. Das gepatchte Image nutzen, um eine alte Box brauchbar zu halten, nicht als Standard fürs Netz.

Derselbe Kampf auf der Cisco-Seite, mit einem Detail, das man mitnehmen sollte. Third-Party-80-km-DWDM-SFP+ (Pro10Optix, beschriftet als SFP-10G-DWDM-192) liefen klaglos in Catalyst-6500-Switches. In die eingebauten SFP+-Ports eines ASR 9001 unter IOS XR 5.3.3 gesteckt, gaben sie:

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

Rote Port-LED, Interface down, Status gemeldet als link loss oder low light ohne Loopback, Wellenlänge als 0 nm zurückgelesen, und der Laser feuerte nie. transceiver permit pid all am Interface änderte für sich genommen nichts, und das globale service unsupported-transceiver obendrauf rettete diese Charge auch nicht. Die Plattform erwartet aus ihrer eigenen Optik-Matrix eine Teilenummer in der Form DWDM-SFP10G-xx.yy, und eine generische PID mappt auf gar keine unterstützte Optik, es gibt also nichts, was der Override lockern könnte.

Jemand anders hatte auf demselben Release Skylane-SPDTU080100D139-80-km-Module an einem 9001 zum Laufen gebracht - aber nur mit beiden Befehlen konfiguriert, sonst erholte sich das Interface nach einem Link-Bounce nicht. Die fehlerhafte Charge wurde am Ende gegen korrekt codierte Module getauscht.

Noch eine Sache, die eine Extra-Runde beim Lieferanten spart: ihn bitten, für die Plattform zu codieren, nicht für die Marke. Ein großer Teil dieser Threads sind Module, die sich als der richtige Hersteller ausgeben, aber eine Teilenummer tragen, von der die Matrix der Plattform noch nie gehört hat, und permit-artige Overrides lockern die Prüfung nur bei Modulen, die der Box ansonsten richtig erscheinen.

Solange die Module auf der Werkbank liegen, sollen sie bestätigen lassen, dass das EEPROM streng SFF-8472-konform ist. Schlampige A2h-Daten lesen sich als Unsinn zurück - die oben erwähnte 0-nm-Wellenlänge ist genau diese Sorte - und sobald das Auslesen sauber ist und die Plattform das Teil trotzdem ablehnt, hat man etwas Konkretes für den Hersteller-Support statt eines allgemeinen Arguments über Third-Party-Optik.