Wie ist IEEE 802.1ad (auch bekannt als VLAN Tagging, QinQ) gültig, wenn die Pakete zu groß sind?


8

Vor kurzem habe ich mich mit MTU-Problemen befasst . Und alles scheint auf die Tatsache zurückzuführen zu sein, dass der Ethernet-Adapter auf neueren Computern standardmäßig eine Frame-Größe von 1504 Byte hat:

>netsh interface ipv4 show subinterfaces

   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  1504                1  3954161316  804790885  Local Area Connection

Laut einer zufälligen Person auf NetworkEngineering.stackexchange.com wird nun jedes zu große Paket von jeder empfangenden Network Interface Card (NIC) verworfen, da das Ethernet-Paket zu groß ist:

... jeder Frame mit einer MTU größer als die 802.3-Spezifikation von 1500

Ein Frame, der größer als das festgelegte Maximum ist, wird von der Netzwerkkarte gelöscht - es ist ein Fehler, und das Betriebssystem wird nie davon erfahren. (Ein übergroßer Frame-Zähler klickt auf, aber das ist alles.)

Dies führt zu Problemen, wenn der Computer versucht, Pakete an den Gateway-Computer zu senden. Idealerweise würde ich mich auf die Entdeckung von Path MTU verlassen . Da die generierten Ethernet-Pakete jedoch zu groß sind, als dass ein anderer Computer sie empfangen könnte, besteht keine Möglichkeit, dass zu große Fragmentierungsnachrichten für IP- Pakete zurückgegeben werden:

Es wird überhaupt keine "Fragmentierung" geben. Schicht-2 (Ethernet) hat keine Mittel, wenn "Fragmentierung erforderlich" angezeigt wird. Dies wird auf Layer-3 (IP) von Routern herausgefunden, die eine ICMP-Nachricht senden, wenn sie das Paket verwerfen müssen, da es nicht auf die Next-Hop-Schnittstelle passt.

Was mich zuerst zu meiner zweiten Frage bringt:

  • Warum gibt es eine Spezifikation, die absichtlich ungültige Ethernet-Frames erstellt? Was ist das beabsichtigte Verhalten hier? Was erwarteten sie, da andere Netzwerkkarten diese neuen Pakete mit Standardgröße nicht empfangen können?

Dies bringt mich dann zu meiner ersten zweiten Frage. Und das wurde schon oft gefragt.

  • Ist das 4-Byte-QinQ-Tag Teil des Ethernet-Frame-Headers oder Teil der Ethernet-Nutzdaten? Wenn es Teil des Headers ist, warum wurde der Nutzlastkörper um 4 Byte erhöht? Wenn es Teil der Ethernet-Nutzlast ist, warum erhöht sich die Nutzlast-MTU um 4 Byte (wenn wir wissen, dass eine Erhöhung um 4 Byte es zu einem ungültigen Paket macht)?

Die größere Frage ist ...

Wenn wir einen Moment zurücktreten, haben wir die größere Frage:

Was sollen wir tun?

Es muss Leute gegeben haben, die diesen Standard entworfen haben. Was erwarteten die Leute von Geräten, die diese zu großen Pakete erzeugen ?

Ich frage wirklich. Ich nehme an, wir sollten nicht zu jedem Hardwaregerät gehen und die Erhöhung der MTU 1504 rückgängig machen und auf 1500 zurücksetzen:

netsh interface ipv4>set subinterface "Local Area Connection" mtu=1500 store=persistent
Ok.

Das wäre (und ist) ein Konfigurations-Albtraum.

Ist die Idee vielleicht, das VLAN-Tagging zu deaktivieren? Abgesehen vom Konfigurations-Albtraum funktioniert es einfach nicht:

  • Schritt 1: Deaktivieren Sie das VLAN-Tagging

    Geben Sie hier die Bildbeschreibung ein

  • Schritt 2: Beachten Sie, dass es nicht funktioniert:

    netsh interface ipv4 zeigt Subschnittstellen

     MTU  MediaSenseState   Bytes In  Bytes Out  Interface
    

    1504                1     238125     245855  Local Area Connection
    

Wenn die Lösung hierfür darin besteht, alle Netzwerkkarten manuell auf eine MTU von 1500 zurückzusetzen, warum haben sie sie dann überhaupt auf 1504 Byte erhöht und ungültige Pakete erstellt?

Es gibt einen Teil des Puzzles, den ich vermisse.

Bonus Chatter

 Without 802.1Q tagging        Without 802.1Q tagging   
