Skip to main content
Sign Out

Welcome to Dell

My Account
  • 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.
Sign In Create an Account Dell Financial Services Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

Article Number: 000181952

Cisco MDS-svitsj: Verter mister en bane til VPLEX Front End (FE)-porter på en soneaktivering

Summary: På en soneaktivering er alle HBA-er som er regulert mot en VPLEX-frontport, logget ut og mister en bane. ESX-verter kan henge og trenge omstart for å gjenopprettes. [Scott - does this only impact ESX hosts? The summary reads "All HBAs zoned to a VPLEX" do we want to limit this to only ESX hosts, or re-word to say "Hosts may hang and required a reboot to recover?] ...

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

Vert som mister baner.
[NOTE- Scott also see note in the summary]

ESX-verten henger og trenger en omstart for å gjenopprettes. [ Scott is it just ESX hosts that can become hung? The summary states "all HBAs zoned to VPLEX"]

From ESXi "vmkernel" log:

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

From the VPLEX firmware logs :
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 - back to the issue of "all HBAs zoned to VPLEX" if this cisco issue impacts all HBAs zoned to VPLEX should we be showing reports of other hosts departing in the fw logs? Do we see other hosts departing same as the esx host shown above?]

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: do we have this data for other HBAs seen to also have arrived ? ]


Change:
Zone activation.
HBA ports and VPLEX front end ports are not involved in the zoning changes.
[Scott - this last sentence does not make sense, the issue, as I understand it, is when there is a ZoneSet activation on a cisco switch all HBAs and VPLEX FE ports 'are' involved. also what Cisco Switch code level(s) does this impact?]

Cause

VPLEX utfører et fabric discovery på alle fiberkanalporter (front-end, back-end og FC-WANCOM) hvert 90. sekund og gjør dette ved å bruke kommandoen «Get all next» (Hent alle etterpå) (GA_NXT). Den utfører dette utenom å motta en RSCN fra svitsjen eller PLOGI fra en regulert HBA.

På grunn av Cisco-feil CSCvw75655, hvis VPLEX utfører fabric discovery på en frontend (FE)-port, mens en sonesettaktivering/-forpliktelse er i gang, er det en liten sjanse for at VPLEX bare får tilbake sin egen fiberkanaladresse (FCID ) og da vil anta at enhver HBA som er logget inn i den, ikke lenger er koblet til fabric og vil sende en utlogging (PLOGO) til hver HBA som er regulert mot den. [Scott - are the VPLEX and/or switch logs that show this action taking place, the PLOGO being sent, if this can be seen on both products can we include samples of this and from which logs this is seen?]

VPLEX vil logge fc/4-hendelsene for hver HBA som den logger ut og fc/3-hendelser på de neste 90 sekunders fabric discovery når den mottar riktig informasjon fra svitsjnavneserveren.

Hvordan HBA håndterer denne utloggingen, vil avhenge av driver/fastvare. ESX-verten i dette eksemplet hang og trengte omstart. [Scott - do we have data from the logs of other hosts being impacted by this event? if so can we also list some so it does not look like only ESX hosts are impacted?]

MERK:
Periodiske fabric discovery gjøres for å sikre at VPLEX har oppdatert fabric data, ettersom det er en mulighet for at ikke alle RSCN-ene når VPLEX fra fabric.

Resolution

Omgåelse av problemet:

Deaktiver navneserver-/soneserverdelt database (db) på Cisco-svitsjen som følger:
 

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


MERK: Zoneset shared-db-funksjonen er bare effektivt når navneserveren og soneserveren deler informasjon. Deaktivering av funksjonen skal ikke ha noen negativ innvirkning på miljøet.

Cisco har bekreftet at endringen er en lokal, ikke global endring. Denne kommandoen skal kjøres på hver svitsj som har VPLEX knyttet til seg. [Scott - is there a Cisco KB that talks to this issue that we can reference in this KBA?]

Løsning:

