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: Værter mister en sti til VPLEX Front-End-porte (FE) ved en zoneaktivering

Summary: Ved en zoneaktivering logges alle HBA'er, der er i samme zone som en VPLEX front-end-port, ud og mister en sti. ESX-værter kan hænge og kræve en genstart for at blive gendannet. [Scott - berører dette kun ESX-værter? I resuméet står der "Alle HBA'er i samme zone som en VPLEX". Kan vi begrænse dette udelukkende til ESX-værter, eller omformulere og skrive "Værter kan hænge og kræve en genstart for at blive gendannet?] ...

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

Værter mister stier.
[BEMÆRK - Scott, se også bemærkning i resuméet]

ESX-vært hænger og kræver en genstart for at blive gendannet. [Scott, er det kun ESX-værter, der kommer til at hænge? I resuméet står der "Alle HBA'er i samme zone som VPLEX"]

Fra ESXi "vmkernel"-logfilen:

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


Fra VPLEX-firmwarelogfilerne:
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 - tilbage til problemet med "Alle HBA'er i samme zone som VPLEX". Hvis dette Cisco-problem berører alle HBA'er i en zone med VPLEX, bør vi så kunne fremlægge rapporter, der viser andre værter forsvinder i fw-logfilerne? Ser vi andre værter, der forsvinder på samme måde som ovennævnte esx-vært?]

Hændelse 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: Har vi set disse data for andre HBA'er? ]


