Probleemoplossing voor het gecorrumpeerde Ethernet-pakket op Cisco Nexus 9000

Inleiding

Dit document beschrijft hoe u het gecorrumpeerde Ethernet-pakket op Cisco Nexus 9000 kunt oplossen wanneer een toegevoegde informatie gecorrumpeerd of misvormd is.

Achtergrondinformatie

De minimale grootte van een Ethernet frame is 64 bytes, ongeacht of de VLAN-tag er is of niet.

De minimale Ethernet lading is:

• 46 bytes als de VLAN-tag niet aanwezig is.
• 42 bytes als de VLAN-tag aanwezig is.

U kunt dit feit controleren:

• Op Wikipedia, sectie payload: https://en.wikipedia.org/wiki/Ethernet_frame
• Op de standaard IEEE 802.3 (http://people.ee.duke.edu/~mbrooke/EE164.02/Spring_2004/group_2/index_files/8023.pdf) wordt het MAC-frame-formaat (zonder VLAN) gedefinieerd in sectie 3.1.1, pagina 39, en de elementen van een gelabeld MAC-frame zijn gedefinieerd op pagina 43, punt 3.5.

De minimale grootte van een Ethernet-pakket is 64 bytes, ongeacht of de VLAN-header aanwezig is of niet. De server mag een 64 bytes lang pakket verzenden dat een VLAN bevat, dat u correct moet accepteren en verwerken.

Opmerking: Dit gedrag wordt correct behandeld door een Catalyst 4500x niet door Nexus 9k.

Hoe een pakket wordt verwerkt door een Switch

Stap 1. Ontvang een GELDIG 64 bytes Ethernet-frame.

Stap 2. Verwijder de Frame Control Sequence (FCS), zodat het pakket 60 bytes lang wordt.

Stap 3. Verwijder de tag VLAN zodat het pakket 56 bytes lang wordt.

Stap 4. Voeg het toevoegen toe om het pakket 60 bytes lang te maken.

Stap 5. Het voegt FCS toe, waardoor het pakket 64 bytes lang wordt.

Het toevoegen moet niet worden aangepast wanneer een pakje door een doorsnede switch gaat.

Toevoegen gewijzigd met VLAN’s met tag wanneer verkeer N9K overschrijdt

In plaats van het toevoegen met nullen, wordt het pakje toegevoegd met vuilnistekens. In de meeste gevallen heeft het geen impact omdat de checksum niet aangepast is en dus niemand deze data gebruikt. Als klanten echter speciaal gebruik hebben en de checksum moeten herberekenen, leidt deze vuilnisinformatie tot corruptie van checksum (waar andere apparaten, zoals NAT/load-stabilisatoren, het probleem misschien ook zien).

Apparaat is een N9K 93120TX (oorspronkelijk gedetecteerd op een 9372TX alhoewel), is versie laatste NXOS 7.0(3)I2(2a).

Gebruik hier Linux-hosts met direct aangesloten hardware op de N9K (geen virtualisatie van welke aard dan ook) (1000Base-T links).

Gebruik deze configuratie:

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

of

Sluit de Windows host aan en stuur de gelabelde frames door, dan zouden ze het probleem moeten activeren. Bovendien, zorg ervoor dat de Netwerkinterfacekaart (NIC) het pakket kan taggen.

De switch voegt de niet-nulpadding toe aan de frames die doorlopen.

Bijvoorbeeld: Host — [Trunk] N9K [Trunk] — Host

U kunt het netwerk gebruiken om de pakketten te verzenden en ontvangen.

Zoals in de afbeelding wordt weergegeven, wordt zijkant (VLAN 100 met een label) en poort op e1/59 op de switch verzonden.

Het ontvangt Side (VLAN 100 met een label), poort e1/60 op de switch, zoals in de afbeelding weergegeven:

Zoals in de afbeelding wordt aangegeven, wordt het pakket verzonden.

Het pakket wordt ontvangen, zoals in de afbeelding te zien is:

Zoals in de afbeelding wordt de fout bij het toevoegen gemarkeerd.

Dit wordt ook weergegeven met een pakketanalyzer (in een ander pakket wijken de gegevens af van de vorige screenshots maar test en bug zijn identiek);

Oplossing

De tijdelijke oplossing is om de buffer-boost uit te schakelen op de interface waar we deze server hebben aangesloten.

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

Gerelateerde defect:

CSCva46849 60 bytes frame met dot1q head-end L2-switching op N9k