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: Os hosts perdem um caminho para as portas de FE (Front-End) do VPLEX em uma ativação de zonas

Summary: Em uma ativação de zonas, todos os HBAs zoneados para uma porta de front-end do VPLEX são desconectados e perdem um caminho. Os hosts ESX podem travar e precisar de uma reinicialização para recuperação. [Scott - Isso afeta somente os hosts ESX? No resumo, temos "todos os HBAs zoneados para o VPLEX". Queremos limitar isso somente a hosts ESX ou devemos reformular a frase e dizer: "Os hosts podem travar e precisar de uma reinicialização para recuperação?] ...

This article applies to   This article does not apply to 

Symptoms

O host perde caminhos.
[NOTA - Scott - Veja também nota no resumo]

O host ESX trava e precisa de uma reinicialização para recuperação. [Scott - Somente hosts ESX podem travar? O resumo informa: "Todos os HBAs zoneados para o VPLEX"]

No log "vmkernel" do 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


From the VPLEX firmware logs :
evento 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 - De volta ao problema "Todos os HBAs zoneados para o VPLEX", se esse problema da Cisco afetar todos os HBAs zoneados para o VPLEX, deveremos mostrar relatórios de outros hosts que partem nos logs de fw? Vemos outros hosts partindo do mesmo host esx mostrado acima?]

evento 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: Temos esses dados para os outros HBAs vistos que também chegaram? ]


Alteração:
Ativação de zonas.
As portas HBA e as portas de front-end do VPLEX não estão envolvidas nas alterações de zoneamento.
[Scott - Esta última frase não faz sentido. Entendo o problema desta forma: quando há uma ativação de conjunto de zonas em um switch Cisco, todas as portas HBA e todas as portas de FE do VPLEX "estão" envolvidas. Além disso, quais níveis de código do switch Cisco isso afeta?]

Cause

O VPLEX realiza uma detecção de fabric em todas as portas Fibre Channel (front-end, back-end e FC-WANCOM) a cada 90 segundos, usando o comando "Get all next" (GA_NXT) do servidor de nomes. Ele fará isso fora do recebimento de uma RSCN do switch ou do PLOGI de um HBA zoneado.

Devido ao bug CSCvw75655 da Cisco, se o VPLEX estiver executando sua detecção de fabric em uma porta de FE (Front-End) enquanto uma ativação/confirmação do conjunto de zonas estiver em andamento, haverá uma pequena chance de que o VPLEX receba seu próprio endereço Fibre Channel (FCID). Com isso, ele assumirá que qualquer HBA conectado a ele não está mais conectado ao fabric e enviará um log-out (PLOGO) a cada HBA zoneado a ele. [Scott - São os logs do VPLEX e/ou do switch que mostram essa ação ocorrendo, o PLOGO sendo enviado? Se isso puder ser visto em ambos os produtos, podemos incluir exemplos disso e em quais logs isso é visto?]

O VPLEX registrará os eventos fc/4 para cada HBA de que ele fizer logout e registrará os eventos fc/3 na próxima detecção de fabric em 90 segundos, quando receber as informações corretas do servidor de nomes de switches.

A forma como o HBA lida com esse log-out dependerá de seu driver/firmware. Neste exemplo, o host ESX travou e precisou de uma reinicialização. [Scott - Temos dados dos logs de outros hosts que estão sendo afetados por esse evento? Em caso afirmativo, é possível listar também alguns deles para que não pareça que apenas os hosts ESX são afetados?]

NOTA:
A detecção periódica de fabric é realizada para garantir que o VPLEX tenha atualizado os dados de fabric, pois é possível que nem todas as RSCNs alcancem o VPLEX a partir do fabric.

Resolution

Solução temporária:

No switch Cisco, desative o recurso de banco de dados compartilhado do servidor de nomes/servidor de zonas da seguinte forma:
 

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


NOTA: A função shared-db do conjunto de zonas é eficaz apenas onde o servidor de nomes e o servidor de zonas compartilham informações. A desativação do recurso não terá impacto negativo no ambiente.

A Cisco confirmou que a alteração é local, e não global. Esse comando deve ser executado em cada switch que tenha o VPLEX conectado a ele. [Scott - Existe uma KB da Cisco que trata desse problema e que podemos mencionar neste KBA?]

