La ConnectX-4 MCX456A-ECAT non aggancia il link con un Cisco NCS su 100GBASE-LR4 anche se il loopback passa su entrambi i lati
Gestiamo una coppia di rack che si collegano a un Cisco NCS verso il carrier, e uno degli uplink server a 100G non è mai salito fin dalla messa in servizio. Stesso risultato dopo aver spostato il server in un altro armadio con un patch panel diverso, quindi ho smesso di trattarlo come un caso isolato.
- server Supermicro, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, entrambe le porte libere
- QSFP28 100GBASE-LR4 generici, single mode, portata 10 km, uno per lato
- Cisco NCS dall'altra parte, fibra scura tra le due sale
La parte che mi lascia bloccato: ogni modulo passa un loopback sul proprio apparato. Con la fibra chiusa ad anello diretto sullo stesso QSFP28 la NIC segnala un link 100G pulito, e l'NCS fa lo stesso dal suo lato. Metti in mezzo la tratta reale e non c'è niente.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noCosa abbiamo già provato:
- sostituiti entrambi i moduli con ricambi dello stesso lotto, nessun cambiamento
- spostato il server e ripatchato attraverso un panel diverso
- aperto un caso con il vendor della NIC, e la risposta è stata un rimando alla lista dei transceiver validati nelle note di rilascio del firmware, che non spiega perché il loopback funziona
C'è qualcosa nell'LR4 sulla ConnectX-4 che le permetterebbe di agganciare il link in locale ma mai su una tratta reale, o sto inseguendo il capo sbagliato di questa storia?
Comments 3
Sembra un percorso sporco, non un problema di compatibilità.
Tutto quello che hai sostituito finora sta dal lato che aveva già testato bene, ed è per questo che non è cambiato niente: la tratta stessa è l'unica cosa ancora non toccata. Quindi lavora sul percorso:
La lista dei transceiver validati che ti hanno indicato vale un'occhiata, ma un modulo che sale pulito in loopback è già pilotato correttamente dalla NIC. Le liste di compatibilità spiegano i moduli che vengono rifiutati apertamente, non i moduli che agganciano il link in locale e muoiono lungo una tratta.
Se la pulizia non basta, il prossimo passo è una sorgente luminosa e un power meter sulla fibra scura, o un OTDR se riesci a farti prestare uno, prima di comprare un'altra NIC o un'altra coppia di ottiche.
Un loopback dimostra solo che una porta riesce a sentire se stessa: laser, ricevitore, impostazioni di velocità. Non dice niente sul vetro tra le tue due sale, ed è l'unico pezzo che non hai ancora testato. Quindi prima di dare di nuovo la colpa alla NIC, prendi i numeri da entrambi i lati con la tratta reale collegata: quant'è la potenza Rx sulla porta dell'NCS, e quant'è sulla NIC? Un Rx sotto la soglia di Low Warn con la tratta collegata è l'indizio classico che punta al lato remoto o al percorso piuttosto che alla porta locale. Sul lato Linux
ethtool -mdovrebbe darti la stessa lettura, e se torna conCannot get module EEPROM information: Input/output errornon leggerlo come un modulo morto: su mlx5 di solito è l'accesso al modulo lato firmware, emst start,mst cable adde poimlxcablesti daranno comunque i valori.La pulizia è stata la soluzione. Abbiamo messo uno scope sulle facce terminali ed erano contaminati sia i moduli sia entrambe le bretelle; il cavo che passava per il permutatore tra le sale era il peggiore dei due. Pulito tutto lungo il percorso, reinserito, e il link 100G verso l'NCS è salito al primo tentativo ed è rimasto su da allora.
Un po' seccato con me stesso per aver perso tutto quel tempo sull'angolo della compatibilità quando il risultato del loopback mi stava dicendo fin dall'inizio che i moduli erano a posto e il percorso no. Per chi arriva qui più avanti: il loopback dimostra la porta, non la fibra.