Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Cisco MDS-Switch: Hosts verlieren einen Pfad zu VPLEX-FE-Ports (Front-End) bei einer Zonenaktivierung

Summary: Bei einer Zonenaktivierung werden alle HBAs, die in einer Zone mit einem VPLEX Front-End-Port sind, abgemeldet und verlieren einen Pfad. ESX-Hosts können sich aufhängen und es muss ein Neustart zur Wiederherstellung durchgeführt werden. [Scott: Betrifft dies nur ESX-Hosts? In der Zusammenfassung steht „alle HBAs in derselben Zone wie ein VPLEX“. Möchten Sie dies nur auf ESX-Hosts einschränken oder die Formulierung ändern: „Hosts können sich aufhängen und es muss ein Neustart zur Wiederherstellung durchgeführt werden.“] ...

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Symptoms

Host verliert Pfade.
[HINWEIS an Scott: Siehe auch Hinweis in der Zusammenfassung]

ESX-Host reagiert nicht mehr und es muss ein Neustart durchgeführt werden. [Scott, können sich nur ESX-Hosts aufhängen? Die Zusammenfassung gibt an: „alle HBAs auf VPLEX“]

Aus dem ESXi-Protokoll „vmkernel“:

2020-08-30T03:52:23.501Z cpu187:66638)WARNING: lpfc: lpfc_els_unsol_buffer:8330: 0:(0):0115 Unknown ELS command x7f26e705 received from NPORT x1f04c0
2020-08-30T03:52:28.325Z cpu187:66638)WARNING: lpfc: lpfc_els_unsol_buffer:8330: 0:(0):0115 Unknown ELS command x7effc405 received from NPORT x1f04c0


Aus dem VPLEX-Firmwareprotokoll:
event fc/4:  "This port has discovered the departure of the indicated port from the fabric."

128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36008:<6>2020/08/30 03:39:07.65: fc/4 A0-FC02.0: port 200000109b59a55d:100000109b59a55d:330fc0 
(spn Emulex PPN-10:00:00:10:9b:59:a5:5d) (snn Emulex LPe16002B-M6 FV12.2.299.27 DV12.2.373.1 HN:localhost OS:VMware ESXi 6.5.0) (speed <unsupported by fabric>) departed
128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36009:<4>2020/08/30 03:39:07.65: stdf/18 FCP connection lost. IT: [Host1_vmhba1 (0x100000109b59a55d) 
A0-FC02 (0xc00144879a780200)]
[Scott, zurück zu dem Problem mit „alle HBAs auf VPLEX“: Wenn dieses Cisco-Problem Auswirkungen auf alle HBAs auf VPLEX hat, sollten wir Berichte von anderen ausgefallenen Hosts in den FW-Protokollen zeigen? Ist es vorgekommen, dass andere Hosts ähnlich dem oben dargestellten ESX-Host ausfallen?]

event fc/3: "This port has discovered the arrival of the indicated port on the fabric."

128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36020:<6>2020/08/30 03:40:37.66: fc/3 A0-FC02.0: port 200000109b59a55d:100000109b59a55d:330fc0 
(spn Emulex PPN-10:00:00:10:9b:59:a5:5d) (snn Emulex LPe16002B-M6 FV12.2.299.27 DV12.2.373.1 HN:localhost OS:VMware ESXi 6.5.0) (speed <unsupported by fabric>) arrived
128.221.253.37/cpu0/log:5988:W/"006016abc83a153324-2":36027:<4>2020/08/30 04:03:28.34: stdf/17 FCP connection established.  IT: [Host1_vmhba1 (0x100000109b59a55d) 
A0-FC02 (0xc00144879a780200)]

[Scott: Sind diese Daten auch für andere HBAs angekommen? ]


Änderung:
Zonenaktivierung.
HBA-Ports und VPLEX-Front-End-Ports sind nicht an den Änderungen der Zone beteiligt.
[Scott: Dieser letzte Satz ergibt keinen Sinn, das Problem ist, so wie ich es verstanden habe, dass wenn eine Zoneset-Aktivierung auf einem Cisco-Switch vorhanden ist, alle HBAs und VPLEX FE-Ports betroffen sind. Außerdem: Welche Cisco-Switch-Code-Level sind betroffen?]