Correção:

NX-OS 8.4(2c). Esta versão não foi disponibilizada pela Dell EMC.
[Scott - Não podemos listar uma correção que ainda não esteja disponível na Dell EMC. Depois de disponibilizada, publique novamente este KBA para análise e remova a frase "Esta versão não foi disponibilizada pela Dell EMC"]

Additional Information

Produtos (1)
Softwares Cisco MDS 9000 NX-OS e SAN-OS

Versões afetadas conhecidas
8.3(2)

Detecção de fabrics do VPLEX

Exemplo:
Host 1, Host 2 e Host 3 zoneados para uma única porta de FE do VPLEX.

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

Working... [Scott - O que é isso? Foi obtido/copiado das informações? Em caso afirmativo, podemos remover a informação de "Working..."]

 

  1. O VPLEX enviará um comando "Get all next" ao servidor de nomes com o endereço Fibre Channel (FCID) "0xffffff" (mais alto)
  2. O servidor de nomes responderá com os detalhes da porta de FE do VPLEX (mais baixa)
  3. O VPLEX enviará um comando "Get all next" ao servidor de nomes com o endereço Fibre Channel (FCID) da porta de FE do VPLEX
  4. O servidor de nomes responderá com os detalhes do Host 1
  5. O VPLEX enviará um comando "Get all next" ao servidor de nomes com o endereço Fibre Channel (FCID) do Host 1
  6. O servidor de nomes responderá com os detalhes do Host 2
  7. O VPLEX enviará um comando "Get all next" ao servidor de nomes com o endereço Fibre Channel (FCID) do Host 2
  8. O servidor de nomes responderá com os detalhes do Host 3
  9. O VPLEX enviará um comando "Get all next" ao servidor de nomes com o endereço Fibre Channel (FCID) do Host 3
  10. O servidor de nomes responderá com os detalhes da porta de FE do VPLEX
  11. O VPLEX para neste ponto, pois recebeu o endereço Fibre Channel (FCID) de si mesmo, que já foi detectado (cruzado novamente)

Bug da Cisco: CSCvw75655 ...

 

  1. O VPLEX enviará um comando "Get all next" para o servidor de nomes com o FCID (Fibre Channel Address, Endereço Fibre Channel) "0xffffff" (mais alto)
  2. O servidor de nomes responderá com os detalhes da porta de FE do VPLEX (mais baixa)
  3. O VPLEX enviará um comando "Get all next" ao servidor de nomes com o endereço Fibre Channel (FCID) da porta de FE do VPLEX
  4. O servidor de nomes responderá com os detalhes da porta de FE do VPLEX
  5. O VPLEX para neste ponto, pois recebeu o endereço Fibre Channel (FCID) de si mesmo, que já foi detectado (cruzado novamente)

Detalhes adicionais sobre a correção do bug CSCvw75655 que foi adicionado ao NX-OS 8.4(2c).
 
Um lembrete do que causa este bug:
 
O problema ocorre quando um dispositivo de destino emite um comando FCNS GA_NXT e só recebe seu próprio FCID de volta, indicando que ele não está zoneado com nenhum outro dispositivo. Alguns dispositivos de destino emitem esses comandos GA_NXT periodicamente; eles não são orientados por RSCN ou outro estímulo e, portanto, são vulneráveis a esse problema.
A causa é que, quando uma ativação/confirmação do conjunto de zonas está em andamento, há um curto período em que o FCNS retornará apenas o FCID do emissor em uma resposta ao GA_NXT e de nenhum dos outros com os quais ele está zoneado. Essa é uma consequência da função de banco de dados compartilhado do conjunto de zonas que foi implementada no Cisco MDS NX-OS 7.3(0)D1(1). 

 
Esta é a descrição da correção da Cisco:

Como parte da ativação, os acionadores de desativação limpam o SDB. Ao limpar o SDB, é enviada uma notificação para todos os assinantes. Agora, isso não ocorre. Além disso, foi adicionada uma nova sequência que enviará a notificação de confirmação do SDB separadamente. Isso fará o zoneamento para criar o SDB e enviará uma notificação final. 
Há uma correção somente na versão 8.4(2c).

 
SDB = Zoneset Shared Database (banco de dados compartilhado do conjunto de zonas).

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