Limitación de la distancia F1 multisalto FCoE de Nexus 7000

Introducción

Este documento describe qué hacer si experimenta descartes de entrada en interfaces multisalto Fibre Channel over Ethernet (FCoE). Este documento de problema/solución es útil cuando se identifican los síntomas de descarte en las interfaces que interconectan los Data Centers remotos.

Este ejemplo representa un escenario real de este problema. 

La topología mostrada en el ejemplo representa dos Data Centers separados por 10KM. Existe una interfaz de expansión virtual (VE) (multisalto) FCoE de 10 KM que conecta DC1 y DC2. Las interfaces multisalto se configuran en tarjetas de línea N7K-F132XP-15. Según esta hoja de datos de la serie F1, esto debería haber estado dentro del rango soportado.

Inicialmente, la hoja de datos indicaba estas funciones de IEEE Data Center Bridging (DCB):

• Control de flujo basado en prioridades (PFC): IEEE P802.1Qbb
• Selección de transmisión mejorada (ETS): IEEE P802.1Qaz
• Intercambio de puente de Data Center (DCBX)
• Distancia máxima de link sin pérdidas: 20 km

El ID de bug de Cisco CSCts72420 se modificó para abordar la documentación. Se eliminó la línea con respecto a la distancia de enlace sin pérdidas de 20KM.

Problema

Los dispositivos VPLEX de EMC soportan una función de replicación de almacenamiento. Esta situación utilizó replicación sincrónica. Cuando se actualizaron los dispositivos VPLEX de EMC, se "dessincronizaron". Después de la actualización de VPLEX, los dispositivos comenzaron a replicar grandes cantidades de datos en el link multisalto FCoE de 10 KM.

Cuando la replicación de datos aumentó, estos eventos ocurrieron:

1. El Nexus 5000-DC2 comenzó a enviar una pausa constante al Nexus 7000-DC2.
2. El Nexus 7000-DC2 comenzó a enviar una pausa sobre el link de 10 KM al Nexus 7000-DC1.
3. El Nexus 7000-DC1 envió una pausa al Nexus 5000-DC1, y así sucesivamente.

Estos eventos son una vista de alto nivel del comportamiento de control de flujo FCoE esperado. Las tramas de pausa recibidas de Nexus 5000-DC2 indican congestiones en un dispositivo final. A medida que las memorias intermedias de ingreso empiezan a llenarse, las tramas se filtran de nuevo en el entramado.

El problema en este escenario es que el Nexus 7000-DC2 descartó paquetes constantemente en el ingreso a través del link mulithop 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

Esto no debería ocurrir porque la interfaz anterior sólo transporta tráfico FCoE (CoS 3). Los descartes de entrada infringen la política de QoS 'sin descarte' para FCoE. Además, los descartes en un entorno FCoE podrían dar lugar a abortos SCSI, errores, etc.

Solución

Cuando un dispositivo envía una pausa, la interfaz que genera la trama de pausa debe tener una cola de ingreso con un espacio de búfer lo suficientemente grande como para almacenar en búfer dos veces la distancia de link. Esto se debe a que en el momento en que se genera la pausa, el cable podría estar lleno. Cuando el dispositivo adyacente recibe/procesa la trama de pausa generada, el cable podría estar lleno de nuevo. Por lo tanto, el dispositivo que genera la pausa debe tener la capacidad de almacenar en búfer dos veces la distancia de link.

Tras el cálculo, podría haber habido más de 100 paquetes en vuelo a través del link de 10KM. Debido a una limitación ASIC, la tarjeta de línea de la serie F1 no admite FCoE sin pérdidas en un link de 10KM o superior. 

Nota: El búfer de entrada (IB) se utiliza para poner en cola los paquetes en vuelo antes de la pausa. Después de enviar la pausa, IB ya no se utiliza. El búfer de latencia (LB) se utiliza para poner en cola los paquetes en vuelo después de enviar la pausa.

Actualización de hardware/software para soportar F2/F2e

El ID de bug de Cisco CSCua10484 se dirigió al soporte de larga distancia de trayecto F2 sin pérdida de distancia. En NX-OS versión 6.1(2) y posteriores, se permiten estos cambios de configuración.

Nota: En las versiones anteriores del código, el cambio está permitido pero no tiene efecto.

El espacio que queda en la IB para capturar paquetes se puede calcular como: PL_STOP - PL_PAUSE. De forma predeterminada, los valores PL_STOP y HWM (PL_PAUSE) son los mismos.

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

Puede modificar estos valores para admitir una mayor distancia mediante la asignación de búferes mayores a la clase de servicio (CoS) sin descartar. Para completar esto, duplique el mapa de política de calidad de servicio (QoS) 'default-4q-7e-in-policy'.

Nota: El siguiente escenario de configuración se adapta a un aumento en la asignación de búfer de ingreso de COS 3 en Nexus 7000 con VDC predeterminado, no con VDC de administrador. Dado que el VDC de administración es estrictamente un VDC de "administración", sin funcionalidad de plano de datos, no se necesitan pasos adicionales para copiar la política de QoS y modificar las asignaciones de búfer, dentro de este VDC. Por lo tanto, si utiliza el VDC de administración, sólo realice estas modificaciones en el VDC de almacenamiento.

En VDC predeterminado y de almacenamiento

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_

Después de que la política se copie en el VDC predeterminado y en el VDC de almacenamiento, modifique el policy-map '4q-7e-in' para asignar un mayor porcentaje de límite de cola al COS sin descarte.

En VDC predeterminado y de almacenamiento

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                <<<<<<<<<<<<<<<<<

Ahora, aplique la política de QoS modificada a la interfaz deseada:

En VDC de almacenamiento

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

Ahora, observe que el valor PL_STOP es mayor que la Marca de agua alta (HWM). Por lo tanto, se permite una mayor capacidad de almacenamiento en búfer para 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

En el ejemplo, el espacio que queda en IB = 3521 páginas - 1161 páginas = 2360 páginas => 906,240 bytes.

Nota: Esta solución alternativa es aceptable cuando SOLAMENTE el tráfico FCoE pasa por la interfaz multisalto FCoE. Si también pasa el tráfico de datos, póngase en contacto con el centro de asistencia técnica Cisco Technical Assistance Center (TAC) para obtener asistencia.

O bien

Si está disponible, utilice Fibre Channel (FC) nativo entre sitios. Esta solución requiere una intervención de multiplexor de división de longitud de onda aproximada/multiplexor de división de longitud de onda densa (CWDM/DWDM) o fibra oscura, según la distancia requerida.

Historial de revisiones