Limitação de distância F1 de vários saltos do Nexus 7000 FCoE

Introduction

Este documento descreve o que fazer se você experimentar descartes de entrada em interfaces de vários saltos Fibre Channel over Ethernet (FCoE). Este documento de problema/solução é útil quando os sintomas de descarte são identificados em interfaces que interconectam data centers remotos.

Este exemplo descreve um cenário real deste problema. 

A topologia mostrada no exemplo representa dois datacenters separados por 10KM. Há uma interface 10KM FCoE Virtual Expansion (VE) (multihop) que conecta DC1 e DC2. As interfaces multihop são configuradas em placas de linha N7K-F132XP-15. De acordo com esta ficha técnica da série F1, esta deve estar dentro do intervalo suportado.

Inicialmente, a folha de dados indicava estes recursos de ponte do data center IEEE (DCB - IEEE Data Center Bridging):

• Controle de fluxo baseado em prioridade (PFC): IEEE P802.1Qbb
• Seleção avançada de transmissão (ETS): IEEE P802.1Qaz
• Data Center Bridging Exchange (DCBX)
• Distância máxima do link sem perdas: 20 km

O bug da Cisco ID CSCts72420 foi modificado para endereçar a documentação. A linha em relação à distância de link sem perdas de 20 KM foi removida.

Problema

Os dispositivos EMC VPLEX oferecem suporte a um recurso de replicação de armazenamento. Este cenário usou replicação síncrona. Quando os dispositivos EMC VPLEX foram atualizados, eles ficaram "fora de sincronia". Após a atualização do VPLEX, os dispositivos começaram a replicar grandes quantidades de dados no link de vários saltos 10KM FCoE.

Quando a replicação de dados aumentou, esses eventos se espalharam:

1. O Nexus 5000-DC2 começou a enviar uma pausa constante para o Nexus 7000-DC2.
2. O Nexus 7000-DC2 começou a enviar uma pausa pelo link de 10 KM para o Nexus 7000-DC1.
3. O Nexus 7000-DC1 enviou uma pausa para o Nexus 5000-DC1, e assim por diante.

Esses eventos são uma visão de alto nível do comportamento esperado de controle de fluxo FCoE. Os quadros de pausa recebidos do Nexus 5000-DC2 indicam congestionamentos em um dispositivo final. À medida que os buffers de ingresso começam a ser preenchidos, os quadros de pausa são reproduzidos na estrutura.

O problema nesse cenário é que o Nexus 7000-DC2 descartou constantemente pacotes na entrada sobre o link de vários segmentos de 10KM.

Ethernet4/1 is up
  Dedicated Interface
  Hardware: 1000/10000 Ethernet, address: XXXX.XXXX.XXXX (bia XXXX.XXXX.XXXX)
  MTU bytes (CoS values): 9216(0-2,4-7) 2112(3)
  BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA
  Port mode is trunk
  full-duplex, 10 Gb/s, media type is 10G
  Beacon is turned off
  Auto-Negotiation is turned on
  Input flow-control is off, output flow-control is off
  Rate mode is dedicated
  Switchport monitor is off
  EtherType is 0x8100
  Last link flapped 25week(s) 0day(s)
  Last clearing of "show interface" counters 79w2d
  30 seconds input rate 296186536 bits/sec, 27891 packets/sec
  30 seconds output rate 151677360 bits/sec, 19294 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 289.58 Mbps, 27.61 Kpps; output rate 165.20 Mbps, 20.05 Kpps
  RX
    566235497816 unicast packets  2504479 multicast packets  0 broadcast packets
    566239834433 input packets  502487779153524 bytes
    219280594774 jumbo packets  0 storm suppression packets
    0 runts  0 giants  0 CRC  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  19312516 input discard
    1832141 Rx pause
  TX
    681040135255 unicast packets  2504251 multicast packets  0 broadcast packets
    681046392756 output packets  744942450903588 bytes
    333793360248 jumbo packets
    0 output error  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble  0 output discard
    3753250 Tx pause
  5 interface resets

Isso não deve acontecer porque a interface acima transporta apenas tráfego FCoE (CoS 3). Os descartes de entrada violam a política de QoS 'no-drop' para FCoE. Além disso, as devoluções em um ambiente FCoE podem levar a abortos SCSI, erros e assim por diante.

Solução

Quando um dispositivo envia uma pausa, a interface que gera o quadro de pausa deve ter uma fila de entrada com um espaço de buffer grande o suficiente para armazenar em buffer duas vezes a distância do link. Isso porque no momento em que a pausa é gerada o fio pode estar cheio. Quando o dispositivo adjacente receber/processar o quadro de pausa gerado, o fio poderá estar cheio novamente. Assim, o dispositivo que gera a pausa deve ter a capacidade de armazenar em buffer duas vezes a distância do link.

Após o cálculo, poderia haver mais de 100 pacotes em voo pelo link de 10KM. Devido a uma limitação de ASIC, a placa de linha da série F1 não pode suportar FCoE sem perdas em um link de 10KM ou superior. 

Note: O buffer de entrada (IB) é usado para colocar pacotes em fila em voo antes da pausa. Depois que a pausa é enviada, a IB não é mais usada. O LB (Latency Buffer) é usado para colocar pacotes em fila em andamento após o envio da pausa.

Atualizar hardware/software para suportar F2/F2e

ID de bug da Cisco CSCua10484 endereçou suporte a longa distância sem perdas F2. No NX-OS versão 6.1(2) e posterior, essas alterações de configuração são permitidas.