Cause

VPLEX führt eine Fabric-Ermittlung auf allen Fibre-Channel-Ports (Front-End-, Back-End-und FC-WANCOM) alle 90 Sekunden durch und verwendet dazu den Nameserver-Befehl „Get all next“ (GA_NXT). Dies erfolgt außerhalb des Empfangs eines RSCN vom Switch oder von PLOGI von einem HBA in der Zone.

Cisco-Fehler CSCvw75655 verursacht, dass VPLEX bei einer Fabric-Ermittlung auf einem Front-End-Port (FE), während ein/e Zoneset-Aktivierung/-Commit im Gange ist, eine geringe Chance hat, nur seine eigene Fibre-Channel-Adresse (FCID) zurück zu erhalten. Es geht dann davon aus, dass keine der angemeldeten HBA mehr mit dem Fabric verbunden sind, und sendet eine Abmeldung (PLOGO) an jeden HBA in seiner Zone. [Scott: Sind die VPLEX-und/oder Switch-Protokolle, die diese Aktion zeigen, dass eine PLOGO gesendet wird, wenn dies bei beiden Produkten der Fall ist, können wir Beispiele davon sehen und aus welchen Protokollen sie stammen?]

VPLEX protokolliert die fc/4-Events für jeden HBA, den es abmeldet, und fc/3-Events bei der nächsten 90-Sekunden-Fabric-Ermittlung, wenn die korrekten Informationen vom Switch-Nameserver empfangen werden.

Die Art und Weise, wie der HBA diese Abmeldung handhabt, hängt von der Treiber/Firmware ab. Der ESX-Host in diesem Beispiel hat sich aufgehängt und ein Neustart war erforderlich. [Scott: Haben wir Daten aus den Protokollen von anderen Hosts, die von diesem Ereignis betroffen sind? Wenn dies der Fall ist, können wir auch einige auflisten, sodass es nicht so aussieht, als wären nur ESX Hosts betroffen?]

Hinweis:
Die regelmäßige Fabric-Ermittlung wird durchgeführt, um sicherzustellen, dass VPLEX aktuelle Fabric-Daten hat, da eventuell nicht alle RSCNs VPLEX von der Fabric aus erreichen.

Resolution

Problemumgehung:

Deaktivieren Sie auf dem Cisco-Switch die Funktion Nameserver/„Zone Server Shared Database“ (DB) wie folgt:
 

switch# no zoneset capability active mode shared-db vsan <vsan-id>


HINWEIS: Die Funktion „zoneset shared-db“ dient nur der Effizienz, indem der Nameserver und die Zonenserver Informationen gemeinsam nutzen. Das Deaktivieren der Funktion hat keine negativen Auswirkungen auf die Umgebung.

Cisco hat bestätigt, dass die Änderung nur lokal, nicht global wirkt. Dieser Befehl sollte auf jedem Switch ausgeführt werden, der mit VPLEX verbunden ist. [Scott: Gibt es einen Cisco Wissensdatenbank-Artikel, in dem dieses Problem behandelt wird, auf den wir in diesem KBA verweisen können?]

Korrektur:

