EX4200 segnala l'EEPROM SFP+ come mis-programmed dopo un upgrade di Junos, mentre un MX960 mostra ancora il DOM
Facciamo girare una manciata di tratte DWDM da 80 km su EX4200 con ottiche di terze parti su entrambi i lati, perché i componenti DWDM a marchio vendor non sarebbero mai rientrati nel budget. Per anni è andato tutto bene. Dopo che le macchine EX sono passate a Junos 12.3 le ottiche stanno ancora nelle stesse porte e le tratte esistono ancora, ma lo switch ha smesso di ammettere che i moduli siano ottiche del tutto.
- EX4200, Junos 12.3 (il DOM funzionava bene sulla 11.4 nello stesso chassis)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- MX960 all'altro capo della stessa tratta, part number identico, DOM ancora completo
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableIl log dei messaggi stampa esattamente una riga quando il modulo viene inserito: SFP+ of type 0 EEPROM is Mis Programmed.
Cosa ho già escluso:
- reinserito l'ottica e spostata su un'altra porta dello stesso chassis, nessun cambiamento;
- provato uno EX3300 di scorta e un QFX5100 in laboratorio, si comportano entrambi allo stesso modo, quindi non è una scatola sola rotta;
- ricontrollato l'altro capo, l'MX960 dà diagnostica completa per lo stesso componente dello stesso ordine.
Quindi il driver dell'EX sta imponendo qualcosa nell'EEPROM che la release più vecchia semplicemente ignorava? E se è così, si può fare qualcosa sull'ottica stessa, o è una conversazione da fare con il fornitore?
Comments 6
Quella riga di log non è un lamento generico, è il driver che ti dice quale controllo è fallito.
I byte da 3 a 10 della pagina A0 contengono i compliance code del transceiver descritti in SFF-8472: i bit che dicono 10GBASE-SR, LR, ER, i codici SONET, quelli Fibre Channel e così via. Su questo tipo di ottica tutti e otto i byte sono a zero, ed è per questo che il messaggio la chiama type 0. La specifica si aspetta che almeno un bit da qualche parte in quel campo sia impostato; un campo compliance tutto a zero non è una descrizione valida del modulo. Il codice EX più vecchio non controllava affatto e andava dritto a interpretare la pagina di diagnostica, il driver più nuovo valida prima il campo e poi si rifiuta di trattare il modulo come un'ottica 10G conosciuta. Da qui il cavo sconosciuto e il DOM mancante. La linea MX non esegue quel controllo sullo stesso percorso, ed è esattamente per questo che lo stesso identico componente lì funziona ancora.
Dimostralo prima di discuterne con chiunque: scendi alla shell e fai xcvrpeek page A0 su quella porta, poi guarda gli offset da 3 a 10. Tutti zeri chiude il caso.
Ripararlo sul posto è dove di solito la cosa si complica. In teoria xcvrpoke riscrive quegli stessi byte. In pratica un sacco di vendor bloccano la pagina A0 e la scrittura torna EIO, e da parte dello switch non c'è nulla da fare. Quello che resta è il fornitore: o spediscono ottiche programmate con compliance code veri, oppure le spediscono con la A0 sbloccata così puoi impostare i bit da solo. Se non possono fare né l'uno né l'altro, è un problema del fornitore travestito da problema Junos.
Due cose da chiarire prima che qualcuno inizi a tirare a indovinare.
Primo, la release esatta su ciascuna macchina. Dici che l'EX è passato alla 12.3, ma cosa gira sull'MX960? Se è ancora su un train più vecchio allora le due macchine non sono davvero confrontabili e per ora la differenza non ti dice niente.
Secondo, il componente lato MX è letteralmente lo stesso SFPP-C51-80-10GD dello stesso lotto, o lo stesso modello ma di un ordine diverso? I lotti differiscono più di quanto chiunque vorrebbe.
Posta
show interfaces diagnostics opticsda entrambi i capi, più tutto quello che il log dei messaggi stampa quando estrai e reinserisci l'ottica, non solo la riga che hai già citato.Stesso componente su entrambi i lati, SFPP-C51-80-10GD, stesso ordine, seriali consecutivi.
Sull'MX960
show interfaces diagnostics opticsdà il set completo: temperatura, corrente di bias del laser, TX power, RX power. Sull'EX4200 lo stesso comando stampa l'header dell'interfaccia e poi la riga unknown cable, nient'altro. Reinserire l'ottica produceSFP+ of type 0 EEPROM is Mis Programmednel log e nient'altro, qualunque porta io usi.La parte che mi disturba è che prima dell'upgrade questa esatta ottica in questo esatto chassis e questa esatta porta riportava il DOM senza una parola di lamento.
Vale la pena aggiungere che la metà di sola lettura di questa storia esiste anche dall'altra parte della barricata. Su Cisco,
show idprom interface <if> detailscarica i byte di identificazione senza nessuna ginnastica da shell, il che è comodo per controllare un lotto su uno switch di scorta prima che i moduli si avvicinino a una macchina Juniper.Leggere è innocuo ovunque. Scrivere dall'host è un altro animale: xcvrpoke è uno strumento interno, non è supportato come modo per riparare i moduli, e come già detto viene bloccato dal vendor lock più o meno metà delle volte comunque. Usalo per dimostrare cosa non va nell'EEPROM, poi consegna quella prova a chi ti ha venduto le ottiche.
Stesso genere di problema, sintomo completamente diverso, nel caso qualcuno arrivi qui da una ricerca.
Abbiamo messo un SFP WDM BiDi 1G senza marchio in ge-0/0/1 di un EX4600 e l'interfaccia semplicemente non esisteva. Assente da
show interfaces terse, e qualsiasi comando contro di essa tornava conerror: device ge-0/0/1 not found. Il log dicevaOPTIC State changed for port: 0/0/1e poiFibre channel transceiver plugged in without Fibre channel configuration!!. L'EEPROM era codificata in modo che Junos classificasse il modulo come transceiver Fibre Channel invece che Gigabit Ethernet, quindi non è mai stata creata nessuna interfaccia Ethernet per esso. Nessuna quantità di configurazione risolve questo; un modulo codificato correttamente sì.E non è solo la fascia economica del mercato. C'è stato un lotto di SFP+ 10G a marchio Citrix che faceva registrare agli apparati NetScaler MPX e SDX
*** Unsupported SFP+/SFP type !all'avvio sui componenti dello stesso vendor. Le unità buone portano una marcatura di revisione A2 sull'etichetta, quelle difettose sono tornate in RMA. Una codifica sbagliata capita a ogni fascia di prezzo.Confermato, e grazie per gli offset precisi.
xcvrpeek sulla pagina A0 mostra gli offset da 3 a 10 tutti a zero su ognuna di queste unità SFPP-C51-80-10GD che ho controllato, incluse quelle ancora imballate. xcvrpoke torna subito con EIO, quindi la A0 è bloccata e non c'è niente da salvare dal nostro lato.
Sono tornato dal fornitore con gli offset dei byte e la riga di log citata. L'ha accettato e stanno ricodificando il lotto con compliance code veri; quelle che stanno nell'MX960 restano dove sono, visto che su quella piattaforma non si lamenta nulla. Segno la spiegazione sopra come risposta.