Diskussion:IEEE 802.1Q

message: 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)
thread_title:  Auswirkung der Tags auf maximale Frame-Länge 

message: 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)
thread_title:  TCI 

message: 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)
replies: text: erledigt. --Noresoft (Diskussion) 08:03, 6. Mär. 2017 (CET)
thread_title:  Literatur 

message: 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)
thread_title:  QinQ 

message: 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)
thread_title:  Unklare Formulierung "DEI" 

message: 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)
replies: text: 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)
thread_title:  Typen von VLAN-Karten 

message: 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)
thread_title:  Irreführendes Bild