Cluster SRX1500 su fibra spenta: la porta HA CONTROL resta muta con SFP-LH 740-011612
Due SRX1500 si trovano in data center separati, a pochi chilometri di distanza, collegati da coppie di fibra spenta che possediamo end-to-end. Devono formare un chassis cluster, il che significa che il link di controllo deve attraversare quella fibra invece di una bretella dentro un solo rack.
La configurazione:
- due Juniper SRX1500, stessa build hardware
- Juniper SFP-LH 740-011612 nella porta HA CONTROL di ciascun nodo
- una coppia di fibra spenta dedicata per il link di controllo, patchata diretta
- il modulo in rame SFP-T fornito di serie con lo chassis, usato in precedenza per un test back-to-back
Con l'SFP-LH inserito non c'è assolutamente nulla. Nessun LED sulla cage, nessun link, e il cluster non si forma mai:
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 DownCosa ho già fatto:
- spostato il link di controllo sulla seconda coppia di fibra, nessun cambiamento su nessuno dei due nodi
- scambiato i moduli tra i due nodi, stesso risultato su entrambi
- rimesso l'SFP-T come controllo di sanità, ed è rimasto giù finché non ho fatto un riavvio completo dello chassis, dopo il quale è salito immediatamente
Quest'ultimo punto mi preoccupa più dell'ottica morta. La porta HA CONTROL su un SRX1500 accetta in generale l'SFP-LH 740-011612 o l'SFP-SX 740-011613, oppure solo l'SFP-T fornito di serie? E qualcuno ha mai fatto funzionare un SFP DWDM in quella porta?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Prima di dare la colpa all'ottica, cosa vede realmente l'apparato in quella cage? Lancia
show chassis hardwarecon l'SFP-LH inserito e verifica se compare una riga Xcvr per quello slot, su entrambi i nodi. Se il modulo non viene nemmeno inventariato, non è un problema di fibra o di lunghezza d'onda, e nessuno scambio di coppie lo cambierà.Seconda cosa, dieci minuti di lavoro: metti uno di quei moduli SFP-LH in una porta di produzione contro un peer noto e funzionante. Se lì si aggancia e resta muto nella cage HA, hai separato il modulo dalla porta e puoi smettere di discutere sulla pianta di fibra.
Sulla metà DWDM della domanda c'è almeno un dato di fatto: qualcuno che fa girare ottiche DWDM Champion ONE sulla serie SRX1500 le ha fatte funzionare. Prima di andare in quella direzione, conferma prima la lunghezza d'onda esatta con il fornitore delle ottiche o del DWDM, perché Juniper non vende necessariamente un modulo per quello, e a quel punto sei su ottiche di terze parti con tutto ciò che comporta nel momento in cui apri un case.
La porta HA control è un animale diverso e non darei per scontato che si comporti come una porta di produzione. Non esiste una lista di ottiche pubblicata per essa oltre all'SFP-T fornito con lo chassis, e il tuo stesso test dice che la cage non viene riletta a runtime: il modulo in rame è tornato solo dopo un riavvio completo dello chassis. Sembra che la porta venga inventariata al boot e che nulla la riscansioni dopo.
Se il cluster deve essere operativo a breve, tieni il trasporto fuori dal firewall. Termina la lunga distanza su apparati che fanno ottiche di mestiere, dai a ciascun SRX un link corto sul modulo che è noto accettare, e lascia che sia il trasporto a gestire la lunghezza d'onda. Meno elegante, molto più rapido da consegnare. Apri comunque un case, perché il fatto che non esista una lista di ottiche supportate per quella porta merita di per sé una risposta scritta.
Confermo la parte sul non fidarsi dello stato della porta su questi apparati. Abbiamo un cluster di due SRX380-POE-AC su Junos 21.4R3-S4.9 dove il guasto va nella direzione opposta: xe-0/0/17 e xe-0/0/18 riportano link UP con i LED accesi e nessuna fibra collegata affatto. Juniper SFP-SX 740-011613 come Xcvr 16-17, SFP+-10G-SR 740-021308 come Xcvr 18-19, entrambi i nodi mostrano lo stesso inventario in
show chassis hardware, eshow interfaces terseinsiste che le interfacce sono up.Reinserire i moduli non ha cambiato assolutamente nulla. Quelle porte erano destinate a un reth che alla fine abbiamo costruito su ge-0/0/14-15, quindi non fa male a nessuno, e non ho mai avuto una risposta su se ci sia un PR dietro. Tra questo e la tua porta di controllo muta, non tratterei lo stato delle ottiche su un SRX in cluster come prova di nulla di fisico.
Due note a margine per quando andrai più avanti su questa strada.
Se un'ottica DWDM finisce davvero nel percorso, controlla la grid prima di ordinare: una tunable a 50 GHz contro ottiche fisse a 100 GHz sul lato remoto è un modo ben noto per perdere una nottata, e su Junos il canale deriva dall'opzione wavelength piuttosto che da qualcosa che imposti sull'interfaccia. Inoltre non farti prendere dal panico se l'apparato riporta un numero di canale che non corrisponde a quanto configurato mentre la luce è sulla lunghezza d'onda giusta. Capita abbastanza spesso sulle tunable Cisco che la lettura da CLI non sia la cosa di cui fidarsi.
Sul tema generale della documentazione scarsa per queste cage: stessa piattaforma, un modulo in rame SRX-SFP-1GE-T si aggancia tranquillamente a 1 Gbps e rifiuta di salire a 100 Mbps, con la guida hardware che chiama le porte SFP 100/1000 mentre il datasheet del modulo dice 10/100/1000. Nemmeno a me nessuno ha saputo dire quale delle due sia vera.