NX-OS 8.4(2c). Denne versjonen er ikke godkjent av Dell EMC.
[Scott - we cannot list a fix that is not yet available from Dell EMC, once available repost this KBA for review and remove the sentence "This version has not been GA by Dell EMC"]

Additional Information

Produkter (1)
Cisco MDS 9000 NX-OS og SAN-OS programvare

Kjente berørte versjoner
8.3(2)

VPLEX Fabric Discovery

Eksempel:
Vert 1, vert 2 og vert 3 regulert mot en enkelt VPLEX FE-port.

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

Working... [Scott - what is this? this taken/copied from info? If so we can remove the "working..." info]

 

  1. VPLEX sender en «Get all next» (Hent alle etterpå)-kommando til navneserveren med fiberkanaladresse (FCID) «0xffffff» (highest)
  2. Navneserveren svarer med detaljer for VPLEX FE-port (lowest)
  3. VPLEX sender en «Get all next» (Hent alle etterpå)-kommando til navneserveren med fiberkanaladresse (FCID) i VPLEX FE-porten
  4. Navneserveren svarer med detaljer for vert 1
  5. VPLEX sender en «Get all next» (Hent alle etterpå)-kommando til navneserveren med fiberkanaladresse (FCID) for vert 1
  6. Navneserveren svarer med detaljer for vert 2
  7. VPLEX sender en «Get all next» (Hent alle etterpå)-kommando til navneserveren med fiberkanaladresse (FCID) for vert 2
  8. Navneserveren svarer med detaljer for vert 3
  9. VPLEX sender en «Get all next» (Hent alle etterpå)-kommando til navneserveren med fiberkanaladresse (FCID) for vert 3
  10. Navneserveren svarer med detaljer for VPLEX FE-porten
  11. VPLEX stopper her, siden den har mottatt selve fiberkanaladressen (FCID) som allerede er oppdaget (krysset på nytt)

Cisco-feil CSCvw75655 ...

 

  1. VPLEX sender en «Get all next» (Hent alle etterpå)-kommando til navneserveren med fiberkanaladresse (FCID) «0xffffff» (høyest)
  2. Navneserveren svarer med detaljer for VPLEX FE-port (lowest)
  3. VPLEX sender en «Get all next» (Hent alle etterpå)-kommando til navneserveren med fiberkanaladresse (FCID) i VPLEX FE-porten
  4. Navneserveren svarer med detaljer for VPLEX FE-porten
  5. VPLEX stopper her, siden den har mottatt selve fiberkanaladressen (FCID) som allerede er oppdaget (krysset på nytt)

Flere detaljer om utbedringen av feilen CSCvw75655 som er lagt til NX-OS 8.4 (2c).
 
En påminnelse om hva som forårsaker denne feilen:
 
Problemet oppstår når en målenhet utsteder en FCNS GA_NXT-kommando og bare får sin egen FCID tilbake, noe som indikerer at den ikke er regulert mot andre enheter. Noen målenheter utsteder disse GA_NXT med jevne mellomrom; de drives ikke av RSCN eller annen stimulus og er dermed sårbare for dette problemet.
Årsaken er at når en sonesettaktivering/-forpliktelse pågår, er det et lite tidsvindu der FCNS bare vil returnere utstederens FCID i et GA_NXT-svar, og ingen av de andre som den er regulert mot. Dette er en konsekvens av den sonesettdelte databasefunksjonen som ble implementert i Cisco MDS NX-OS 7.3 (0) D1 (1). 
 
Dette er løsningsbeskrivelsen fra Cisco:

Som en del av aktiveringen utløses deaktivering, noe som tømmer SDB. Ved å tømme SDB sender den varsel til alle abonnenter. Dette blir nå ikke gjort. Også lagt til en ny sekvens som vil sende SDB-forpliktelsesvarselet separat. Dette vil regulere for å bygge opp SDB og sende en endelig varsling
Det finnes bare en løsning i versjon 8.4 (2c).
 
SDB = sonesettdelt 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

Back to Top