HINWEIS:

DIESE FELDBENACHRICHTIGUNG WIRD "WIE BESEHEN" BEREITGESTELLT UND IMPLIZIERT KEINE GEWÄHRLEISTUNG ODER GEWÄHRLEISTUNG, EINSCHLIESSLICH DER GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT. IHRE VERWENDUNG DER INFORMATIONEN IN DER FELDBENACHRICHTIGUNG ODER DEN IN DER FELDBENACHRICHTIGUNG VERKNÜPFTEN MATERIALIEN STEHT AUF EIGENES RISIKO. CISCO BEHÄLT SICH DAS RECHT VOR, DIESE FELDBENACHRICHTIGUNG JEDERZEIT ZU ÄNDERN ODER ZU AKTUALISIEREN.

Revisionsverlauf

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

Betroffene Produkte

UCSB-MLOM-40G-01

UCS-VIC-M82-8P

UCSB-MLOM-40G-03

UCSC-PCIE-C10T-02

UCSC-PCIE-CSC-02

Problembeschreibung

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.

Hintergrund

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:

- Der IOM wird zurückgesetzt.

- Das IOM ist wieder eingesetzt.

- Das Kabel zwischen IOM und FI wird gezogen/ausgetauscht.

- Das Unified Computing System (UCS) wird aktualisiert, und Infrastrukturkomponenten (A-Paket) werden vor Adaptern (B/C-Paket) abgeschlossen.

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.

Problemsymptome

Schritte zur Identifizierung der Cisco Bug-ID CSCuh61202

1. 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 <--

2. Stellen Sie fest, ob die Anzahl der abgebrochenen Protokolle in den Adapterprotokollen seit dem letzten "Betrieb der PFC-Funktion" zunimmt.

Hinweise:

- Es gibt viele Gründe für Abtreibungen in den Protokollen. Stellen Sie sicher, dass Sie die Überlegungen zu Treibern und Speicher-Fabric berücksichtigen, bevor Sie davon ausgehen, dass die Abbrüche auf einen dieser PFC-Fehler zurückzuführen sind.

- Abgänge werden nicht unbedingt unmittelbar nach dem Server angezeigt. Dies hängt von der Last und anderen Faktoren ab, die die Speichergewohnheiten des Servers sowie die Storage-Fabric betreffen.

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

3. Ü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

1. 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

2. Stellen Sie fest, ob die Anzahl der abgebrochenen Protokolle in den Adapterprotokollen seit dem letzten "Betrieb der PFC-Funktion" zunimmt.

Hinweise:

- Es gibt viele Gründe für Abtreibungen in den Protokollen. Stellen Sie sicher, dass Sie die Überlegungen zu Treibern und Speicher-Fabric berücksichtigen, bevor Sie davon ausgehen, dass die Abbrüche auf einen dieser PFC-Fehler zurückzuführen sind.

- Abgänge werden nicht unbedingt unmittelbar nach dem Server angezeigt. Dies hängt von der Last und anderen Faktoren ab, die die Speichergewohnheiten des Servers sowie die Storage-Fabric betreffen.

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

3. Ü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

Anweisungen für Adapterprotokolle

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.

Problemumgehung/Lösung

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.

Vermeidung weiterer Probleme

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.

CDET

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.

Weitere Informationen

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):

- Serviceanfrage auf Cisco.com erstellen

- Per E-Mail

- Per Telefon

E-Mail-Benachrichtigung für neue Problemhinweise erhalten

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.