Ændring:
Zoneaktivering.
HBA-porte og VPLEX front-end-porte er ikke omfattet af zoning-ændringerne.
[Scott - Denne sidste sætning giver ikke mening, problemet, som jeg forstår det, er, at når der sker en ZoneSet-aktivering på en Cisco-switch, berøres alle HBA'er og VPLEX FE-porte. Hvilke andre Cisco-switchkodeniveau(er) berører dette også?]

Cause

VPLEX udfører en strukturregistrering på alle Fibre Channel-porte (front-end, back-end og FC-WANCOM) hvert 90. sekund og gør dette ved at bruge navneserverkommandoen "Hent alle efterfølgende" (GA_NXT). Den udfører dette uden for modtagelsen af en RSCN fra switchen eller PLOGI fra en HBA, den er i en zone med.

På grund af Cisco-fejl CSCvw75655, er der, hvis VPLEX udfører sin strukturregistrering på en FE-port (front-end), mens en zoneset-aktivering/-bekræftelse er i gang, en lille risiko for, at VPLEX kun returneres sin egen Fibre Channel-adresse (FCID) og således antager, at en HBA, der er logget på den, ikke længere er forbundet til strukturen og sender en logout (PLOGO) til hver HBA, hvormed den er i en zone. [Scott - er de VPLEX- og/eller switchlogfiler, der viser denne igangværende handling, den PLOGO, der sendes. Hvis det kan ses på begge produkter, kan vi så medtage eksempler på dette, og fra hvilket logfiler det ses?]

VPLEX logger fc/4-hændelser for hver HBA, som den logger ud, og fc/3-hændelser, under den næste 90 sekunders strukturregistrering, når den modtager de korrekte oplysninger fra switchens navneserver.

Hvordan HBA håndterer logout, afhænger af dens driver/firmware. ESX-værten i dette eksempel hang fast og krævede en genstart. [Scott - har vi data fra logfilerne for andre værter, der er berørt af denne hændelse? Hvis det er tilfældet, kan vi så også vise nogle, så det ikke ser ud som om, at det kun er ESX-værter, der berøres?]

BEMÆRK:
Der udføres periodisk strukturregistrering for at sikre, at VPLEX har opdaterede strukturdata, da der er en mulighed for, at ikke alle RSCN'er når frem til VPLEX fra strukturen.

Resolution

Løsning:

På Cisco-switchen skal du deaktivere den navneserver-/zoneserverdelte databasefunktion (db) på følgende måde:
 

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


BEMÆRK: Den zoneset-delte db-funktionen er blot en effektivitet, hvor navneserver og zoneserver deler oplysninger. Deaktivering af funktionen har ingen negativ indvirkning på miljøet.

Cisco har bekræftet, at ændringen er en lokal ændring og ikke en global. Denne kommando skal køres på alle switche, der er tilsluttet VPLEX. [Scott - er der en Cisco KB, der omhandler dette problem, som vi kan referere til i denne KBA?]

Rettelse:

NX-OS 8.4 (2c). Denne version er ikke blevet GA af Dell EMC.
[Scott - vi kan ikke vise en rettelse, der endnu ikke er tilgængelig hos Dell EMC. Når den bliver tilgængelig, lægges indlægget vedrørende denne KBA ud igen til gennemsyn, og sætningen "Denne version er ikke blevet GA af Dell EMC"] fjernes

Additional Information

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

Kendte berørte udgivelser
8.3 (2)

VPLEX-strukturregistrering

Eksempel:
Vært 1, Vært 2 og Vært 3 udlagt til en enkelt VPLEX FE-port.

VPLEX FE-port: FCID 0x200b20
Vært 1: FCID 0x340000
Vært 2: FCID 0x340020
Vært 3: FCID 0x340040

Fungerer... [Scott - Hvad er det? Er det taget/kopieret fra oplysninger? Hvis det er tilfældet, kan vi fjerne oplysningen "Fungerer..."]

 

  1. VPLEX sender kommandoen "Hent alle herefter" til navneserveren med Fibre Channel-adressen (FCID) "0xffffff" (højest)
  2. Navneserveren svarer med oplysninger om VPLEX FE-port (lavest)
  3. VPLEX sender kommandoen "Hent alle herefter" til navneserveren med VPLEX FE-portens Fibre Channel-adresse (FCID)
  4. Navneserveren svarer med oplysninger om Vært 1
  5. VPLEX sender kommandoen "Hent alle herefter" til navneserveren med Vært 1's Fibre Channel-adresse (FCID
  6. Navneserveren svarer med oplysninger om Vært 2
  7. VPLEX sender kommandoen "Hent alle herefter" til navneserveren med Vært 2's Fibre Channel-adresse (FCID
  8. Navneserveren svarer med oplysninger om Vært 3
  9. VPLEX sender kommandoen "Hent alle herefter" til navneserveren med Vært 3's Fibre Channel-adresse (FCID
  10. Navneserveren svarer med oplysninger om VPLEX FE-port
  11. VPLEX stopper her, da den har modtaget sin egen Fibre Channel-adresse (FCID), som allerede er blevet registreret (genkrydset)

Cisco-fejl CSCvw75655 ...

 

  1. VPLEX sender kommandoen "Hent alle herefter" til navneserveren med Fibre Channel-adressen (FCID) "0xffffff" (højest)
  2. Navneserveren svarer med oplysninger om VPLEX FE-port (lavest)
  3. VPLEX sender kommandoen "Hent alle herefter" til navneserveren med VPLEX FE-portens Fibre Channel-adresse (FCID)
  4. Navneserveren svarer med oplysninger om VPLEX FE-port
  5. VPLEX stopper her, da den har modtaget sin egen Fibre Channel-adresse (FCID), som allerede er blevet registreret (genkrydset)

Yderligere oplysninger om rettelsen af fejlen CSCvw75655, som er blevet tilføjet NX-OS 8.4 (2c).
 
En påmindelse om, hvad der er årsag til denne fejl:
 
Problemet opstår, når en destinationsenhed udsteder en FCNS GA_NXT-kommando og kun får sin egen FCID tilbage, hvilket betyder, at den ikke er i en zone med andre enheder. Visse destinationsenheder udsteder disse GA_NXT periodisk. De er ikke baseret på RSCN eller anden stimulus og er derfor sårbare over for dette problem.
Årsagen er, at når en zoneset-aktivering/-bekræftelse er i gang, er der et lille tidsvindue, hvor FCNS kun returnerer udstederens FCID i et GA_NXT-svar og ingen af de andre, hvormed den er i en zone. Dette er en konsekvens af den zoneset-delte databasefunktion, som blev implementeret i Cisco MDS NX-OS 7.3 (0) D1 (1). 

 
Dette er beskrivelsen af rettelsen fra Cisco:

Som en del af aktiveringen, udløser deaktiveringen en rydning af SDB. Ved rydning af SDB udsender den en underretning til alle abonnenter. Dette gøres ikke nu. Desuden har vi tilføjet en ny sekvens, som sender SDB-bekræftelsesmeddelelsen separat. Det er rettet mod at skabe SDB og sende én endelig meddelelse
Rettelsen er kun foretaget i version 8.4 (2c).

 
SDB = Zoneset-delt 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