+------------------------+    +------------------------+
|Destination MAC: 6 bytes|    |Destination MAC: 6 bytes|
|Source MAC: 6 bytes     |    |Source MAC: 6 bytes     |
|Ethertype: 2 bytes      |    |802.1Q tag: 4 bytes     |
+------------------------+    |Ethertype: 2 bytes      |
|                        |    +------------------------+
|                        |    |                        |
/ Payload: 1500 bytes    /    / Payload: 1500 bytes    /
|                        |    |                        |
|                        |    |                        |
+------------------------+    |                        |
| Frame Check Sequence:  |    +------------------------+
|                 4 bytes|    | Frame Check Sequence:  |
+------------------------+    |                 4 bytes|
                              +------------------------+

Netzwerkdiagramm

+------------------+      +----------------+     +------------------+
| Realtek PCIe GBe |      | NetGear 10/100 |     | Realtek 10/100   |
|       (on-board) |      |     Switch     |     |     (on-board)   |
|                  |      +----------------+     |                  |
| Windows 7        |           ^    ^            |                  |
|                  |           |    |            |                  |
| 192.168.1.98/24  |-----------+    +------------| 192.168.1.10/24  |
| MTU = 1504 bytes |                             | MTU = 1500 bytes |
+------------------+                             +------------------+

Sie können auch eine beliebige Konfiguration ersetzen und Pakete generieren, die größer als die maximal zulässigen 1500Bytes sind:

+------------------+      +----------------+     +------------------+
| Realtek PCIe GBe |      | NetGear 10/100 |     | Realtek 10/100   |
|       (on-board) |      |     Switch     |     |     (on-board)   |
|                  |      +----------------+     |                  |
| Windows 7        |           ^    ^            | MTU = 1500 bytes |
| MTU = 16384bytes |           |    |            |                  |
|                  |-----------+    +------------|                  |
+------------------+                             +------------------+

Ich versuche, eine Site zu finden, die möglicherweise mein technisches, konzeptionelles, logisches, grundlegendes und theoretisches Problem der Funktionsweise von Ethernet lösen kann, wenn einige Geräte absichtlich ungültige Pakete generieren.

Das Problem tritt auf, wenn ich versuche, ein ungültiges Ethernet-Paket an ein anderes Ethernet-Gerät zu senden:

  • Computer generiert Ethernet-Paket

    Source MAC:      xx-xx-xx-xx-xx-xx
    Destination MAC: yy-yy-yy-yy-yy-yy
    Ethertype:       0x0800
    Payload:         ...1504 bytes...  (or could be ...16384 bytes, anything larger than 1500...)
    CRC:             4 bytes                
    

Dieses Paket ist ungültig, da es zu groß ist, um vom 802.3u-Zielgerät empfangen zu werden. Da das Host-Betriebssystem des Ziels das Paket nie sieht und Ethernet keine Funktion zum Melden ungültiger Pakete an den Absender hat, geht das "große" Paket verloren.

Bonus Chatter

Aus dem Inter-Switch Link- und IEEE 802.1Q-Frame-Format von Cisco :

Rahmengröße

Die standardmäßige maximale Übertragungseinheit (MTU) einer Schnittstelle beträgt 1500 Byte. Wenn ein äußeres VLAN-Tag an einen Ethernet-Frame angeschlossen ist, erhöht sich die Paketgröße um 4 Byte. Daher ist es ratsam, die MTU jeder Schnittstelle im Anbieternetzwerk entsprechend zu erhöhen. Die empfohlene Mindest-MTU beträgt 1504 Byte.

Inzwischen:

Der IEEE 802.3-Ethernet-Standard schreibt nur die Unterstützung von 1500-Byte-MTU-Frames vor.


3
Dies ist ein Problem für Netzwerkkarten (die über Firmware verfügen), die dot1q (ethertype == 0x8100) nicht unterstützen. Ich denke, Sie sehen einen Windows-Fehler / Artefakt / was auch immer erforderlich ist, um die zusätzlichen Bytes im Frame zu verarbeiten - normalerweise Die IP-Nutzlast-MTU ändert sich nicht, aber der Treiber weist die Hardware an, mehr Daten zu akzeptieren.
Ricky Beam

