Le ottiche SFP+ di terze parti restano down su un DCS-7150S-24 di seconda mano: il file flash enable3px è ancora un'opzione?
Ho preso un paio di switch Arista di seconda mano per il laboratorio e sono finito dritto contro il blocco delle ottiche. I moduli codificati Arista fanno link, i cavi DAC passivi fanno link, e qualsiasi cosa di terze parti lascia la porta down.
Il lato laboratorio:
- DCS-7150S-24, comprato usato, nessun contratto di supporto e nessun account team dietro di me
- moduli SFP+ di terze parti assortiti
- cavi DAC passivi per le tratte corte dentro il rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upQuello che ho capito finora:
- il fatto che il DAC funzioni mentre le ottiche no mi dice che è un controllo di codifica, non il cablaggio e non un alloggiamento morto
- c'è un comando di configurazione della forma
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, che ovviamente vuole una chiave che non ho modo di ottenere - scritti più vecchi menzionano un file marcatore sulla flash invece di una chiave, ma non riesco a capire a quale generazione si applichi
Quale dei due meccanismi è quello giusto per un box di questa età, e il file flash è ancora un'opzione su un 7150S, o la chiave è l'unica strada rimasta?
Comments 6
Su quella generazione è il file, ed è rozzo tanto quanto sembra. Dalla CLI di EOS:
Un file vuoto, niente dentro - la sua semplice presenza accende le ottiche di terze parti dopo il reload. L'elenco delle piattaforme dove funziona è lungo: DCS-7120T-4S, la famiglia DCS-7050 e tutta la linea DCS-7150S tra le altre, e ogni modello ha una release EOS più recente che rispetta ancora il file, che va all'incirca da 4.13.16M sui box più vecchi fino al train 4.23 sul 7150S. Gli switch più nuovi ignorano il file completamente.
Quindi un 7150S-24 è dal lato buono di quella linea, a patto che tu non sia andato oltre quello che il modello supporta. Provalo prima di avvicinarti anche solo alla strada della chiave.
Quale train EOS c'è su quel 7150S-24, e l'hai aggiornato dopo averlo comprato? Questo conta, perché il taglio è per piattaforma piuttosto che per famiglia. Il file flag è documentato come funzionante su 7048T, 7120T-4S, 7140T-8S, le varianti SFP+ 7124 e 7148, le serie 7050 e 7150S e le line card 7548S-LC, ma l'ultima release EOS che lo rispetta ancora differisce per ciascuno di loro.
Se hai già aggiornato EOS su un box usato, c'è una discreta possibilità che tu ti sia aggiornato fuori dal trucco da solo, e allora la soluzione economica è tornare indietro di un train piuttosto che andare a caccia di una chiave.
Non ho mai toccato EOS da quando è arrivato il box, quindi è ancora su qualsiasi train ci abbia lasciato il venditore - che si è rivelato fortunato. Ho fatto il touch, write memory, reload - e i moduli SFP+ di terze parti che prima erano morti ora vengono su come porte ordinarie. Nessuna chiave, nessun account team, nient'altro necessario. I DAC hanno continuato a funzionare per tutto il tempo, come previsto.
Per chi arriva qui con un box più recente: lì il file viene davvero ignorato, e l'unica strada è una chiave crittografica per cliente che vive nella configurazione attiva come
La chiave arriva dal team account o vendite, non dal supporto - il TAC non è autorizzato a rilasciare chiavi di sblocco e ti rimanderà alla gestione account, che è un vicolo cieco quando lo switch viene dal mercato dell'usato.
Vale la pena ripeterlo per i laboratori: i cavi DAC passivi sono accettati di default qualunque sia lo stato di sblocco. Se le tratte sono abbastanza corte, puoi aggirare l'intera questione cablando con DAC e tenendo le ottiche per i link che ne hanno davvero bisogno.
Piccola correzione a «vive nella configurazione attiva»: sul codice più vecchio con cui ho lavorato c'era anche una variante non documentata dello stesso comando, quindi se trovi un riferimento che non corrisponde alla sintassi sopra, è da lì che viene piuttosto che da un errore di battitura di qualcuno.
Nella mia esperienza la chiave ha avuto effetto anche senza reboot - la maggior parte delle ottiche di terze parti ha iniziato a funzionare subito dopo aver inserito il comando, anche se un paio di moduli hanno continuato a rifiutarsi comunque. Era un po' di tempo fa su hardware che non ho più, quindi verificalo sul tuo box prima di pianificarci intorno una finestra di manutenzione.
Dato che questo confronto salta fuori ogni volta che salta fuori l'argomento: su Cisco IOS-XE e IOS XR l'equivalente sono due passi invece di uno. Il comando globale da solo non basta, serve anche quello per interfaccia su ogni porta fisica che deve accettare il modulo:
La riga per interfaccia è quella che salta il controllo del product ID, quindi la porta almeno tenterà di accendere l'ottica - nessuna promessa che il modulo poi funzioni, solo che la piattaforma smette di rifiutarlo. L'ho fatto su IOS XR 5.3.3 e su box IOS-XE.
L'avvertenza è la stessa su entrambi i vendor, ed è il motivo per cui la gente continua a discuterne: se un guasto viene ricondotto a un transceiver di terze parti installato dal cliente, il supporto in garanzia o sotto contratto può essere negato. Va bene per un laboratorio, una decisione da prendere consapevolmente in produzione.