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.