Supermicro E300-9A su pfSense Plus 22.05: ix2 e ix3 restano a no carrier con un DAC che funziona bene su uno USW-Aggregation
Il mio firewall è un Supermicro E300-9A con pfSense Plus 22.05, ed entrambe le porte 10G SFP+ rifiutano di salire. Né ix2 né ix3 mostrano mai carrier, qualunque cosa metta nella cage.
Hardware:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M e un cavo twinax passivo 10Gtek
- moduli in fibra Supermicro AXS85-192-M3 come alternativa
- Ubiquiti USW-Aggregation sul lato switch
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 si presenta uguale.
Provato finora:
- entrambi i cavi funzionano sullo USW-Aggregation tra altri dispositivi, quindi non sono morti
- sostituito il rame con i moduli in fibra AXS85-192-M3, stesso no carrier su entrambe le porte
- riavviato l'apparato più volte, compreso inserire un modulo mentre era acceso
C'è qualcosa in questo apparato che va sbloccato prima che le cage inizino a funzionare, oppure ho davvero due porte morte?
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
I riavvii a caldo non ti portano da nessuna parte - quelle porte bloccano uno stato del media e non lo riprobano mai a un restart. Spegni l'apparato correttamente, stacca l'alimentatore per un paio di minuti, poi riaccendilo con il modulo già inserito. È quello che qui ha fatto tornare entrambe le porte, e un'altra persona ha descritto un comportamento identico su una porta Intel X552, motivo per cui penso sia uno stato del media rimasto bloccato più che un problema di pfSense.
Se inserisci un modulo mentre il sistema è già acceso, rilancia l'interfaccia invece di riavviare:
Così il driver guarda di nuovo la cage. Non è una soluzione permanente per niente, ma ti risparmia un riavvio quando stai cambiando moduli sul banco. Controlla il risultato con
ifconfig -ainvece che dal pannello frontale.Fai prima la rimozione completa dell'alimentazione e conferma entrambe le cage con un DAC prima di toccare il lato switch. Qui conta fare debug di una cosa alla volta, perché "no carrier con ogni modulo" e "il link sale alla velocità sbagliata" sono di solito due guasti separati che capitano a stare sulla stessa tratta di cavo.
La rimozione completa dell'alimentazione ha risolto. Spento, staccato l'alimentatore, aspettato un paio di minuti, riacceso - entrambe le porte sono salite. Ho fatto un loop con un DAC tra ix2 e ix3 e ho ottenuto un link 10G pulito, e anche la coppia AXS85-192-M3 fa 10G tra le due porte, quindi le cage e i moduli sono a posto.
Il lato switch è un'altra storia. Verso lo USW-Aggregation il link negozia sempre e solo a 1G, e se forzo 10G su un lato qualsiasi va giù e resta giù. Quindi metà del problema è sparita e la metà fastidiosa è ancora qui.
La metà del fallback a 1G mi suona molto familiare. Ho inseguito lo stesso sintomo su un TL-SG3428X e un TL-SX3008F: riavvia un server attaccato a una di quelle porte SFP+ e torna su negoziato a 1G, qualunque cosa fosse configurata sulla porta dello switch. Adattatori Intel X520-DA2, Mellanox e HP, ottiche Intel E10GSFPSR e 10GTek, aggiornamenti firmware, diverse versioni di driver su Linux e Windows, port profile - niente di tutto questo ha cambiato qualcosa. Un riavvio dello switch, o spostare la velocità della porta via da 10G e poi tornare indietro, ripristinava il link 10G fino al reset successivo dell'host.
Quello che davvero ha risolto è stato cambiare le ottiche invece di toccare l'host: moduli TP-Link SM5110-SR sul lato switch e il link tornava a 10G ogni volta. Qualcun altro ha confermato lo stesso su un SG3428XMPP. L'interpretazione era che lo switch negozia male con alcuni moduli di terze parti dopo un reset del link lato host.
Vendor diverso dal tuo lato, ma la forma corrisponde. Prima di comprarne un set intero, fatti prestare un singolo modulo a marchio Ubiquiti e prova una porta sull'aggregation switch.
Sul forzare 10G: farlo su un solo lato peggiora le cose, non le migliora. Il peer sta ancora provando a negoziare e un'impostazione fissa non gli dà niente contro cui negoziare, quindi il link semplicemente resta giù - esattamente il comportamento che descrivi. Fissa velocità e duplex su entrambi i lati, o su nessuno dei due.
Due casi simili dal mondo MikroTik, nel caso ti suonino familiari. Su un RB4011 un Finisar FTLF8524P2BNV-BR veniva rilevato con sfp-rx-loss e sfp-tx-fault entrambi a no, e l'interfaccia diceva comunque no-link, perché un SFP 1G in una cage SFP+ va fissato invece che negoziato:
e, di nuovo, su entrambi i lati. Il secondo caso era un CCR1072 dove l'auto-negotiation restava su DONE dopo una perdita di link e il driver non la riavviava mai; disabilitare l'autoneg e fissare la velocità ha riportato il link, al prezzo di una corretta rilevazione del link-down.