Solución de problemas del paquete Ethernet dañado en Cisco Nexus 9000

Introducción

Este documento describe cómo resolver problemas del paquete Ethernet dañado en Cisco Nexus 9000 cuando la información de relleno está dañada o mal formada.

Antecedentes

El tamaño mínimo de una trama Ethernet es de 64 bytes, independientemente de que la etiqueta VLAN esté presente o no.

El tamaño mínimo de carga útil Ethernet es:

• 46 bytes si la etiqueta VLAN está ausente.
• 42 bytes si la etiqueta VLAN está presente.

Puede verificar este hecho:

• En Wikipedia, sección Carga útil: https://en.wikipedia.org/wiki/Ethernet_frame
• En el estándar IEEE 802.3 (http://people.ee.duke.edu/~mbrooke/EE164.02/Spring_2004/group_2/index_files/8023.pdf), donde el formato de trama MAC (sin VLAN) se define en la sección 3.1.1, página 39, y los elementos de una trama MAC etiquetada se definen en la sección 3.5 de la página 43.

El tamaño mínimo de un paquete Ethernet es de 64 bytes, independientemente de que el encabezado VLAN esté o no presente. El servidor puede enviar un paquete de 64 bytes que contiene una VLAN, que debe aceptar y procesar correctamente.

Nota: Este comportamiento es manejado correctamente por un Catalyst 4500x no por Nexus 9k.

Cómo procesa un paquete un switch

Paso 1. Reciba una trama Ethernet VÁLIDA de 64 bytes.

Paso 2. Quite la secuencia de verificación de tramas (FCS), de modo que el paquete tenga 60 bytes.

Paso 3. Quite la etiqueta VLAN, de modo que el paquete tenga 56 bytes.

Paso 4. Agregue relleno para hacer que el paquete tenga 60 bytes.

Paso 5. Agrega el FCS, haciendo que el paquete tenga 64 bytes de longitud.

El relleno no debe modificarse cuando un paquete pasa por un switch de conexión directa.

Relleno modificado con VLAN etiquetadas cuando el tráfico atraviesa N9K

En lugar de relleno con ceros, el paquete se agrega con caracteres basura, en la mayoría de los casos no tiene impacto porque las sumas de comprobación no se modifican y por lo tanto nadie utiliza estos datos. Sin embargo, si los clientes tienen un uso especial y necesitan volver a calcular las sumas de comprobación, estos datos no utilizados provocan una corrupción de las sumas de comprobación al final (otros dispositivos, como los equilibradores de carga/NAT, podrían ver el problema también).

El dispositivo es un N9K 93120TX (detectado inicialmente en un 9372TX), la versión es la última versión de NXOS 7.0(3)I2(2a).

Utilice hosts Linux con hardware conectado directamente al N9K (sin virtualización de ningún tipo) aquí (enlaces 1000base-T).

Utilice esta configuración:

interface Ethernet1/59

  switchport mode trunk

!

interface Ethernet1/60

  switchport mode trunk

 

linux configurations:

inet 10.2.1.1/24 brd 10.2.1.255 scope global eth1  <= native vlan

inet 10.1.1.1/24 brd 10.1.1.255 scope global eth1.100 <= taggued vlan 100

or

Sólo tiene que conectar el host de windows y enviar las tramas etiquetadas, deben activar el problema. Además, asegúrese de que la tarjeta de interfaz de red (NIC) tenga la capacidad de etiquetar el paquete.

El switch agrega el relleno distinto de cero a las tramas que pasan.

Por ejemplo: Host — [Trunk] N9K [Trunk] — Host

Puede utilizar netcat para enviar y recibir los paquetes.

Como se muestra en la imagen, envía Side (VLAN 100 etiquetada), puerto e1/59 en el switch.

Recibe Side (VLAN 100 etiquetada), puerto e1/60 en el switch, como se muestra en la imagen:

Como se muestra en la imagen, el paquete se transmite.

Se recibe el paquete, como se muestra en la imagen:

Como se muestra en la imagen, se resalta el relleno incorrecto.

Esto también se muestra con un analizador de paquetes (en otro paquete, los datos son diferentes de las capturas de pantalla anteriores, pero la prueba y el error son idénticos),

Solución

La solución alternativa es inhabilitar el buffer-up en la interfaz donde tenemos este servidor conectado.

C9396PX-1(config)# int et 1/7
C9396PX-1(config-if)# no buffer-boost

Defecto relacionado:

CSCva46849 Trama de 60 bytes con conmutación de encabezado L2 dot1q en N9k