Contenido

Introducción

Problema

Solución

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

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.