Diskussion:IEEE 802.1Q

Auswirkung der Tags auf maximale Frame-Länge

Wie in Ethernet#Datenframe auch steht, ist die maximale Frame-Länge durch VLAN-Tags größer geworden. Bekommt ältere Ethernet-Technik nicht Probleme, wenn durch das VLAN-Tag ein Ethernet-Frame die maximal erlaubten Länge überschreitet? Erst recht, wenn VLAN-Tags geschachtelt werden, wie es einige neueren Router/Switches machen, um mehr als 4094 VLANs zu unterstützen... --RokerHRO 10:11, 24. Feb. 2010 (CET)

Ältere Switches wertet das VLAN-Tag nicht aus, können in der Regel – da bei allen getaggten Paketen nach 802.1Q alle OSI Layer 2 Informationen ganz normal gesetzt sind und sich das Tag aus Layer-2-Sicht im Datenbereich befindet – aber trotzdem Pakete mit gesetzten VLAN-Tags weiterleiten. Im Datenframe wird dann ja die die Länge des "unsichtbaren" Tags beachtet.

Einfache und ältere Karten: Diese können, entweder auf Grund von Beschränkungen in der Hardware oder auf Grund fehlender Software, nicht mit VLAN-Tags umgehen; sie werden Pakete mit gesetzten VLAN-Tags verwerfen. Daher müssen diese Karten an 802.1Q-fähige Switches angeschlossen werden, welche Tags analysieren und bei Bedarf entfernen und einfügen können.

Und die erlaubte Gesamtlänge eines Frames wurde ja in Ethernet2 durch Änderung des EtherTypes auf 1522 Bytes verlängert. (nicht signierter Beitrag von 91.64.192.77 (Diskussion) 03:58, 17. Sep. 2014 (CEST))

TCI

Es fehlt Beschreibung TCI: Die Felder Priorität, CFI und VID bilden zusammen das Feld TCI (Tag Control Information) -- 91.53.160.243 09:16, 28. Okt. 2010 (CEST)

Literatur

Gleiche Frage wie in IEEE 802.1p: Sind das nur unterschiedliche Versionen? Dann würde es doch eigentlich Sinn machen, stattdesssen eine aktuelle zu verlinken. Zumal einer der drei Links nicht mehr verfügbar ist.

Würde ich dann bei Gegelenheit mal tun. --Noresoft (Diskussion) 17:09, 3. Mär. 2017 (CET)

erledigt. --Noresoft (Diskussion) 08:03, 6. Mär. 2017 (CET)

QinQ

Ich denke, hier muesste dringend zumindest irgendein Hinweis auf 802.3ad bzw. QinQ dazu, wo das aeussere VLAN einfach einen anderen Ethertype hat. Viele Linuxer meinen, dass das mit zwei gleichen Frametypen (also 'double tagging') gebaut wird, und mit einem Hinweis von hier waere das vielleicht leichter zu vermeiden. 93.104.185.42 02:32, 20. Dez. 2017 (CET)

Unklare Formulierung "DEI"

Zitat: "DEI – Drop Eligible Indicator: Kann separat oder in Verbindung mit PCP verwendet werden, um anzuzeigen, dass Frames in der Gegenwart von Staus fallen gelassen werden können". Bitte, was bedeutet "... in der Gegenwart von Staus ..."? (Hat das eine Maschine übersetzt??) 2001:7F0:400C:0:0:0:0:4 12:37, 22. Nov. 2018 (CET)

Typen von VLAN-Karten

Dieser Abschnitt muss komplett weg, denn die Karte (besser: der Chipsatz, die Schnittstelle - viele Ethernetschnittstellen sind heutzutage auf der Hauptplatine integriert) hat nichts mit VLAN-Tagging zu tun. Es gibt Chipsätze, die das mit intern erledigen können, wenn sie vom Betriebssystem entsprechend programmiert sind; ansonsten kann ein kundiges Betriebssystem das komplett in Software erledigen. Siehe z.B. die Manpage vlan(4) von NetBSD.

Die einzige Stelle, wo die Schnittstellen-Hardware ins Spiel kommt, ist, dass ggfls. innere Pakete nur bis zu einer Länge von 1496 Oktetten unterstützt werden können, wenn die Hardware maximal 1500 Oktette (Ethernet-Standard) erlaubt. --Nomentz (Diskussion) 18:31, 1. Mär. 2020 (CET)

In der Tat ist die Beschreibung des Umgangs einfacher Ethernet-Karten ohne Hardware-Support mit VLAN-Ethernet-Frames komplett falsch. Diese Frames werden nicht von der Karte verworfen, sondern vom Betriebssystem. Leider habe ich keine Idee, wie ich das belegen soll, ohne auf eigen Erfahrung oder die Quellen des Linux-Kernels zu verweisen. --CyDeFect (Diskussion) 19:43, 5. Mär. 2023 (CET)

Irreführendes Bild

Die Zuordnung der Type-Felder zum Ethernet-Header bzw. zum VLAN-Header ist nicht unbedingt falsch aber irreführend.

Das erste Type-Feld (Bytes 13:14) gehört nach wie vor zum Ethernet-Header. Dort steht gegebenenfalls Protokoll-Typ '0x8100' - das 802.1q-VLAN. Dieser verweist auf den anschließenden VLAN Header mit PCP/DEI/VID und Protokoll-Typ, der dann z.B. auf ein anschließendes IP-Protokoll '0x0800' verweist.

Das heißt, die Parserreihenfolge für ankommende Frames bleibt ganz normal ein Header nach dem anderen: Zuerst Ethernet-Header, dann VLAN-Header, dann IP-Header. --Wolfram256 (Diskussion) 10:43, 31. Mär. 2023 (CEST)