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

Switch Cisco MDS: gli host perdono un percorso per le porte front-end (FE) VPLEX in un'attivazione di zone

Summary: In un'attivazione di zone, tutti gli HBA suddivisi in zone in una porta front-end VPLEX sono disconnessi e perdono un percorso. Gli host ESX possono bloccarsi ed è necessario un riavvio per ripristinarli. [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 applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

L'host perde percorsi.
[NOTE- Scott also see note in the summary]

L'host ESX si blocca ed è necessario un riavvio per ripristinarlo. [ Scott is it just ESX hosts that can become hung? The summary states "all HBAs zoned to VPLEX"]

Dal registro "vmkernel" dell'host ESXi:

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


Dai registri del firmware 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 - 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 ? ]


Modifica:
Attivazione di zone.
Le porte HBA e le porte front-end VPLEX non sono coinvolte nelle modifiche alla suddivisione in zone.
[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 esegue l'individuazione della fabric su tutte le porte Fibre Channel (front-end, back-end e FC-WANCOM) ogni 90 secondi utilizzando il comando "Get all next" (GA_NXT) del server dei nomi. Eseguirà questa operazione oltre a ricevere un comando RSCN dallo switch o PLOGI da un HBA suddiviso in zone.

Per via del bug Cisco CSCvw75655, se VPLEX esegue l'individuazione della fabric su una porta front-end (FE) mentre è in corso un'attivazione/commit di un set di zone, è poco probabile che VPLEX riceva solo il proprio indirizzo Fibre Channel (FCID), quindi presume che qualsiasi HBA collegato al suo interno non sia più connesso alla fabric e invierà un comando di disconnessione (PLOGO) a ciascun HBA suddiviso in zone. [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 registrerà gli eventi fc/4 per ogni HBA che disconnette e gli eventi fc/3 alla successiva individuazione di fabric dopo 90 secondi, quando riceve le informazioni corrette dal server dei nomi dello switch.

Il modo in cui l'HBA gestisce questa disconnessione dipende dal driver/firmware. L'host ESX in questo esempio si è bloccato e ha richiesto un riavvio. [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?]

NOTA:
Viene eseguita l'individuazione di fabric periodica per garantire che VPLEX disponga di dati di fabric aggiornati, in quanto è possibile che non tutti i comandi RSCN raggiungano VPLEX dalla fabric.

Resolution

Soluzione alternativa:

Nello switch Cisco disabilitare la funzione di database (db) condiviso del server dei nomi/server delle zone come segue:
 

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


NOTA: la funzione shared-db del set di zone è efficiente laddove il server dei nomi e il server delle zone condividono informazioni. La disabilitazione della funzione non avrà alcun impatto negativo sull'ambiente.

Cisco ha confermato che si tratta di una modifica locale e non globale. Questo comando deve essere eseguito su ogni switch con VPLEX collegato. [Scott - is there a Cisco KB that talks to this issue that we can reference in this KBA?]

Correzione:

NX-OS 8.4(2c). Questa versione non è stata resa generalmente disponibile da 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

Prodotti (1)
Software Cisco MDS 9000 NX-OS e SAN-OS

Versioni note interessate
8.3(2)

Individuazione della fabric VPLEX

Esempio:
Host 1, Host 2 e Host 3 suddivisi in zone in una porta VPLEX FE singola.

Porta VPLEX FE: 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 invierà un comando "Get all next" al server dei nomi con l'indirizzo Fibre Channel (FCID) di "0xffffff" (massimo)
  2. Il server dei nomi risponderà con i dettagli della porta VPLEX FE (minimo)
  3. VPLEX invierà un comando "Get all next" al server dei nomi con l'indirizzo Fibre Channel (FCID) della porta VPLEX FE
  4. Il server dei nomi risponderà con i dettagli dell'Host 1
  5. VPLEX invierà un comando "Get all next" al server dei nomi con l'indirizzo Fibre Channel (FCID) dell'Host 1
  6. Il server dei nomi risponderà con i dettagli dell'Host 2
  7. VPLEX invierà un comando "Get all next" al server dei nomi con l'indirizzo Fibre Channel (FCID) dell'Host 2
  8. Il server dei nomi risponderà con i dettagli dell'Host 3
  9. VPLEX invierà un comando "Get all next" al server dei nomi con l'indirizzo Fibre Channel (FCID) dell'Host 3
  10. Il server dei nomi risponderà con i dettagli della porta VPLEX FE
  11. VPLEX si arresta qui in quanto ha ricevuto il suo stesso indirizzo Fibre Channel (FCID), già individuato (processo incrociato)

Bug Cisco CSCvw75655 ...

 

  1. VPLEX invierà un comando "Get all next" al server dei nomi con l'indirizzo Fibre Channel (FCID) di "0xffffff" (massimo)
  2. Il server dei nomi risponderà con i dettagli della porta VPLEX FE (minimo)
  3. VPLEX invierà un comando "Get all next" al server dei nomi con l'indirizzo Fibre Channel (FCID) della porta VPLEX FE
  4. Il server dei nomi risponderà con i dettagli della porta VPLEX FE
  5. VPLEX si arresta qui in quanto ha ricevuto il suo stesso indirizzo Fibre Channel (FCID), già individuato (processo incrociato)

Ulteriori dettagli relativi alla correzione per il bug CSCvw75655 aggiunto a NX-OS 8.4(2c).
 
Promemoria su ciò che causa questo bug:
 
Il problema si verifica quando un dispositivo di destinazione emette un comando FCNS GA_NXT e riceve solo il proprio FCID, a indicare che non è suddiviso in zone con altri dispositivi. Alcuni dispositivi di destinazione generano questi comandi GA_NXT periodicamente. Non sono gestiti da RSCN o altri e sono quindi soggetti a questo problema.
La causa è dovuta al fatto che, quando è in corso un'attivazione/commit di un set di zone, vi è una piccola finestra temporale in cui FCNS restituirà solo l'FCID dell'emittente in una risposta GA_NXT e nessuno degli altri con cui è suddiviso in zone. Questa è una conseguenza della funzione del database condiviso del set di zone implementata in Cisco MDS NX-OS 7.3(0)D1(1). 

 
Questa è la descrizione della correzione di Cisco:

Nell'ambito dell'attivazione, si attiva la disattivazione che cancella l'SDB. Oltre a cancellare l'SDB, invia una notifica a tutti i sottoscrittori. Ora questa operazione non avviene. Inoltre, è stata aggiunta una nuova sequenza che invierà la notifica di commit dell'SDB separatamente. In questo modo sarà possibile eseguire la suddivisione in zone per creare l'SDB e inviare una notifica finale 
È presente una correzione solo nella versione 8.4(2c).

 
SDB = database condiviso del set di zone.

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
Article Properties
Article Number: 000181952
Article Type: Solution
Last Modified: 19 Aug 2021
Version:  4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.