SFP+ DWDM di terze parti resta giù su un Arista 7050T con EOS 4.10.6 - c'è un'alternativa a patchare l'immagine

Prima che qualcuno ti indirizzi verso l'immagine, due cose.

A quale ramo EOS sei davvero vincolato su quel 7050T? Se deve restare su 4.10.6 allora un hack specifico per quella build è quantomeno coerente con se stesso. Se puoi spostarlo, tieni presente che la gestione dei transceiver è stata riorganizzata nelle release successive e nessuna ricetta scritta per 4.10.6 si trasferisce.

E cosa può davvero programmarci dentro quel fornitore? Vale la pena chiedere se il loro programmatore ha proprio un profilo Arista, o solo la codifica per piattaforma Cisco che tengono quasi tutti - le parti per ASR9K, per esempio, richiedono un profilo proprio e i vendor di ottiche ne mantengono uno. Far ricodificare il lotto costa molto meno che convivere con un'immagine modificata. A parte questo: hai già chiesto al tuo account team la chiave unsupported-transceiver, o è fuori discussione per motivi commerciali?

La patch all'immagine funziona davvero su quella build esatta, e non è nemmeno tanto lavoro - ma falla su un box di laboratorio o di scorta, mai su qualcosa che porta traffico.

In sintesi: fai l'unzip di EOS-4.10.6.swi e tieni i membri, che sono boot0, initrd-i386, linux-i386, rootfs-i386.sqsh e version. Scompatta il root filesystem come root, modifica l'agente, ricomprimi:

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

La modifica vera e propria è in squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: commenta le quattro righe vicino alla linea 172 che verificano lo stato di presenza e poi eseguono l'autenticazione del transceiver. Il -Z store sullo zip non è opzionale, lo swi deve restare non compresso o il box non lo avvierà.

Dopodiché le porte si alzano con qualsiasi cosa tu ci inserisca, perché non c'è più nulla che valida. Due prezzi da pagare: niente supporto del vendor su un'immagine modificata, e la patch è legata a questa build, quindi tieni lo .swi originale sulla flash per poterci riavviare quando qualcosa va storto.

Per rispondere alle domande di sopra: il box è di scorta e senza contratto di supporto, e il fornitore non ha alcun profilo Arista nel loro programmatore - codificano per piattaforme Cisco e la lista finisce lì, quindi ricodificare questo lotto non è un'opzione offerta. La strada dell'account team non è esclusa, solo che questa settimana non mi aiuta.

Ho ricostruito 4.10.6 come descritto, avviato l'immagine patchata, ed entrambe le porte DWDM si sono alzate al primo tentativo. L'immagine originale è ancora lì sulla flash. Il link è stabile da allora, e il lato remoto non vede niente di anomalo.

Contento che abbia funzionato, ma sii onesto con te stesso sulla durata di quella patch, perché il thread qui sopra la fa sembrare più generale di quanto sia.

È scritta per 4.10.6 e nient'altro. C'è chi ha chiesto come ripeterla su 4.14.5F, 4.14.7M e 4.23.8M e nessuno ha mai postato una risposta funzionante, perché il transceiver manager è stato riorganizzato nelle release successive e quelle quattro righe non sono lì ad aspettarti. Ogni upgrade sostituisce anche l'immagine, quindi la patch sparisce e le porte cadono alla prima manutenzione ordinaria successiva.

Le strade che sopravvivono a un upgrade sono la chiave service unsupported-transceiver specifica per il cliente che rilascia l'account team, e sulle piattaforme più vecchie il file marcatore enable3px. Usa l'immagine patchata per tenere in vita un box vecchio, non come standard per la rete.

Stessa battaglia sul lato Cisco, con un dettaglio che vale la pena portarsi dietro. SFP+ DWDM 80 km di terze parti (Pro10Optix, etichettati SFP-10G-DWDM-192) giravano nei Catalyst 6500 senza problemi. Spostati nelle porte SFP+ integrate di un ASR 9001 su IOS XR 5.3.3 hanno dato:

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

LED della porta rosso, interfaccia giù, stato riportato come link loss o low light senza loopback, lunghezza d'onda letta come 0 nm e laser mai acceso. transceiver permit pid all sull'interfaccia da solo non cambiava nulla, e il service unsupported-transceiver globale sopra di esso non ha salvato nemmeno quel lotto. La piattaforma si aspetta dalla propria matrice ottiche un partnumber nella forma DWDM-SFP10G-xx.yy, e un PID generico non corrisponde a nessuna ottica supportata, quindi non c'è niente che l'override possa allentare.

Qualcun altro sulla stessa release aveva moduli Skylane SPDTU080100D139 80 km funzionanti su un 9001 - ma solo con entrambi i comandi configurati, altrimenti l'interfaccia non si riprendeva dopo un link bounce. Il lotto difettoso è stato infine sostituito con moduli codificati correttamente.

Aggiungo una cosa che ti risparmia un giro a vuoto quando torni dal fornitore: chiedigli di codificare per la piattaforma, non per il marchio. Buona parte di questi thread sono moduli che si identificano come il vendor giusto ma portano un partnumber che la matrice della piattaforma non ha mai sentito nominare, e gli override in stile permit allentano il controllo solo per moduli che al box sembrano comunque giusti.

Finché hanno i moduli sul banco, fatti confermare che l'EEPROM è rigorosamente conforme a SFF-8472. Dati A2h sciatti si leggono come spazzatura - la lunghezza d'onda a 0 nm citata sopra è esattamente di quel genere - e una volta che la lettura è pulita e la piattaforma rifiuta comunque la parte, hai qualcosa di concreto da portare al supporto del vendor invece di un discorso generico sulle ottiche di terze parti.