Solucione problemas do pacote Ethernet corrompido no Cisco Nexus 9000

Introduction

Este documento descreve como solucionar problemas do pacote Ethernet corrompido no Cisco Nexus 9000 quando uma informação de preenchimento está corrompida ou mal formada.

Informações de Apoio

O tamanho mínimo de um quadro Ethernet é 64 bytes, independentemente da marca de VLAN estar presente ou não.

O tamanho mínimo do payload Ethernet é:

• 46 bytes se a marca de VLAN estiver ausente.
• 42 bytes se a marca de VLAN estiver presente.

Você pode verificar este fato:

• Na Wikipédia, seção Payload: https://en.wikipedia.org/wiki/Ethernet_frame
• No padrão IEEE 802.3 (http://people.ee.duke.edu/~mbrooke/EE164.02/Spring_2004/group_2/index_files/8023.pdf), onde o formato do quadro MAC (sem VLAN) é definido na seção 3.1.1, página 39, e os elementos de um quadro MAC marcado são definidos na página 43, seção 3.5.

O tamanho mínimo de um pacote ethernet é 64 bytes, independentemente do cabeçalho da VLAN estar presente ou não. O servidor tem permissão para enviar um pacote de 64 bytes que contém uma VLAN, que você deve aceitar e processar corretamente.

Note: Esse comportamento é tratado corretamente por um catalyst 4500x e não pelo Nexus 9k.

Como um pacote é processado por um switch

Etapa 1. Receba um quadro Ethernet VÁLIDO de 64 bytes.

Etapa 2. Remova a FCS (Frame Check Sequence, sequência de verificação de quadro), de modo que o pacote tenha 60 bytes de comprimento.

Etapa 3. Remova a marca da VLAN para que o pacote tenha 56 bytes de comprimento.

Etapa 4. Adicione o preenchimento para tornar o pacote de 60 bytes longo.

Etapa 5. Ele adiciona o FCS, tornando o pacote de 64 bytes longo.

O enchimento não deve ser modificado quando um pacote passa pelo switch cut-through.

Preenchimento modificado com VLANs marcadas quando o tráfego atravessa N9K

Em vez de enchimento com zeros, o pacote é almofadado com caracteres de lixo, na maioria dos casos não tem impacto porque somas de verificação não são modificadas e ninguém usa esses dados. No entanto, se os clientes tiverem um uso especial e precisarem recomputar as somas de verificação, esses dados de lixo levarão à corrupção das somas de verificação no final (outros dispositivos, como NAT/balanceadores de carga, também podem ver o problema).

O dispositivo é um N9K 93120TX (foi detectado inicialmente em um 9372TX), mas a versão é a mais recente do NXOS 7.0(3)I2(2a).

Use hosts Linux com hardware diretamente conectado ao N9K (sem virtualização de qualquer tipo) aqui (links 1000base-T).

Use esta configuração:

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

Basta conectar o host do Windows e enviar os quadros marcados, eles devem disparar o problema. Além disso, certifique-se de que a placa de rede (NIC) tenha a capacidade de marcar o pacote.

O switch adiciona o preenchimento diferente de zero aos quadros que passam.

Por exemplo: Host — [Tronco] N9K [Tronco] — Host

Você pode usar o netcat para enviar e receber os pacotes.

Como mostrado na imagem, ele envia Side (VLAN 100 marcado), porta e1/59 no switch.

Ele recebe o Lado (VLAN 100 marcado), a porta e1/60 no switch, como mostrado na imagem:

Como mostrado na imagem, o pacote é transmitido.

O pacote é recebido, como mostrado na imagem:

Como mostrado na imagem, o preenchimento errado é realçado.

Isso também é exibido com um analisador de pacotes (em outro pacote, os dados são diferentes das capturas de tela anteriores, mas o teste e o bug são idênticos),

Solução

A solução alternativa é desativar o buffer-boost na interface onde temos esse servidor conectado.

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

Defeito relacionado:

Quadro CSCva46849 de 60 bytes com comutação L2 do cabeçalho dot1q em N9k