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

Cisco MDS-switch: Värdar förlorar en sökväg till VPLEX-klientdelsportar (FE) vid en zonaktivering

Summary: Vid en zonaktivering blir alla HBA som är zonanslutna till en VPLEX-klientdelsport utloggade och sökvägen går förlorad. ESX-värdar kan hänga sig och kräva en omstart för att återställas. [Scott – påverkar det här bara ESX-värdar? Sammanfattningen säger ”alla HBA som är zonanslutna till en VPLEX”; vill vi begränsa det här till endast ESX-värdar eller omformulera till ”Värdarna kan hänga sig och kräva en omstart för att återställas?” ...

This article applies to   This article does not apply to 

Symptoms

Värden förlorar sökvägar.
[Obs! Scott ser även noteringen i sammanfattningen]

ESX-värden hänger sig och kräver en omstart för att återställas. [Scott – är det bara ESX-värdar som kan hänga sig? Sammanfattningen uppger ”alla HBA-enheter som är zonanslutna till VPLEX”]

Från ESXi ”vmkernel”-loggen:

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


Från loggarna för fast programvara i VPLEX:
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 – tillbaka till problemet med ”alla HBA som är zonanslutna till VPLEX”; om det här Cisco-problemet påverkar alla HBA som är zonanslutna till VPLEX, bör vi visa rapporter för andra värdar som avviker i fw-loggarna? Ser vi andra värdar som avviker på samma sätt som ESX-värden ovan?]

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: Har vi dessa data för andra HBA som också har kommit fram ? ]


Ändring:
Zonaktivering.
HBA-portar och VPLEX-klientdelsportar är inte involverade i zonändringarna.
[Scott – den här sista meningen är inte begriplig; problemet är, som jag förstått det, att när det sker en aktivering av zonuppsättning på en Cisco-switch är alla HBA och VPLEX FE-portar involverade. Och vilka Cisco Switch-kodnivåer påverkas av detta?]

Cause

VPLEX utför en strukturidentifiering på alla fiberkanalportar (klientdel, serverdel och FC-WANCOM) var 90:e sekund med hjälp av namnserverkommandot ”Hämta alla följande” (GA_NXT). Den utför detta utanför mottagningen av en RSCN från switchen eller PLOGI från en zonansluten HBA.

Cisco-fel CSCvw75655 gör att om VPLEX utför strukturidentifieringen på en klientdelsport (FE) medan aktivering/bekräftelse av en zonuppsättning pågår, finns det en liten risk att VPLEX endast får tillbaka sin egen fiberkanaladress (FCID). Den antar då att alla HBA som är inloggade på den inte längre är anslutna till strukturen och skickar ett utloggningskommando (PLOGO) till varje HBA som är zonansluten till den. [Scott – skapas VPLEX- och/eller switch-loggarna som visar denna åtgärd, att PLOGO skickas, och om detta ses på båda produkterna, kan vi inkludera exempel på det och i vilka loggar framgår detta?]

VPLEX loggar fc/4-händelserna för varje HBA som den loggar ut och fc/3-händelser vid nästa 90-sekunders strukturidentifiering när den tar emot korrekt information från switchens namnserver.

Hur HBA hanterar den här utloggningen beror på dess drivrutin/fasta programvara. ESX-värden i det här exemplet hängde sig och krävde en omstart. [Scott – har vi data från loggarna för andra värdar som påverkas av den här händelsen? Om så är fallet, kan vi lista några så att det inte ser ut som om bara ESX-värdar påverkas?]

Obs!
Periodisk strukturidentifiering görs för att säkerställa att VPLEX har uppdaterade strukturdata eftersom det är möjligt att inte alla RSCN når VPLEX från strukturen.

Resolution

Alternativ lösning:

Inaktivera funktionen delad databas (db) för namnserver/zonserver på Cisco-switchen enligt följande:
 

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


Obs! Funktionen zoneset shared-db är bara en effektivitet där namnservern och zonservern delar information. Att inaktivera funktionen har ingen negativ inverkan på miljön.

Cisco har bekräftat att det är en lokal ändring och inte en global. Detta kommando bör utföras på alla switchar som har VPLEX anslutet. [Scott – finns det en Cisco-artikel som rör det här problemet som vi kan hänvisa till i denna KBA?]