Ian, obwohl es sicher so aussieht, als ob Sie hier auf Probleme stoßen, haben Sie einige fragwürdige beschreibende Annahmen in dem Beitrag ... SE-Kommentare sind einschränkend, aber ich fange von oben an: RE: "Es gibt keine Gelegenheit für IP-Paket zu große Fragmentierungsnachrichten, die zurückgegeben werden sollen " <- sieht falsch aus, es sei denn, Sie führen reine Nicht-IP-Dienste (wie FCoE) aus. Da diese erste Aussage Ihre erste Frage antreibt ( Warum gibt es eine Spezifikation, die absichtlich ungültige Ethernet-Frames erstellt? ), Bin ich geneigt, nach weiteren Details zu fragen . Wir brauchen Topologie / Diagramm usw.
Mike Pennington

Fügen Sie Details zu den Geräten im Pfad hinzu, fassen Sie die Vlan / IP-Konfigurationsdetails zusammen und geben Sie spezifische MTU-Informationen für alle Ethernet-Links an. Wir müssen auch die Hersteller- / Modellnummern der relevanten Netzwerkgeräte kennen (einschließlich NICs). Geben Sie auch Ihre bisher durchgeführten Schritte zur Fehlerbehebung sowie die Ausgabe aller von Ihnen durchgeführten Sniffer-Erfassungen an. Wenn Sie weitere Informationen benötigen, wenden Sie sich bitte an Network Engineering Meta oder an den NE-Chat
Mike Pennington,

@MikePennington "Es gibt keine Möglichkeit, dass IP-Paket zu große Fragmentierungsnachrichten zurückgegeben werden" ergibt sich aus dem Problem, dass ein fehlerhaftes Ethernet-Paket niemals auf dem TCP / IP-Stapel des Betriebssystems ankommt. Wenn IP das Paket nie empfängt, hat es keine Möglichkeit, mit irgendeiner Form von ICMP-Typ-3-Paket zu antworten.
Ian Boyd

Bis ich die Karte sah, hatte ich keine Möglichkeit, dies zu bestätigen. Bitte haben Sie Verständnis dafür, dass viele Leute mit Missverständnissen über Netzwerke hierher kommen und wir entschlüsseln müssen, was sie wirklich gegen die Realität sagen wollen. Ich habe Eingaben, die helfen könnten; Ich muss mich jedoch mit anderen Problemen aus dem wirklichen Leben befassen, bevor ich antworten kann
Mike Pennington,

Antworten:


6

Antworten auf individuelle Bedenken in der Post ...

In Bezug auf die Pfad-MTU-Erkennung

Idealerweise würde ich mich auf die Entdeckung von Path MTU verlassen. Da die generierten Ethernet-Pakete jedoch zu groß sind, um von einem anderen Computer empfangen zu werden, besteht keine Möglichkeit, dass zu große Fragmentierungsnachrichten für IP-Pakete zurückgegeben werden

Aufgrund Ihres Diagramms stimme ich zu, dass PMTUD nicht zwischen zwei verschiedenen PCs im selben LAN-Segment funktionieren kann. PCs generieren keine ICMP-Fehlermeldungen, die von PMTUD benötigt werden .

Jumbo-Rahmen

Einige Anbieter (z. B. Cisco) verfügen über Switch-Modelle, die Ethernet-Nutzdaten mit mehr als 1500 Byte unterstützen. Offiziell unterstützt IEEE diese Konfiguration nicht , aber die Branche hat berechtigte Bedürfnisse, um vernünftig von der ursprünglichen 1500-Byte-MTU abzuweichen. Ich habe Speicher-LAN / Backup-Netzwerke, die aus gutem Grund Jumbo-Frames nutzen. Ich habe jedoch sichergestellt, dass alle MTUs innerhalb desselben VLAN übereinstimmen, als ich Jumbo-Frames bereitgestellt habe.

Nicht übereinstimmende MTUs innerhalb einer Broadcast-Domäne

Das Fazit ist, dass Sie niemals nicht übereinstimmende Ethernet-MTUs innerhalb derselben Ethernet-Broadcast-Domäne haben sollten. Wenn Sie dies tun, liegt ein Fehler oder ein Konfigurationsfehler vor. Unabhängig von Fehlern oder Irrtümern müssen Sie diese Probleme manchmal manuell lösen.

All diese Diskussionen führen zur nächsten Frage ...

Warum gibt es eine Spezifikation, die absichtlich ungültige Ethernet-Frames erstellt?

Ich bin mir nicht sicher, ob ich damit einverstanden bin ... Ich sehe nicht, wie die IEEE 802.3-Serie oder RFC 894 ungültige Frames erstellen. Host-Implementierungen oder Host-Fehlkonfigurationen erzeugen ungültige Frames. Um zu verstehen, ob Ihre Implementierung der Spezifikation entspricht, benötigen wir viel mehr Beweise ...

