Catalyst 3850 setzt den Port auf err-disable, wenn ein ThinkSystem SR650 Lenovo 46C3447 SR-Optiken verwendet
Neuer ESXi-Host für ein Rack, das an einem 3850 im Campus hängt. Das Management über Kupfer kam problemlos hoch, die 10G-Uplinks nicht: Sobald der Server bootet, fällt der Switch-Port in err-disable, und der Host sieht auf diesem vmnic gar nichts.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, mit einem Emulex VFA5.2 2x10GbE SFP+ Adapter
- Lenovo 10GBASE-SR Module, 46C3447, im Adapter
- Cisco WS-C3850-24XS-S mit Cisco SFP-10G-SR auf der Switch-Seite
- OM3-LC-LC-Patchkabel dazwischen
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 stableBereits versucht:
- Server auf einen anderen Port am selben Switch umgesteckt, gleiches Verhalten
- 46C3447 gegen sein Pendant vom anderen Adapter-Port getauscht
- neues Patchkabel, beide Enden gereinigt und neu gesteckt
Die Faser und die Optik auf der Switch-Seite sind offensichtlich in Ordnung, also wehrt sich etwas gegen das Lenovo-Modul. Welche Seite sperrt sich hier, der Server oder der Switch, und gibt es einen Weg, den 3850 damit leben zu lassen?
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
Das Log klärt es.
gbic-invalidheißt, der Switch verweigert, was er als nicht autorisiertes Modul erkennt, und die Prüfung, die dabei auslöst, sitzt auf der Cisco-Seite, nicht im SR650 und nicht in ESXi. Er wehrt sich gegen die Lenovo-codierte SR-Optik in diesem Link und legt den Port lahm, bevor der Link überhaupt bewertet wird - deshalb hat auch das Umstecken der Ports und der Kabeltausch nichts gebracht.Zwei Zeilen in der globalen Konfiguration:
Die erste sagt dem Switch, er soll mit einem Modul weitermachen, das er nicht kennt, die zweite verhindert, dass err-disable den Port abschießt, wenn diese CRC-Prüfung anschlägt. Keins von beiden wirkt rückwirkend, also danach den Port einmal toggeln und die Faser währenddessen neu einstecken:
Konfiguration sichern, sobald der Port oben ist. Bleibt sie nur in der running config, kommt der Port nach dem nächsten Reload wieder err-disabled zurück, und das Debugging beginnt von vorn, zu einem deutlich unpassenderen Zeitpunkt.
Zwei Vorbehalte. Damit ist man außerhalb der von Cisco unterstützten Konfiguration: Drittanbieter-Optiken gelten dort als ungetestet, und der TAC kann einen Interoperabilitätsfall mit so einem Modul ablehnen, was relevant ist, wenn dieser Link unter einem Vertrag läuft. Und
service unsupported-transceiverist kein Allheilmittel. Dieselbe bad-crc-Meldung überlebt den Befehl, wenn der Port selbst das Hindernis ist, etwa ein reiner 1G-SFP-Slot mit einem hineingedrückten 10G-Modul - bleibt der Port nach dem Toggeln also unten, erst die tatsächliche Geschwindigkeit an beiden Enden prüfen, bevor wieder die Optik verdächtigt wird.Bevor hier jemand rät: Was loggt der Switch tatsächlich, wenn der Port fällt? Err-disable nennt immer seine Ursache, und die Ursache ändert die Antwort komplett. Eine Security- oder CRC-Beschwerde über ein Modul ist ein anderes Problem als ein Flap oder ein Protokollfehler, und die Abhilfe für das eine bringt beim anderen gar nichts.
show loggingab dem Moment holen, in dem der Server hochfährt, und die Zeilen zu diesem Port posten. Auch klären, was physisch in Te1/0/7 steckt, du sagst Cisco SFP-10G-SR, ist das 46C3447 also das einzige Nicht-Cisco-Teil auf dieser ganzen Strecke?Log ab dem Moment, in dem er fällt, zwei Zeilen zu diesem Port:
Es ist also die Security-Prüfung, die auslöst, kein Flap. Und ja, das Switch-Ende ist ein echtes Cisco SFP-10G-SR aus einer Cisco-Box, das 46C3447 im Server ist das einzige Lenovo-codierte Teil auf der Strecke. Was mich eben verwirrt hat, weil die Meldung den Port auf dem Switch nennt und nichts auf der Serverseite.