Korrigering:

NX-OS 8.4(2c). Den här versionen har inte gjorts allmänt tillgänglig av Dell EMC.
[Scott – vi kan inte lista en korrigering som ännu inte är tillgänglig från Dell EMC. När den finns tillgänglig, lägg upp den här artikeln för granskning igen och ta bort meningen ”Den här versionen har inte gjorts allmänt tillgänglig av Dell EMC”]

Additional Information

Produkter (1)
Cisco MDS 9000 NX-OS- och SAN-OS-programvara

Kända berörda versioner
8.3(2)

VPLEX-strukturidentifiering

Exempel:
Värd 1, värd 2 och värd 3 zonanslutna till en enda VPLEX FE-port.

VPLEX FE-port: FCID 0x200b20
Värd 1: FCID 0x340000
Värd 2: FCID 0x340020
Värd 3: FCID 0x340040

Arbetar... [Scott – vad är det här? Taget/kopierat från info? Om så är fallet kan vi ta bort informationen ”arbetar...”]

 

  1. VPLEX skickar ett ”Hämta alla följande”-kommando till namnservern med fiberkanaladressen (FCID) för ”0xffffff” (högst)
  2. Namnservern svarar med information om VPLEX FE-porten (lägst)
  3. VPLEX skickar ett ”Hämta alla följande”-kommando till namnservern med fiberkanaladressen (FCID) för VPLEX FE-porten
  4. Namnservern svarar med information om värd 1
  5. VPLEX skickar ett ”Hämta alla följande”-kommando till namnservern med fiberkanaladressen (FCID) för värd 1
  6. Namnservern svarar med information om värd 2
  7. VPLEX skickar ett ”Hämta alla följande”-kommando till namnservern med fiberkanaladressen (FCID) för värd 2
  8. Namnservern svarar med information om värd 3
  9. VPLEX skickar ett ”Hämta alla följande”-kommando till namnservern med fiberkanaladressen (FCID) för värd 3
  10. Namnservern svarar med information om VPLEX Fe-porten
  11. VPLEX stannar här eftersom den har tagit emot sin egen fiberkanaladress (FCID) som redan har identifierats

Cisco-fel CSCvw75655 ...

 

  1. VPLEX skickar ett ”Hämta alla följande”-kommando till namnservern med fiberkanaladressen (FCID) för ”0xffffff” (högst)
  2. Namnservern svarar med information om VPLEX FE-porten (lägst)
  3. VPLEX skickar ett ”Hämta alla följande”-kommando till namnservern med fiberkanaladressen (FCID) för VPLEX FE-porten
  4. Namnservern svarar med information om VPLEX FE-porten
  5. VPLEX stannar här eftersom den har tagit emot sin egen fiberkanaladress (FCID) som redan har identifierats

Mer information om korrigeringen för fel CSCvw75655 som har lagts till i NX-OS 8.4(2c).
 
En påminnelse om vad som orsakar felet:
 
Problemet uppstår när en målenhet utfärdar ett FCNS GA_NXT-kommando och bara får tillbaka sitt eget FCID, vilket indikerar att den inte är zonansluten till någon annan enhet. Vissa målenheter utfärdar dessa GA_NXT regelbundet; de drivs inte av RSCN eller liknande och är därför sårbara för det här problemet.
Orsaken är att när aktivering/bekräftelse av en zonuppsättning pågår finns det ett litet tidsfönster där FCNS endast returnerar utfärdarens FCID i ett GA_NXT-svar och inget för de andra som den är zonansluten till. Det är en följd av zoneset shared database-funktionen som implementerades i Cisco MDS NX-OS 7.3(0)D1(1). 

 
Det här är Ciscos beskrivning av korrigeringen:

Som en del av aktiveringen utlöstes avaktivering, vilket tog bort SDB. Förutom att ta bort SDB skickade den ut ett meddelande till alla prenumeranter. Nu görs inte detta. Dessutom har en ny sekvens lagts till som skickar meddelandet om SDB-bekräftelse separat. Den gör att SDB skapas och ett sista meddelande skickas
Det finns endast en korrigering i version 8.4(2c).

 
SDB = Zoneset Shared Database.

Affected Products

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

Products

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