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
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.
Antworten:
Antworten auf individuelle Bedenken in der Post ...
In Bezug auf die Pfad-MTU-Erkennung
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 ...
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 ...
Wie sollte eine 802.3-kompatible Implementierung auf MTU-Fehlanpassungen reagieren?
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.
An dieser Stelle schwer zu sagen
802.1ad vs 802.1q
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.
quelle
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.
quelle