L'uplink 100GE del Huawei CE6800 verso un Profitap XX-3200G non sale mai con ottiche SR4
Sto sostituendo la coppia di aggregazione esistente di un cliente con apparati CloudEngine, e l'unico link che si rifiuta di salire è il feed 100GE verso il loro packet broker. Tutto il resto sullo switch è andato senza intoppi.
- Huawei CloudEngine 6800, porta 100GE
- moduli 100GBASE-SR4 QSFP28, parti Huawei, uno per lato
- packet broker Profitap XX-3200G dall'altra parte
Entrambi i lati vedono il proprio modulo. Il log dello switch non ha altro che le voci di inserimento e rimozione del transceiver di quando stavo riposizionando i moduli, nessun allarme, e l'interfaccia resta semplicemente down:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECCosa ho già provato:
- sostituiti entrambi i moduli con ricambi e pulite le estremità MPO, nessun cambiamento;
- spostato il link su un'altra porta 100GE dello switch;
- controllato il lato broker, rileva il proprio modulo e non segnala nulla di anomalo.
Quindi le ottiche sono riconosciute su entrambi i lati, niente si lamenta, e non c'è link. Cos'altro deve combaciare tra una porta 100GE CloudEngine e un apparecchio di terze parti prima che il link faccia training?
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 3
È un mismatch di FEC. CloudEngine abilita RS-FEC di default sulle porte 100GE con ottiche SR4, il broker non ha nessuna impostazione FEC e quindi gira senza, e due lati in disaccordo sul FEC non completano mai il training. Non c'è niente di rotto, quindi non viene loggato niente, ed è per questo che il log ha solo i tuoi messaggi di inserimento e rimozione.
Disattivalo sullo switch, nella view dell'interfaccia:
undo fec modefa la stessa cosa. La seconda riga è quella che conta. CE ha una configurazione a due stadi, e unfec mode nonenon committato sembra perfettamente corretto quando rileggi la config mentre la porta resta down esattamente come prima. Ho visto un caso cliente trascinarsi per un giorno in più per questo motivo, con tutti convinti che il FEC fosse già disabilitato.Dopo il commit,
display interfacedovrebbe mostrare FEC: NONE e la porta dovrebbe fare training.Se mai il lato remoto guadagnasse un'impostazione FEC, la soluzione migliore è abilitare RS-FEC lì e lasciare lo switch sul suo default, visto che sui 100G la correzione la vuoi davvero. Tra due vendor diversi imposterei il FEC esplicitamente su entrambi i lati piuttosto che fidarmi che venga negoziato.
Cosa dice il broker riguardo al FEC dal suo lato, ammesso che dica qualcosa? Tu hai già postato tu stesso la metà interessante: la porta dello switch sta girando in RS-FEC. Huawei è esplicita sul fatto che entrambi i lati di un link 100GE devono usare la stessa modalità FEC, altrimenti le interfacce non salgono mai, e quel guasto assomiglia esattamente al tuo: entrambi i moduli sani, nessun allarme, nessun log, porta down.
La maggior parte dei packet broker e dei tap con cui ho lavorato non espone affatto una manopola per il FEC, il che significa che girano senza, ed è lo switch il lato che deve cedere. Conferma prima questo, poi cambia una cosa sola.
Vale la pena aggiungere che il default di CloudEngine non è un valore unico, dipende dal modulo. QSFP28-100G-LR4 e QSFP28-100G-LR1 girano con FEC off secondo IEEE 802.3, mentre tutti gli altri tipi QSFP28 hanno FEC on di default. Quindi il consiglio di disattivarlo e basta è sbagliato su un link LR4, dove lo switch è già off e il mismatch sta dall'altra parte.
Altre due regole dello stesso capitolo che mi hanno fregato:
Quindi controlla cosa hai davvero in mano con
display transceiver interface 100GE1/0/1 verboseprima di decidere in che direzione spingere il FEC, e ricordati il commit in ogni caso.