Il Catalyst 3850 mette la porta in err-disable quando un ThinkSystem SR650 usa ottiche Lenovo SR 46C3447
Nuovo host ESXi che va in un rack collegato a un 3850 di campus. La gestione su rame è salita senza drammi, gli uplink 10G no: appena il server si avvia, la porta dello switch va in err-disable e l'host non vede nulla su quel vmnic.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, con adattatore Emulex VFA5.2 2x10GbE SFP+
- moduli Lenovo 10GBASE-SR, 46C3447, nell'adattatore
- Cisco WS-C3850-24XS-S con Cisco SFP-10G-SR lato switch
- bretella OM3 LC-LC tra i due
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableGià provato:
- spostato il server su un'altra porta dello stesso switch, stesso comportamento
- scambiato il 46C3447 con il suo gemello dell'altra porta dell'adattatore
- bretella nuova, entrambi i capi puliti e reinseriti
La fibra e l'ottica lato switch sono chiaramente a posto, quindi qualcosa sta rifiutando il modulo Lenovo. Chi obietta qui, il server o lo switch, e c'è un modo per far digerire il modulo al 3850?
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
Quel log chiarisce tutto.
gbic-invalidè lo switch che rifiuta quello che legge come un modulo non autorizzato, e il controllo che scatta vive lato Cisco, non sullo SR650 e non in ESXi. Obietta all'ottica SR con codifica Lenovo su quel link e uccide la porta prima ancora che il link venga valutato, ed è anche per questo che spostare porte e cambiare bretelle non ha cambiato nulla.Due righe in configurazione globale:
La prima dice allo switch di andare avanti anche con un modulo che non riconosce, la seconda impedisce a err-disable di abbattere la porta quando quel controllo CRC fallisce. Nessuna delle due è retroattiva, quindi rilancia la porta dopo e reinserisci la fibra mentre è giù:
Salva la configurazione una volta che è su. Se resta solo nella running config, la porta torna in err-disable al prossimo reload e ti tocca ridebuggare tutto nel momento peggiore possibile.
Due avvertenze. Sei ora fuori dalla configurazione supportata Cisco: considerano le ottiche di terze parti non testate e il TAC può rifiutare un caso di interoperabilità che ne coinvolge una, il che conta se questo link è sotto contratto. E
service unsupported-transceivernon è una soluzione universale. Lo stesso messaggio bad crc sopravvive quando è la porta stessa l'ostacolo, per esempio uno slot SFP solo 1G con dentro un modulo 10G, quindi se la porta resta giù dopo il rilancio, controlla a che velocità gira davvero ciascun capo prima di dare di nuovo la colpa all'ottica.Prima che qualcuno tiri a indovinare: cosa logga davvero lo switch quando la porta va giù? Err-disable indica sempre la causa, e la causa cambia completamente la risposta. Una segnalazione di sicurezza o CRC su un modulo è un problema diverso da un flap o da un protocollo che inciampa, e il rimedio per uno non serve a nulla per l'altro.
Tira fuori
show loggingdal momento in cui il server si accende e posta le righe per quella porta. Conferma anche cosa c'è fisicamente in Te1/0/7: dici Cisco SFP-10G-SR, quindi il 46C3447 è l'unico pezzo non Cisco in tutto quel percorso?Log dal momento in cui cade, due righe per quella porta:
Quindi è il controllo di sicurezza che scatta, non un flap. E sì, il lato switch è un vero Cisco SFP-10G-SR uscito da una scatola Cisco, il 46C3447 nel server è l'unico pezzo con codifica Lenovo nel percorso. Il che è quello che mi ha confuso, perché il messaggio nomina la porta sullo switch e non qualcosa lato server.