L'IBM Flex System EN4093 fa cadere le porte trunk SFP+ in ERRDISABLE all'avvio e durante il funzionamento
Due chassis Flex System, ognuno con un EN4093R 10Gb Scalable Switch (opzione 49Y4270) come modulo di rete. Le porte tornano error-disabled dopo un evento di alimentazione dello chassis, e meno spesso cadono nello stesso stato mentre tutto è in funzione. Non sono sempre le stesse porte, il che è quello che rende la caccia così estenuante.
Setup:
- IBM Flex System EN4093 10Gb Scalable Switch, opzione 49Y4270
- trunk di uplink di quattro porte verso il core, ottiche IBM più un DAC aggiunto più tardi
- porta QSFP+ suddivisa (breakout) verso il secondo chassis
- MSTP in esecuzione sul nostro lato, il core è di un vendor diverso
Cosa mostra la lista porte dopo un boot:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesProvato:
- shutdown / no shutdown sulle porte interessate ne fa tornare la maggior parte finché non arriva il prossimo evento
- pulita e riseduta ogni fibra nel trunk, nessun cambiamento nello schema
- confrontata la configurazione della porta lato remoto, le velocità corrispondono sulla carta
Cosa sta davvero spingendo queste porte in errdisable, e c'è un modo per impedire che succeda a ogni boot invece di pulirlo a mano ogni volta?
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 5
Questo switch ha sette stati documentati che disabilitano una porta, e hanno pochissimo a che fare l'uno con l'altro:
Il tuo è il quarto, ed è quello che incontra più gente, perché è quello che ti costruisci da solo: mescola velocità o tipi di modulo dentro un unico trunk e lo switch protesta. Basta un DAC seduto accanto a tre moduli ottici. Togli di lì il DAC e riempi lo slot con un modulo che corrisponda agli altri tre.
Per la porta sul rilevatore di flap, rilanciarla resta il recupero documentato:
Dopo di che, rileggi la configurazione dello spanning tree su quel link e ripassa rame e fibra a mano. Fai seguire ogni modifica di configurazione da un reload, o lo stato in esecuzione smette silenziosamente di corrispondere a quello che pensi di aver impostato.
Due cose da non aspettarsi. Due di quei sette stati tengono la porta giù anche dopo che il timeout scade e vogliono una mano sulla porta. E nessuna release di firmware risolve questo - la linea del vendor è che ci si configura attorno, quindi moduli identici su ogni membro del trunk più fibra pulita è il massimo che puoi fare per prevenirlo.
Partirei da due motivi diversi nello stesso incolla. Una data porta torna sempre disabilitata per lo stesso motivo, oppure una che è caduta per le capability questo boot fa scattare il rilevatore di flap il prossimo? Un motivo che resta fisso per porta e un motivo che vaga sono due indagini separate, e solo una delle due finisce con te che compri hardware.
La seconda cosa da chiarire è cosa gira sul core per lo spanning tree. Tu sei su MSTP; se il lato remoto mette BPDU in stile Cisco PVST su quegli uplink, questo switch ha un meccanismo di protezione che reagisce esattamente a quello e porta giù la porta, e dall'esterno sembra il guasto che stai già inseguendo. Riesci a dire se qualcuna delle cadute coincide con un cambio di topologia sul core piuttosto che con i tuoi boot?
Per porta è coerente, su tutto il box no. I membri del trunk che cadono tornano sempre con mismatched link capabilities, e la porta di accesso sulla 5 fa scattare solo e sempre il rilevatore di flap, con un intervallo in cui non riesco a trovare uno schema. Quindi sembra proprio siano due guasti con la stessa giacca addosso.
Sullo spanning tree del lato remoto non posso ancora rispondere - il core appartiene a un altro team e ho chiesto loro cosa emette davvero su quegli uplink. Niente nel nostro log lega finora una caduta a un cambio di topologia lì, ma lo stavo leggendo per eventi di link piuttosto che per quello, quindi non lo definirei escluso.
Vendor diverso, stessa forma. Avevamo un FortiGate 201F attaccato a un FortiSwitch 548D su SFP+ con un DAC Fortinet tra i due, e il link 10Gbps semplicemente non restava su - cadeva qualunque cosa facessimo a velocità e duplex, e tornare indietro su entrambi i lati da FortiOS 7.4 a 7.2.5 non ha cambiato nulla.
Quello che alla fine ha tenuto è stato un DAC Fortinet più corto con STP spento su quel link, ed è su da allora. La parte che vale la pena portarsi dietro è il ragionamento venuto dopo: più lunga è la tratta in rame passivo, più il segnale si è degradato quando arriva, quindi a 10G qualsiasi DAC lungo o al limite finisce nella lista dei sospetti qualunque etichetta ci sia stampata sopra. Con tre ottiche e un DAC in un trunk errdisable, io guarderei con attenzione quello fuori posto.
Una cosa da fare prima di toccare qualsiasi hardware: annota la cadenza esatta dei flap rispetto ai timestamp del log.
Su uno switch completamente scollegato da questo, un TL-SG3452X, ogni porta SFP+ popolata andava giù e tornava su ogni dieci-quindici minuti con messaggi STP nel log a ogni flap, e la conclusione ovvia era ottiche difettose - finché un DAC TL-SM5220-1M a marchio primo ha fatto flap esattamente nello stesso ritmo. Questo ha ucciso la teoria delle ottiche in un solo test e ha puntato invece a una regressione firmware; l'unica risposta funzionante lì è stata restare sulla build più vecchia.
Un intervallo regolare significa che qualcosa va in timeout secondo una schedulazione. Uno casuale significa qualcosa di fisico. Test economico, e ti risparmia comprare moduli che non ti servono. Conviene anche tenere da parte l'immagine firmware precedente così un downgrade resta un'opzione.