Dieses Diagramm ist zumindest ein Anscheinsbeweis dafür, dass Ihre MTUs innerhalb einer Broadcast-Domäne nicht übereinstimmen ...

+------------------+      +----------------+     +------------------+
| Realtek PCIe GBe |      | NetGear 10/100 |     | Realtek 10/100   |
|       (on-board) |      |     Switch     |     |     (on-board)   |
|                  |      +----------------+     |                  |
| Windows 7        |           ^    ^            |                  |
|                  |           |    |            |                  |
| 192.168.1.98/24  |-----------+    +------------| 192.168.1.10/24  |
| MTU = 1504 bytes |                             | MTU = 1500 bytes |
+------------------+                             +------------------+

Wie sollte eine 802.3-kompatible Implementierung auf MTU-Fehlanpassungen reagieren?

Was erwarteten sie [die Verfasser der Spezifikation] von den Geräten, die diese zu großen Pakete erzeugen?

MTU 1504 und MTU 1500 innerhalb derselben Broadcast-Domäne sind einfach eine Fehlkonfiguration. Es sollte niemals erwartet werden, dass es nicht mehr als nicht übereinstimmende IP-Netzmasken funktioniert, oder es kann erwartet werden, dass nicht übereinstimmende IP-Subnetze funktionieren. Ihr Unternehmen muss die Grundursache für die MTU-Fehlanpassungen ermitteln und beheben. Derzeit ist schwer zu sagen, ob die Grundursache ein Benutzerfehler, ein Implementierungsfehler oder eine Kombination der oben genannten Ursachen ist.

Wenn sich die betroffenen Windows-Computer erfolgreich bei einer Active Directory-Domäne anmelden, können Windows-Anmeldeskripts geschrieben werden, um MTU-Probleme basierend auf einigen gut konstruierten Tests in den Domänenanmeldeskripten automatisch zu beheben (vorausgesetzt, der Domänencontroller ist nicht Teil der MTU Probleme).

Wenn sich die Computer nicht bei einer Domäne anmelden, ist Handarbeit eine weitere Option.

Andere Möglichkeiten, den Schaden einzudämmen

Verwenden Sie einen Layer3-Switch. Hinweis 1 , um ein benutzerdefiniertes VLAN für alle fehlerhaften MTUs zu erstellen und die Ethernet-MTU des Layer3-Switches so einzustellen, dass sie mit den defekten Maschinen übereinstimmt. Dies beruht auf PMTUD , um MTU-Probleme auf der IP-Ebene zu lösen. Layer3-Switches erzeugen die für PMTUD erforderlichen ICMP-Fehler .

Diese Option funktioniert am besten, wenn Sie die defekten Computer mit DHCP neu adressieren können. und Sie können die defekten Maschinen anhand der Mac-Adresse identifizieren.

... warum haben sie es überhaupt auf 1504 Bytes erhöht und ungültige Pakete erstellt?

An dieser Stelle schwer zu sagen

802.1ad vs 802.1q

Wie ist IEEE 802.1ad (auch bekannt als VLAN Tagging, QinQ) gültig, wenn die Pakete zu groß sind?

Ich habe bisher keine Beweise dafür gesehen, dass Sie QinQ verwenden . aus den begrenzten Beweisen , die ich bisher gesehen habe, sind Sie einfach mit 802.1q - Kapselung, die sollte korrekt in Windows arbeiten, die NIC - Treiber unterstützt unter der Annahme , 802.1q encap.


End Notes :

Hinweis 1 Jeder Layer 3-Switch sollte ... Cisco, Juniper und Brocades können alle diese Art von Funktion ausführen.


2

Ich kann versuchen, Ihre konzeptionelle Frage zu beantworten.

Ich kann kein tatsächliches Angebot finden, aber es scheint ziemlich klar zu sein, dass .1ad und .1q niemals von PCs oder anderen Endhosts verarbeitet werden sollten. Sie werden (normalerweise) nur von Infrastrukturgeräten verarbeitet. Ich weiß nicht, was die Designer dachten, aber es ist schwer vorstellbar, dass QinQ-Pakete in einem realen Szenario an einen PC gesendet werden. Ethernet-Schnittstellen an Infrastrukturgeräten (Routen, Switches usw.) können größere Pakete verarbeiten.

Die Pakete sind also nur für PCs ungültig, die sie theoretisch niemals sehen sollten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.