Note: Em versões anteriores do código, a alteração é permitida, mas não tem efeito.

O espaço restante na IB para capturar pacotes pode ser calculado como: PL_STOP - PL_PAUSE. Por padrão, os valores PL_STOP e HWM (PL_PAUSE) são os mesmos.

module-4# show hardware internal mac port 1 qos configuration | begin IB | end EB
  IB
    Port page limit : 3584 (1376256 Bytes)
    VL#  HWM pages(bytes)  LWM pages(bytes) Used PL_STOP(HWM & LWM)
                                            pages                    THR
     0    1107 (  425088)   1059 (  406656)     0     1107   1059
     1       2 (     768)      1 (     384)     0        2      1
     2    1107 (  425088)   1059 (  406656)     0     1107   1059
     3    1053 (  404352)   1029 (  395136)     0     1053   1029
     4       2 (     768)      1 (     384)     0        2      1
     5     231 (   88704)    159 (   61056)     0      231    159
     6       2 (     768)      1 (     384)     0        2      1
     7       2 (     768)      1 (     384)     0        2      1
    Credited DWRR WT: 216 (0xd8) Uncredited DWRR WT: 144 (0x90)
    DWRR honor UC = FALSE
     Leak Lo weight = 0xd8, enabled = FALSE
  EB

Você pode modificar esses valores para suportar uma distância maior pela alocação de buffers maiores para a Classe de Serviço (CoS - Class of Service) sem queda. Para concluir isso, duplique o mapa de políticas de Qualidade de Serviço (QoS) 'padrão-4q-7e-em-política'.

Note: O próximo cenário de configuração é adaptado para um aumento na alocação de buffer de entrada COS 3 no Nexus 7000 com VDC padrão, não VDC de administração. Como o VDC de administração é estritamente um VDC de "gerenciamento", sem funcionalidade de plano de dados, não são necessárias etapas adicionais para copiar a política de QoS e modificar as alocações de buffer, dentro desse VDC. Portanto, se você usar o VDC de administração, faça apenas essas modificações no VDC de armazenamento.

Por padrão e VDC de armazenamento

Switch(config)# qos copy policy-map type queuing ?
*** No matching command found in current mode, matching in (exec) mode ***
  default-4q-7e-in-policy   Default 7-ethernet input queuing policy
  default-4q-7e-out-policy  Default 7-ethernet output queuing policy

Switch(config)# qos copy policy-map type queuing default-4q-7e-in-policy prefix 7I_

Depois que a política for copiada no VDC padrão e no VDC de armazenamento, modifique o mapa de política '4q-7e-in' para alocar uma porcentagem de limite de fila maior para o COS sem queda.

Por padrão e VDC de armazenamento

Switch(config)# show run ipqos
<snippet>

policy-map type queuing 7I_4q-7e-in
  class type queuing c-4q-7e-drop-in
    service-policy type queuing 7I_4q-7e-drop-in
    queue-limit percent 1                 <<<<<<<<<<<<<<<<<
  class type queuing c-4q-7e-ndrop-in
    service-policy type queuing 7I_4q-7e-ndrop-in
    queue-limit percent 99                <<<<<<<<<<<<<<<<<

Agora, aplique a política de QoS modificada à interface desejada:

No VDC de armazenamento

Switch(config)# int e4/1
Switch(config-if)# service-policy type queuing input 7I_4q-7e-in
Switch(config-if)# show run int e4/1

!Command: show running-config interface Ethernet4/1
!Time: Sun Mar  2 21:03:07 2014

version 6.1(4)

interface Ethernet4/1
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 1,2990
  load-interval counter 2 30
  service-policy type queuing input 7I_4q-7e-in
  no shutdown

Agora, observe que o valor PL_STOP é maior que a Marca d'água alta ( HWM). Assim, um maior recurso de buffer é permitido para a IB.

module-4# show hardware internal mac port 1 qos configuration | begin IB | end EB
  IB
    Port page limit : 3584 (1376256 Bytes)
    VL#  HWM pages(bytes)  LWM pages(bytes) Used PL_STOP(HWM & LWM)
                                            pages                    THR
     0      15 (    5760)      9 (    3456)     0       15      9
     1       2 (     768)      1 (     384)     0        2      1
     2      15 (    5760)      9 (    3456)     0       15      9
     3    1161 (  445824)   1137 (  436608)     0     3521   1137
     4       2 (     768)      1 (     384)     0        2      1
     5       3 (    1152)      0 (       0)     0        3      0
     6       2 (     768)      1 (     384)     0        2      1
     7       2 (     768)      1 (     384)     0        2      1
    Credited DWRR WT: 216 (0xd8) Uncredited DWRR WT: 144 (0x90)
    DWRR honor UC = FALSE
     Leak Lo weight = 0xd8, enabled = FALSE
  EB

No exemplo, o espaço deixado em IB = 3521 páginas - 1161 páginas = 2360 páginas => 906.240 bytes.

Note: Essa solução alternativa é aceitável quando SOMENTE o tráfego FCoE é passado pela interface multihop FCoE. Se o tráfego de dados também for passado, entre em contato com o Cisco Technical Assistance Center (TAC) para obter assistência.

Ou

Se disponível, use Fibre Channel (FC) nativo entre os locais. Essa solução exige a intervenção de Multiplexador de Divisor de Comprimento de Onda Cruzado/Multiplexador de Divisor de Comprimento de Onda Denso (CWDM/DWDM) ou fibra escura, dependendo da distância necessária.

Histórico de revisões