NX-OS 8.4(2c). Für diese Version besteht keine GA durch Dell EMC.
[Scott: Wir können keine Korrektur auflisten, die noch nicht von Dell EMC verfügbar ist. Sobald die Korrektur verfügbar ist, reichen Sie diese KBA nochmals zur Überprüfung ein und entfernen Sie den Satz „Für diese Version besteht keine GA durch Dell EMC.“

Additional Information

Produkte (1)
Cisco MDS 9000 NX-OS und SAN-OS-Software

Bekannte betroffene Versionen
8.3(2)

VPLEX-Fabric-Ermittlung

Beispiel:
Host 1, Host 2 und Host 3 in Zonen auf einem einzigen VPLEX-FE-Port.

VPLEX-FE-Port: FCID 0x200b20
Host 1: FCID 0x340000
Host 2: FCID 0x340020 
Host 3: FCID 0x340040 

Working... [Scott: Was ist das? Wurde das aus Info entnommen/kopiert? Wenn dies der Fall ist, können wir die Info „Working...“ entfernen]

 

  1. VPLEX sendet den Befehl „Get all next“ an den Nameserver mit der Fibre-Channel-Adresse (FCID) „0xffffff“ (der höchsten)
  2. Nameserver antwortet mit Details für VPLEX-FE-Port (den niedrigsten)
  3. VPLEX sendet den Befehl „Get all next“ an den Nameserver mit der Fibre-Channel-Adresse (FCID) des VPLEX-FE-Ports
  4. Nameserver antwortet mit Details für Host 1.
  5. VPLEX sendet den Befehl „Get all next“ an den Nameserver mit der Fibre-Channel-Adresse (FCID) von Host 1.
  6. Nameserver antwortet mit Details für Host 2.
  7. VPLEX sendet den Befehl „Get all next“ an den Nameserver mit der Fibre-Channel-Adresse (FCID) von Host 2.
  8. Nameserver antwortet mit Details für Host 3.
  9. VPLEX sendet den Befehl „Get all next“ an den Nameserver mit der Fibre-Channel-Adresse (FCID) von Host 3.
  10. Nameserver antwortet mit Details für VPLEX-FE-Port.
  11. VPLEX wird hier gestoppt, da es die Fibre Channel-Adresse (FCID) von sich selbst empfängt, die bereits ermittelt (erneut überschritten) wurde.

Cisco-Bug CSCvw75655 ...

 

  1. VPLEX sendet den Befehl „Get all next“ an den Nameserver mit der Fibre-Channel-Adresse (FCID) „0xffffff“ (der höchsten)
  2. Nameserver antwortet mit Details für VPLEX-FE-Port (den niedrigsten)
  3. VPLEX sendet den Befehl „Get all next“ an den Nameserver mit der Fibre-Channel-Adresse (FCID) des VPLEX-FE-Ports
  4. Nameserver antwortet mit Details für VPLEX-FE-Port.
  5. VPLEX wird hier gestoppt, da es die Fibre Channel-Adresse (FCID) von sich selbst empfängt, die bereits ermittelt (erneut überschritten) wurde.

Weitere Informationen zur Korrektur für Fehler CSCvw75655wurden NX-OS 8.4 (2C) hinzugefügt.
 
Zur Wiederholung, wie dieser Fehler verursacht wird:
 
Das Problem tritt auf, wenn ein Zielgerät einen „FCNS GA_NXT“-Befehl ausgibt und nur seine eigene FCID zurück erhält, was darauf hinweist, dass es nicht mit anderen Geräten in einer Zone ist. Einige Zielgeräte lösen diese GA_NXT periodisch aus. Sie werden nicht von RSCN oder anderen Auslösern gesteuert und sind daher anfällig für dieses Problem.
Der Grund dafür ist, dass, wenn ein/e Zoneset-Aktivierung/-Commit durchgeführt wird, ein kleines Zeitfenster vorhanden ist, in dem FCNS in einer GA_NXT-Antwort nur die FCID des Herausgebers und keine der anderen Nutzer in der Zone zurückgibt. Dies ist eine Konsequenz der Funktion „Zoneset Shared Database“, die in Cisco MDS NX-OS 7.3(0)D1(1) implementiert wurde. 

 
Dies ist die Korrekturbeschreibung von Cisco:

Im Rahmen der Aktivierung wird die Deaktivierung ausgelöst, die die SDB löscht. Beim Löschen des SDB sendet sie Benachrichtigungen an alle Abonnenten. Dies geschieht jetzt nicht. Außerdem wurde eine neue Sequenz hinzugefügt, die die SDB-Commit-Benachrichtigung separat sendet. In dieser Zone können Sie die SDB erstellen und eine abschließende Benachrichtigung senden.
Es gibt nur eine Korrektur in Version 8.4(2C).

 
SDB = Zoneset Shared Database.

Article Properties


Affected Product

VPLEX, Connectrix MDS-Series Firmware 7.X, Connectrix MDS-Series Firmware 8.X, VMware ESXi 6.5.X

Product

Connectrix, Connectrix MDS-Series, Connectrix MDS-Series Firmware, VMware ESXi, VPLEX GeoSynchrony, VPLEX Series, VPLEX VS6

Last Published Date

19 Aug 2021

Version

4

Article Type

Solution