Revision | Datum | Kommentar |
---|---|---|
1.2
|
18. MAI 2016
|
Betroffene Produkte, Problembeschreibung, Hintergrund, Problemsymptome und Problemumgehung/Lösungsabschnitte aktualisiert. Abschnitt CDETS hinzugefügt.
|
1.1
|
15. Dezember 2014
|
Aktualisierte Problembeschreibung
|
1.0
|
21. AUG. 2014
|
Erste Veröffentlichung
|
Betroffene Produkte |
---|
UCSB-MLOM-40G-01
|
UCS-VIC-M82-8P
|
UCSB-MLOM-40G-03
|
UCSC-PCIE-C10T-02
|
UCSC-PCIE-CSC-02
|
Wenn das Ein-/Ausgabemodul (IOM) aktualisiert/zurückgesetzt/entfernt/wieder eingesetzt oder das Kabel zwischen dem IOM und dem Fabric Interconnect (FI) gezogen/ersetzt wird, wird der Fibre Channel (FC)-Speicherdatenverkehr von der Cisco Virtual Interface Card (VIC) 1225/1227/1240/1280/134 geleitet Bei 0/1380 bis hin zum IOM können Probleme auftreten (fallen), nachdem die Verbindung wiederhergestellt wurde.
Es gibt keine visuellen Anzeichen in Unified Computing System Manager (UCSM), dass die in diesem Dokument erwähnten Fehler aufgetreten sind. Obwohl die virtuellen Netzwerkschnittstellenkarten/virtuellen Host-Bus-Adapter im UCSM als grün angezeigt werden, sind die zugrunde liegenden Speicherpfade bei Auswirkungen möglicherweise weiterhin nicht verfügbar.
Wenn der Ausgangs-FC-Port überlastet ist, sendet der Switch PFC-Frames (Priority-Based Flow Control) an die Server, um die FCoE-Rate (Fibre Channel over Ethernet) zu reduzieren und Paketverluste durch definierte CoS-Priorität zu vermeiden. Data Center Bridging (DCB) PFC erweitert den Standard-PAUSE-Frame um IEEE 802.1p-CoS-Werte. Bei PFC wird der Datenverkehr nicht unterbrochen, wenn ein PAUSE-Frame gesendet wird, sondern nur für die CoS-Werte, die im PFC-Frame aktiviert sind. Ein PFC-Frame wird für die aktivierte Priorität gesendet, für die der Datenverkehr angehalten werden muss.
Dieses Problem kann unter verschiedenen Bedingungen auftreten:
In der Cisco Bug-ID CSCuh61202 sendet der Switch/IOM Pause Registers (Priority Groups (PGS) und PFC-Updates) an den Adapter, insbesondere ein PGS-Update gefolgt von einem PFC-Update. Aufgrund eines Problems mit der VIC-Firmware wird die Pausenkonfiguration beim PFC-Update nicht korrekt programmiert. Dies führt dazu, dass der Adapter die Pause für die FCoE-CoS nicht einhält. Dies führt dazu, dass FCoE-Frames im IOM verworfen werden.
Die Cisco Bug-ID CSCus64439 wird durch eine Reihe von Ereignissen auf dem VIC-Adapter ausgelöst, bei denen die PFC möglicherweise nicht korrekt neu konfiguriert wird, nachdem ein PFC-inoperativer Frame gefolgt von einem PFC-Operational-Frame empfangen wurde. Dies führt dazu, dass der Adapter die Pause für die FCoE-CoS nicht einhält. Dies führt dazu, dass FCoE-Frames im IOM verworfen werden.
Da dieses Verhalten eine Rassenbedingung ist, kann es auf einigen Servern auftreten, aber nicht auf anderen. In der Regel kann dies in einem gesamten Chassis auftreten. Wenn jedoch mehrere Chassis im System vorhanden sind, kann das Chassis mit der richtigen Pausenkonfiguration weiterhin betroffen sein, da der Datenverkehr in das Netzwerk fließt.
Schritte zur Identifizierung der Cisco Bug-ID CSCuh61202
Suchen Sie im Adapter-Syslog nach "feature Operational" (Funktion aktiv).
Im folgenden Beispiel wird der Adapter-Syslog nicht betroffen:
140416-07:30:41.096482 mcp.uif_dcbx Port 1-0: FCOE feature operational
140416-07:30:41.096588 mcp.uif_dcbx Port 1-0: MTU feature operational
140416-07:30:41.096774 mcp.uif_dcbx Port 1-0: NIV feature operational
140416-07:30:41.096910 mcp.uif_dcbx Port 1-0: PFC feature operational <--
140416-07:30:41.097054 mcp.uif_dcbx Port 1-0: PGS feature operational <--
Das folgende Beispiel zeigt ein betroffenes Beispiel aus dem Adapter-Syslog:
140416-04:46:00.769934 mcp.uif_dcbx Port 1-0: NIV feature operational
140416-04:46:06.645865 mcp.uif_dcbx Port 1-0: PGS feature operational <--
140416-04:46:06.848516 mcp.uif_dcbx Port 1-0: MTU feature operational
140416-04:46:08.782584 mcp.uif_dcbx Port 1-0: FCOE feature operational
140416-04:46:10.788342 mcp.uif_dcbx Port 1-0: PFC feature operational <--
Stellen Sie fest, ob die Anzahl der abgebrochenen Protokolle in den Adapterprotokollen seit dem letzten "Betrieb der PFC-Funktion" zunimmt.
Hinweise:
Beispiel für Abbruchmeldung im Adapterprotokoll:
140416-08:13:12.809365 ecom.ecom_main ecom(8:1): Abort aufgerufen für exch 4d56, status 3 rx_id b38 s_stat 0x1 xmit_recvd 0x200 burst_offset 0x200 sgl_err 0x0 last_param 0x0 last_seq_cnt 0x0 tot_bytes_exp 0x200 h_seq_cnt 0x0 exch_type 0x1 s_id 0x3d0200 d_id 0x3d03a0 host_tag 0x78
Überprüfen Sie die recv-Puffer an den HIF-Ports des IOM, um festzustellen, ob sie überlaufen sind (ein Hinweis darauf, dass Frames nicht funktionieren).
Suchen Sie im IOM show-tech-support-iom-nxos.out nach "frames rcvd without Credit for pausable class" (Frames rcvd ohne Gutschrift für pausable class):
: |3 |000001ad | wo_cr[3] | Frames rcvd ohne Gutschrift für anhaltenden Klassen. Pause fehlt. < — inkrementierender Wert ungleich null
Schritte zur Identifizierung der Cisco Bug-ID CSCus64439
Stellen Sie fest, wann das PFC-Feature-Paket zum letzten Mal inaktiv war und welche weiteren PGS- und PFC-Funktionspakete sich in den Adaptersyslogs befinden.
150209-16:12:35.817073 mcp.uif_dcbx Port 0-0: PFC-Funktion betriebsbereit
150209-17:31:11.454181 mcp.uif_dcbx Port 0-0: PFC-Funktion inaktiv <—
150209-17:31:20.512303 mcp.uif_dcbx Port 0-0: Funktion für PGS
150209-17:31:24.482730 mcp.uif_dcbx Port 0-0: PFC-Funktion betriebsbereit
Stellen Sie fest, ob die Anzahl der abgebrochenen Protokolle in den Adapterprotokollen seit dem letzten "Betrieb der PFC-Funktion" zunimmt.
Hinweise:
Beispiel für Abbruchmeldung im Adapterprotokoll:
140416-08:13:12.809365 ecom.ecom_main ecom(8:1): Abort aufgerufen für exch 4d56, status 3 rx_id b38 s_stat 0x1 xmit_recvd 0x200 burst_offset 0x200 sgl_err 0x0 last_param 0x0 last_seq_cnt 0x0 tot_bytes_exp 0x200 h_seq_cnt 0x0 exch_type 0x1 s_id 0x3d0200 d_id 0x3d03a0 host_tag 0x78
Überprüfen Sie die recv-Puffer an den HIF-Ports des IOM, um festzustellen, ob sie überlaufen sind (ein Hinweis darauf, dass Frames nicht funktionieren).
Suchen Sie im IOM show-tech-support-iom-nxos.out nach "frames rcvd without Credit for pausable class" (Frames rcvd ohne Gutschrift für pausable class):
: |3 |000001ad | wo_cr[3] | Frames rcvd ohne Gutschrift für anhaltenden Klassen. Pause fehlt. < — inkrementierender Wert ungleich null
Erfassen der Protokollinformationen von der CLI
Wenn Sie nach Adapterprotokollen suchen möchten, die mit Chassis 2, Server 3, Adapter 1 verknüpft sind, finden Sie hier die Syntax der CLI eines Live-Systems:
ucs-B# connect adapter 2/3/1
adapter 2/3/1 # connect
No entry for terminal type "dumb";
using dumb terminal settings.
adapter 2/3/1 (top):1# show-log
Hinweis: Es ist nicht möglich, grep oder | in dieser Shell einschließen.
Erfassen der Protokollinformationen aus dem UCSM
Sammeln Sie einen technischen Chassis-Support für das vermutete Chassis:
Entpacken Sie die Datei für den technischen Support des Cisco Integrated Management Controller (CIMC), und navigieren Sie zum technischen Support-Ordner MEZZ des betroffenen Adapters. In diesem Beispiel werden die Adapterprotokolle für Server 3 angezeigt. Entpacken Sie die Datei MEZZ31_TechSupport.tar.gz:
Erweitern Sie den Ordner MEZZ tech-support, und entfernen Sie die Datei obfl.tar.gz:
Navigieren Sie zum obfl-Ordner, und öffnen Sie die Syslog/syslog.1-Dateien mit einem Text-Editor.
Je nach Situation können Kunden eine vorübergehende/sofortige Lösung oder die bevorzugte Lösung wählen.
Sofortige Problemumgehung: Starten Sie den Blade neu, der den Datenverkehr zum IOM überflutet. Dies führt dazu, dass die Pausenkonfiguration neu programmiert wird.
Bevorzugte Problemumgehung: Diese Methode dient der langfristigen Vermeidung dieses Problems. Wenn ein Upgrade durchgeführt werden soll; Planen Sie das Upgrade so, dass die Adapter-Firmware (B/C-Paket) vor den Infrastrukturkomponenten (A-Paket) aktualisiert wird. Es wird empfohlen, alle Systemkomponenten vom Blade zum FI im gleichen Wartungsfenster zu aktualisieren, damit das System nicht in unterschiedlichen Versionen eingesetzt wird.
Wenn Sie ein Upgrade von einer 2.2x- auf eine 3.1x-Version planen, aktualisieren Sie zuerst das B/C-Paket auf 2.2(6g), dann auf das 2.2(6g) A-Paket. Danach können Sie in der normalen Reihenfolge auf 3.1x aufrüsten.
Wenn Sie ein Upgrade von einer 2.1x- auf eine 2.2x/3.1x-Version planen, aktualisieren Sie zuerst das B/C-Paket auf 2.1(3k), und dann auf das 2.1(3k) A-Paket. Anschließend können Sie in der normalen Reihenfolge auf 2.2.x/3.1x aktualisieren.
Version 3.1(1e) oder 2.2(6g) sowie deren Folgeversionen, die eine Behebung aller in dieser Ankündigung genannten Fehler enthalten, finden Sie unter Cisco Software Download Release 2.2 und höher.
Weitere Informationen finden Sie unter Upgrade des Cisco UCS von Version 2.1 auf Version 2.2.
Um dieses Problem zu vermeiden, muss die Firmware des Cisco 1225/1227/1240/1280/1340/1380-Adapters aktualisiert werden, bevor die UCS-Infrastrukturkomponenten (UCSM/IOM/FI) aktualisiert werden können. Dieses Verfahren verstößt gegen die Richtlinien des Cisco UCS-Upgrade-Leitfadens, aber um dieses Problem zu vermeiden, wird empfohlen.
Um dem unten angezeigten Link zu Bug ID zu folgen und detaillierte Fehlerinformationen zu erhalten, müssen Sie ein registrierter Kunde sein und angemeldet sein.
CDET | Beschreibung |
---|---|
CSCuh61202 (nur registrierte Kunden) | VIC: FC-Datenverkehr sinkt nach IOM-Zurücksetzen/Wiedereinsetzen/Kabelziehen oder Upgrade |
CSCus64439 (nur registrierte Kunden) | "PFC-Funktion betriebsbereit" wird nicht aktualisiert verursacht Speicherlatenz und wird abgebrochen. |
Wenn Sie weitere Unterstützung benötigen oder weitere Fragen zu dieser Bekanntmachung haben, wenden Sie sich über eine der folgenden Methoden an das Cisco Systems Technical Assistance Center (TAC):
Cisco Notification Service - Richten Sie ein Profil ein, um E-Mail-Aktualisierungen zu Zuverlässigkeit, Sicherheit, Netzwerksicherheit und End-of-Sale-Problemen für die von Ihnen angegebenen Cisco Produkte zu erhalten.