Fehlerbehebung beim beschädigten Ethernet-Paket auf dem Cisco Nexus 9000

Einführung

In diesem Dokument wird beschrieben, wie Sie das beschädigte Ethernet-Paket auf dem Cisco Nexus 9000 beheben, wenn eine Padding-Information beschädigt oder falsch gebildet wird.

Hintergrundinformationen

Die minimale Größe eines Ethernet-Frames beträgt 64 Byte, unabhängig davon, welches VLAN-Tag ist dort vorhanden sein oder nicht.

Die minimale Ethernet-Nutzlastgröße ist:

• 46 Byte, wenn das VLAN-Tag nicht vorhanden ist.
• 42 Byte, wenn das VLAN-Tag vorhanden ist.

Sie können Folgendes überprüfen:

• Auf Wikipedia, Abschnitt Payload: https://en.wikipedia.org/wiki/Ethernet_frame
• Beim IEEE 802.3-Standard (http://people.ee.duke.edu/~mbrooke/EE164.02/Spring_2004/group_2/index_files/8023.pdf)Hier wird das MAC-Frame-Format (ohne VLAN) in Abschnitt 3.1.1, Seite definiert. 39 und die Elemente eines markierten MAC-Frames sind in Abschnitt 3.5 auf Seite 43 definiert.

Die minimale Größe eines Ethernet-Pakets beträgt 64 Byte, unabhängig davon, ob ein VLAN-Header vorhanden ist oder nicht. Der Server darf ein 64-Byte-Paket mit einem VLAN senden, das Sie akzeptieren und korrekt verarbeiten sollten.

Hinweis:Dieses Verhalten wird von einem Catalyst 4500x richtig gehandhabt, nicht von Nexus 9000.

Wie wird ein Paket von einem Switch verarbeitet?

Schritt 1: Empfangen eines GÜLTIGEN 64-Byte-Ethernet-Frames.

Schritt 2: Entfernen Sie die Frame Check Sequence (FCS), sodass das Paket 60 Byte lang wird.

Schritt 3: Entfernen Sie das VLAN-Tag, sodass das Paket 56 Byte lang wird.

Schritt 4: Fügen Sie Padding hinzu, um das Paket 60 Byte lang zu machen.

Schritt 5: Durch das Hinzufügen des FCS wird das Paket 64 Byte lang.

Beim Durchstellen eines Pakets über den Cut-Through-Switch darf das Padding nicht geändert werden.

Mit getaggten VLANs geändertes Padding bei der Übertragung von Datenverkehr über N9K

Anstatt mit Nullen zu paddeln, wird das Paket mit Garbage-Zeichen gepaart. In den meisten Fällen hat es keine Auswirkungen, da Prüfsummen nicht geändert werden und daher keine dieser Daten verwendet wird. Wenn Kunden jedoch eine spezielle Verwendung haben und die Prüfsummen neu berechnen müssen, führen diese überflüssigen Daten letztendlich zu Beschädigungen der Prüfsummen (das Problem kann auch bei anderen Appliances wie NAT/Load Balancern auftreten)

Gerät ist ein N9K 93120TX (wurde ursprünglich auf einem 9372TX erkannt), Version ist neueste NXOS 7.0(3)I2(2a)

Hier Linux-Hosts mit direkt mit der N9K verbundener Hardware (keine Virtualisierung irgendeiner Art) verwenden (1000Base-T-Verbindungen)

Verwenden Sie diese Konfiguration:

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

oder

Schließen Sie einfach den Windows-Host an und senden Sie die getaggten Frames, sollten sie das Problem auslösen. Stellen Sie außerdem sicher, dass die Netzwerkkarte (NIC) das Paket kennzeichnen kann.

Switch fügt den durchlaufenden Frames das Padding von 0 (0) hinzu.

Beispiel: Host — [Trunk] N9K [Trunk] — Host

Sie können netcat zum Senden und Empfangen von Paketen verwenden.

Wie im Bild gezeigt, sendet er Side (VLAN 100 getaggt), Port e1/59 am Switch

Es empfängt Side (VLAN 100 markiert), Port e1/60 am Switch, wie im Bild gezeigt:

Wie im Bild gezeigt, wird das Paket übertragen.

Das Paket wird empfangen, wie im Bild gezeigt:

Wie im Bild gezeigt, wird das falsche Padding hervorgehoben.

Dies wird auch mit einem Paketanalyzer angezeigt (in einem anderen Paket unterscheiden sich die Daten von den vorherigen Screenshots, Test und Fehler sind jedoch identisch).

Lösung

Die Umgehungsarbeit besteht darin, Puffer-Boost auf der Schnittstelle deaktivieren, an der dieser Server angeschlossen ist.

C9396PX-1(config)# int et 1/7

C9396PX-1(config-if)# kein Buffer-Boost

Ähnlicher Fehler:

CSCva46849    60-Byte-Frame mit dot1q-Header L2-Switching auf N9k