Warum gibt es PVID bei VLANs?
Hallo,
warum gibt es bei einigen Switchen eigentlich PVID für VLANs?
Eigentlich müßte dies doch schon mit dem Untagged festgelegt sein.
Und mehr als ein untagged Eintrag dürfte es für einen Port doch eh nicht geben.
Ist das nur weil die Switchhersteller zu faul sind eine Überprüfung einzubauen?
Viele Grüße
Stefan
warum gibt es bei einigen Switchen eigentlich PVID für VLANs?
Eigentlich müßte dies doch schon mit dem Untagged festgelegt sein.
Und mehr als ein untagged Eintrag dürfte es für einen Port doch eh nicht geben.
Ist das nur weil die Switchhersteller zu faul sind eine Überprüfung einzubauen?
Viele Grüße
Stefan
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 325880
Url: https://administrator.de/forum/warum-gibt-es-pvid-bei-vlans-325880.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
16 Kommentare
Neuester Kommentar
Hallo,
PVID vs VLAN
- VLAN is a broadcast domain
- PVID (Port VLAN ID) is a default VLAN id assigned to frames coming to the port. This is a term used for non-Cisco switches.
<code >Example 1.
interface fa0/1
switchport mode access
switchport access vlan 10
switchport voice vlan 20
switchport trunk native vlan 30
Here PVID is 10, as untagged frames will get into VLAN 10
Here PVID is 30, as untagged frames will get into VLAN 30
Gruß
Dobby
PVID vs VLAN
- VLAN is a broadcast domain
- PVID (Port VLAN ID) is a default VLAN id assigned to frames coming to the port. This is a term used for non-Cisco switches.
<code >Example 1.
interface fa0/1
switchport mode access
switchport access vlan 10
switchport voice vlan 20
switchport trunk native vlan 30
Here PVID is 10, as untagged frames will get into VLAN 10
Example 2.
interface fa0/2
switchport mode trunk
switchport access vlan 10
switchport voice vlan 20
switchport trunk native vlan 30
Here PVID is 30, as untagged frames will get into VLAN 30
Gruß
Dobby
Eigentlich müßte dies doch schon mit dem Untagged festgelegt sein.
Eigentlich ja und es ist vollkommen überflüssig das bei Port based VLANs immer noch extra zu machen. Da hast du Recht.Die PVID bestimmt das VLAN in das untagged Frames geforwardet werden die an dem Port reinkommen.
Der IEEE 802.1q Standard definiert das nicht voll aus, was mit untagged Paketen passieren soll an so einem tagged Trunk/Uplink Port. Viele Hersteller droppen solche Frames auch an tagged Ports. Beides ist möglich und aus .1q Standad Sicht richtig, nur es bleibt letztlich Herstellern überlassen wie sie das konfigtechnisch handhaben und implementieren.
PVID heisst bei anderen Herstellern "Native Vlan" oder auch "dual Mode VLAN". Es ist aber immer das gleiche und bestimmt WO in welches VLAN UNgetaggte Pakete also solche OHNE ein VLAN Tag an diesem Port geforwardet werden. (Siehe dazu auch VLAN Schnellschulung!)
Normal ist es so, und auch logisch, das wenn du ein Port untagged einem VLAN zuweist, die PVID natürlich logischerweise auch dieser VLAN ID entspricht. Bei Premium Herstellern ist das immer so und man muss es explizit umstellen will man dies nicht. (Auto-PVID)
Die meisten der üblichen Billigherstellern supporten kein Auto-PVID und es ist so das du die PVID immer noch extra setzen musst, weil sie sonst immer fest auf dem Default PVID Wert 1 (Default VLAN 1) verbleibt.
Konfigtechnischer Blödsinn aber vermutlich ist das mit der Firmware Implementierung einfacher und das sich wieder ein paar Cent im Massenmarkt damit sparen lassen.
Das dieses Verhalten die meisten VLAN Anfänger mit ihren Konfigurationen damit häufig überfordert spielt da keinerlei Rolle ! Wie immer, leider...
Aber wer im Billigsektor kauft weiss das ja auch... (hoffentlich ?!).
Dort wird die PVID automatisch konfiguriert.
Wie es bei "intelligenten" Switches auch durch die Bank üblich ist Aber es hat mich bei Switchen von HP und Zyxel schon die eine oder andere Gehirnzelle gekostet deren Logik zu druchblicken.
Nicht nur dir... Lieder mit dem Effekt das eben Anfänger über sowas stolpern und viele Frustrationserlebnisse haben.Ein ganz böser Vertreter ist da auch NetGear. Deshalb der besondere Hinweis im hiesigen VLAN Tutorial zu dieser unsäglichen PVID Problematik.
Ganz korrekt müssten deine Leitsätze aber so lauten:
Untagged Port eingehend: Die VLAN-Markierung wird laut PVID (häufig identlichen mit der untagged VLAN ID) intern im Switch hinzugefügt
Untagged Port ausgehend: Die VLAN-Markierung wird überprüft und beim Versenden entfernt
Ein untagged Frame extern bzw. auf dem Netz hat ja generell überhaupt keine .1q VLAN Markierung. Diese Switches fügen sie intern im ASIC automatisch nach PVID hinzu rein zur internen Verarbeitung (und NUR zu der).
Weil es der Standard so definiert und die sich dabei etwas gedacht haben.
Eine Fehlannahme die zeigt, dass Du nicht hinreichend zwischen ingress und egress unterscheidest und nur Deine einfachen Konfigurationen vor Augen hast.
Zitat von @StefanKittel:
Und mehr als ein untagged Eintrag dürfte es für einen Port doch eh nicht geben.
Und mehr als ein untagged Eintrag dürfte es für einen Port doch eh nicht geben.
Ingress ist dies zwangsläufig so, aber egress gibt es durchaus Szenarien, bei denen es sehrwohl erforderlich ist, den Traffic mehrerer VLANs untagged auszugeben.
Der wichtigste Anwendungsfall sind sog. asymmetrische VLANs. Leider sind meine diesbezüglichen Links mittlerweile verwaist. Letzlich ist es aber nichts anderes, als das, was Cisco unter CatOS und IOS-basierenden Switches "(community) private vlan" nennt. Also Ports oder Gruppen von Ports gegeneinander zu isolieren, die dennoch auf gemeinsame Ressorcen zugreifen können, ohne dass ein Layer3-Routing erforderlich wäre. Und zwar wenn nötig auch Switch-übergreifend! Siehe https://www.it-bildungsnetz.de/fileadmin/media/Akademietag_2012/Private% ...
Technisch läuft das so ab, dass der Antworttraffic in einem anderen VLAN zurück kommt, als die Anfragen.
Zitat von @StefanKittel:
Ist das nur weil die Switchhersteller zu faul sind eine Überprüfung einzubauen?
Ist das nur weil die Switchhersteller zu faul sind eine Überprüfung einzubauen?
Es ist ja nicht nur das. Wenn man Auto-PVID hart implementiert, nimmt man dem Admin damit auch Konfigurationsmöglichkeiten, die der Standard bewusst zulassen wollte (s.o.). Ergo muss man dies abschaltbar oder anderweitig konfigurierbar programmieren - sonst wird aus einem Komfortfeature eine Funktionslimitierung.
Zitat von @StefanKittel:
Ich habe meist mit Cisco SG200/300 zu tun sowie D-Link 3120.
Dort wird die PVID automatisch konfiguriert.
Ich habe meist mit Cisco SG200/300 zu tun sowie D-Link 3120.
Dort wird die PVID automatisch konfiguriert.
Per Default ja. Bei beiden lässt sich Auto-PVID jedoch auch abschalten.
Bei DLink heisst der Punkt in der Web-GUI schlicht "asymmetric VLAN".
Ciscos SG-Serie stammt eigentlich von Linksys und ist nur nachträglich auf die Cisco-Logik/Terminologie umgestellt/ergänzt worden. Stellt man den Portmode auf "general", kann dieser auch in mehreren VLANs (egress) untaggt Member sein. Siehe http://sbkb.cisco.com/CiscoSB/GetArticle.aspx?docid=07e54124d9be46b48d6 ...
Zitat von @StefanKittel:
Aber es hat mich bei Switchen von HP und Zyxel schon die eine oder andere Gehirnzelle gekostet deren Logik zu druchblicken.
Aber es hat mich bei Switchen von HP und Zyxel schon die eine oder andere Gehirnzelle gekostet deren Logik zu druchblicken.
Bei HP kenne ich das nicht. Sowohl bei der ehemaligen Procurve-Serie als auch bei der A-Serie (ehem. H3C) ist Auto-PVID per Default an.
Bei ZyXEL, Netgear, TP-Link, Enterasys und vielen anderen gibt es das halt nicht. Wäre ich so anmaßend, wie manch Wortführer hier gelegentlich auftritt, würde ich sagen, dass diese Hersteller halt voraussetzen, dass ihre Geräte von Profis bedient werden - anstatt von Amateuren. Aber so bin ich ja nicht. Ich kann durchaus nachvollziehen, dass es ein wünschenswertes Komfortfeature ist. In 99 Prozent der Anwendungsfälle erleichtert es die tägliche Arbeit enorm. Auch erleichtert es Anfängern sicherlich den Einstieg. Andererseits führt es aber eben auch dazu, dass selbsternannte oder gefühlte "alte Hasen" doch nicht wirklich verstehen, wie die Technik im Detail funktioniert...
Gruß
sk
Das verstehen sie schon ,allerdings kann man das bei Anfängern erheblich kritischer sehen. Viele wissen mit diesen Begriffen nichts anzufangen geschweige denn können sie die Technik verstehen, das im Asic oder Fabric intern auch mit Taggs und Klassifizierungen gearbeitet wird für eine Forwarding Entscheidung.
Insofern wäre das Auto PVID Feature jedenfalls für solche Clientel eine erhebliche Erleichterung als das bei jedem Port einzeln definieren zu müssen. Die Zielgruppe von einfachen Web Smart Switches sind eben nicht immer Profis (oder solche die sich so bezeichnen)
Aber wie immer im Leben ist das relativ und Ansichtssache.
Insofern wäre das Auto PVID Feature jedenfalls für solche Clientel eine erhebliche Erleichterung als das bei jedem Port einzeln definieren zu müssen. Die Zielgruppe von einfachen Web Smart Switches sind eben nicht immer Profis (oder solche die sich so bezeichnen)
Aber wie immer im Leben ist das relativ und Ansichtssache.
Hallo zusammen,
sorry für das Ausgraben des Threads - aber ich befasse mich jetzt schon ne Weile mit dem Thema und habe noch Verständnisprobleme. Hauptsächlich frage ich mich (wie der Threadersteller), ob tatsächlich ein Szenario existiert, bei
ein Port im UNTAG-Modus arbeitet und die VID/VLAN-ID ungleich der PVID ist.
Mir ist schon klar, dass bspw. bei Ports im TAG-Modus die frei konfigurierbare PVID Sinn macht (bestes Beispiel: VoIP,
mit Trunk-Port, Telefone mit integriertem Switch und Rechner am Telefonswitch). Aber bei Ports im UNTAG-Modus?
Hier wurden ja asymmetrische VLANs als Anwendungsfall angesprochen (@sk). Deswegen habe ich in diese Richtung recherchiert und bin auf die Seite https://evilttl.com/wiki/Asymmetric-VLAN
gestoßen. Dort gibt es ein recht anschauliches Beispiel. ABER: Auch dort sind die Ports im UNTAG-Modus so konfiguriert,
dass VID=PVID gilt. Anders würde es mMn auch keinen Sinn machen.
Vielleicht könnt ihr mich hier ein wenig erleuchten? ^^
Gruß
apoth1
sorry für das Ausgraben des Threads - aber ich befasse mich jetzt schon ne Weile mit dem Thema und habe noch Verständnisprobleme. Hauptsächlich frage ich mich (wie der Threadersteller), ob tatsächlich ein Szenario existiert, bei
ein Port im UNTAG-Modus arbeitet und die VID/VLAN-ID ungleich der PVID ist.
Mir ist schon klar, dass bspw. bei Ports im TAG-Modus die frei konfigurierbare PVID Sinn macht (bestes Beispiel: VoIP,
mit Trunk-Port, Telefone mit integriertem Switch und Rechner am Telefonswitch). Aber bei Ports im UNTAG-Modus?
Hier wurden ja asymmetrische VLANs als Anwendungsfall angesprochen (@sk). Deswegen habe ich in diese Richtung recherchiert und bin auf die Seite https://evilttl.com/wiki/Asymmetric-VLAN
gestoßen. Dort gibt es ein recht anschauliches Beispiel. ABER: Auch dort sind die Ports im UNTAG-Modus so konfiguriert,
dass VID=PVID gilt. Anders würde es mMn auch keinen Sinn machen.
Vielleicht könnt ihr mich hier ein wenig erleuchten? ^^
Gruß
apoth1
Hallo,
Das stimmt nicht. Schau Dir Dein verlinktes Beispiel nochmal an - und zwar den Teil von Anfang bis zum ersten Bild und die zwei Sätze darunter.
Alles ab "VLANs between Cisco 3560 and Allied Telesys AT-GS950" bitte erstmal ignorieren, denn das was der Verfasser uns da sagen will, habe ich mangels Zeit auch noch nicht nachvollziehen können - bin gerade mitten in einem abendlichen Migrationsprojekt...
In dem verlinkten Beispiel sind
- die Ports 1 und 2 (egress) untagged Member in den VLANs 1 und 3
- die Ports 4 und 5 (egress) untagged Member in den VLANs 2 und 3
- der Port 3 (egress) untagged Member in den VLANs 1, 2 und 3
Also nochmal deutlich zum mitschreiben: der selbe Port ist zur gleichen Zeit Mitglied in mehreren VLANs, welche alle ausgehend untagged auf den Draht geschickt werden.
Im Übrigen gibt auch Szenarien, in denen mehrere VLANs nicht nur ausgehend untagged auf den gleichen Port ausgegeben werden, sondern auch eingehender Traffic trotz fehlender Kennzeichnung des Frames in unterschiedlichen VLANs landet. Beispielsweise bei protocol based VLANs.
Gruß
sk
Zitat von @apoth1:
Hier wurden ja asymmetrische VLANs als Anwendungsfall angesprochen (@sk). Deswegen habe ich in diese Richtung recherchiert und bin auf die Seite https://evilttl.com/wiki/Asymmetric-VLAN
gestoßen. Dort gibt es ein recht anschauliches Beispiel. ABER: Auch dort sind die Ports im UNTAG-Modus so konfiguriert,
dass VID=PVID gilt.
Hier wurden ja asymmetrische VLANs als Anwendungsfall angesprochen (@sk). Deswegen habe ich in diese Richtung recherchiert und bin auf die Seite https://evilttl.com/wiki/Asymmetric-VLAN
gestoßen. Dort gibt es ein recht anschauliches Beispiel. ABER: Auch dort sind die Ports im UNTAG-Modus so konfiguriert,
dass VID=PVID gilt.
Das stimmt nicht. Schau Dir Dein verlinktes Beispiel nochmal an - und zwar den Teil von Anfang bis zum ersten Bild und die zwei Sätze darunter.
Alles ab "VLANs between Cisco 3560 and Allied Telesys AT-GS950" bitte erstmal ignorieren, denn das was der Verfasser uns da sagen will, habe ich mangels Zeit auch noch nicht nachvollziehen können - bin gerade mitten in einem abendlichen Migrationsprojekt...
In dem verlinkten Beispiel sind
- die Ports 1 und 2 (egress) untagged Member in den VLANs 1 und 3
- die Ports 4 und 5 (egress) untagged Member in den VLANs 2 und 3
- der Port 3 (egress) untagged Member in den VLANs 1, 2 und 3
Also nochmal deutlich zum mitschreiben: der selbe Port ist zur gleichen Zeit Mitglied in mehreren VLANs, welche alle ausgehend untagged auf den Draht geschickt werden.
Im Übrigen gibt auch Szenarien, in denen mehrere VLANs nicht nur ausgehend untagged auf den gleichen Port ausgegeben werden, sondern auch eingehender Traffic trotz fehlender Kennzeichnung des Frames in unterschiedlichen VLANs landet. Beispielsweise bei protocol based VLANs.
Gruß
sk
Hallo sk,
danke für die prompte Antwort. Bin jetzt das Beispiel nochmal durchgegangen. Unter dem ersten Bild steht folgende Erläuterung (ich weiß nicht, ob ich das Bild hier posten darf, deshalb nur der Text):
The logic behind this is the following – any frames received on ports 1-2 will be marked with 1 and will be in the same broadcast domain with ports 1-2 and 3. Any frames received on ports 4-5 will be marked 2 and will be in the same broadcast domain with ports 4-5 and 3. Any frames received on port 3 will be marked with 3 and will be in the same broadcast domain with ports 1-2 and 4-5.
Ich bin jetzt mal so frei und spiele ein fiktives Szenario durch:
__________________________________________________________________________________________________________
Soweit so gut - allerdings macht es mMn bei dem Beispiel keinen Sinn eine andere PVID als die VID/VLAN-ID zu vergeben. Würde man das tun, wäre das eher kontraproduktiv und die beschriebene Konfiguration wurde nicht mehr funktionieren.
Um jetzt zur Ausgangsfrage zurückzukommen:
Existiert ein Szenario bei dem ein Port im UNTAG-Modus arbeitet und die VID/VLAN-ID ungleich der PVID ist? Bzw. warum ist die PVID frei konfigurierbar und nicht automatisch im UNTAG-Modus PVID=VID?
(Wie gesagt beim dem VoIP-Fall mit dem internen Switch des Telefons ist mir das klar. Aber dort arbeitet der Port am Switch im TAGGED-Modus.)
Mit deinem Hinweis @sk
wirds heller bei mir .
Klar, wenn ich einen Port für Protocol-based VLAN konfiguriere und festlege, dass bspw. IPv4 Traffic ins vlan 10 und IPv6 Traffic ins vlan 15 packe, dann muss der entsprechende port des switches member von vlan 10 und vlan 15 sein.
Geht dieser Traffic UNTAGED beim Switch ein (INGRESS), wird hier geprüft, ob der Frame/das Packet IPv4/IPv6 ist. Dann versieht er es (intern) mit dem entsprechenden Tag. Ist es aber etwas anderes (ICMP etc.) dann MUSS er das auch markieren (Internally in the switch, all VLANs are tagged)
Und hier nimmt der dann die PVID, die ich konfiguriert habe und die wird halt in den nicht die eine der VLAN-IDs oben (10, 15) sein sondern eine andere (damit dieser ICMP-Traffic eben nicht in VLAN 10, 15 landet).
Das ist dann ein Szenario wo bei einem Port im UNTAG-Modus nicht gilt PVID = VID und wo man (sofern man sie hat) die Auto-PVID-Funktion abschaltet und selbst Hand anlegt.
So jetzt genug Verwirrung gestiftet...
danke für die prompte Antwort. Bin jetzt das Beispiel nochmal durchgegangen. Unter dem ersten Bild steht folgende Erläuterung (ich weiß nicht, ob ich das Bild hier posten darf, deshalb nur der Text):
The logic behind this is the following – any frames received on ports 1-2 will be marked with 1 and will be in the same broadcast domain with ports 1-2 and 3. Any frames received on ports 4-5 will be marked 2 and will be in the same broadcast domain with ports 4-5 and 3. Any frames received on port 3 will be marked with 3 and will be in the same broadcast domain with ports 1-2 and 4-5.
Ich bin jetzt mal so frei und spiele ein fiktives Szenario durch:
__________________________________________________________________________________________________________
- Einer der PCs aus dem VLAN 1 (der linke an Port 1) möchte mit dem Server in VLAN 3 kommunizieren. Er sendet einen "nackten" (d. h. ohne VLAN-TAG) Frame zum Switch.
- Der Frame kommt am Port 1 an. Am Port zieht die INGRESS-Regel. Da der Frame da noch "nackt" ist, erhält er aufgrund der PVID 1, die VID/VLAN-ID 1 verpasst.
- Im nächsten Schritt checkt der Switch dass ein Frame zu versenden ist. Dieser Frame wird an ALLE Member (Port 1 ausgenommen, der ja Absender ist) des VLANs 1 weitergeleitet, also Port 2 und Port 3.
- Anschließend erhält Port 3 (Port 2 auch, aber den lass ich jetzt aus Gründen der Vereinfachung weg) den Frame.
- Nun soll der Frame an das angeschlossene Gerät (den Server) weiterleitet werden.
- Jetzt greift die EGRESS-Regel. Und die prüft: VID gleich PVID des Ausgangsports? VID ist 1, PVID des Ausgangsports 3 => Nicht erfüllt, damit: Übertragung mit dem TAG 1. ABER: Der Port arbeitet im UNTAG-Modus! Folglich wird das TAG entfernt und "nackt" übertragen (Annahmen stützen sich auf die Angaben auf dieser Seite, hoffe das ist korrekt...)
- Der Server erhält einen ungetagten Frame (passt, damit kann er umgehen).
- Jetzt sendet er seine Antwort an den PC in VLAN 1, d. h. der Frame geht bei Port 3 ein (UNGETAGT)
- Damit greift die INGRESS-Regel am Port: Ein "nackter" eingehender Frame erhält die VID die der PVID des Ports entspricht, also VID = 3
- Im nächsten Schritt checkt der Switch dass ein Frame zu versenden ist. Dieser Frame wird an ALLE Member (Port 3 ausgenommen, der ja Absender ist) des VLANs 3 weitergeleitet, also Port 1,2,4,5
- An den jeweiligen Ports soll der Frame nun an die angeschlossenen Endgeräte ausgegeben werden, es greift wieder die EGRESS-Regel, und wie oben bereits wird überprüft VID gleich PVID des Ausgangsports? VID ist 3, PVID des Ausgangsports 1 oder 2 => Nicht erfüllt, damit: Übertragung mit dem TAG 3. ABER: Der Port arbeitet im UNTAG-Modus! Folglich wird das TAG entfernt und "nackt" übertragen (Annahmen stützen sich wie oben auf Angaben dieser Seite)
- Die Endgeräte erhalten den ungetagten Frame (passt, damit können diese umgehen).
- Besonderheit hier: Der Antwortframe gelangt ebenfalls in das VLAN 2 (aber NUR die, daher asymetrisch), da ja der Rückkanal über das gemeinsame VLAN3 läuft
Soweit so gut - allerdings macht es mMn bei dem Beispiel keinen Sinn eine andere PVID als die VID/VLAN-ID zu vergeben. Würde man das tun, wäre das eher kontraproduktiv und die beschriebene Konfiguration wurde nicht mehr funktionieren.
Um jetzt zur Ausgangsfrage zurückzukommen:
Existiert ein Szenario bei dem ein Port im UNTAG-Modus arbeitet und die VID/VLAN-ID ungleich der PVID ist? Bzw. warum ist die PVID frei konfigurierbar und nicht automatisch im UNTAG-Modus PVID=VID?
(Wie gesagt beim dem VoIP-Fall mit dem internen Switch des Telefons ist mir das klar. Aber dort arbeitet der Port am Switch im TAGGED-Modus.)
Mit deinem Hinweis @sk
Zitat von @sk:
Im Übrigen gibt auch Szenarien, in denen mehrere VLANs nicht nur ausgehend untagged auf den gleichen Port ausgegeben werden, sondern auch eingehender Traffic trotz fehlender Kennzeichnung des Frames in unterschiedlichen VLANs landet. Beispielsweise bei protocol based VLANs.
Im Übrigen gibt auch Szenarien, in denen mehrere VLANs nicht nur ausgehend untagged auf den gleichen Port ausgegeben werden, sondern auch eingehender Traffic trotz fehlender Kennzeichnung des Frames in unterschiedlichen VLANs landet. Beispielsweise bei protocol based VLANs.
wirds heller bei mir .
Klar, wenn ich einen Port für Protocol-based VLAN konfiguriere und festlege, dass bspw. IPv4 Traffic ins vlan 10 und IPv6 Traffic ins vlan 15 packe, dann muss der entsprechende port des switches member von vlan 10 und vlan 15 sein.
Geht dieser Traffic UNTAGED beim Switch ein (INGRESS), wird hier geprüft, ob der Frame/das Packet IPv4/IPv6 ist. Dann versieht er es (intern) mit dem entsprechenden Tag. Ist es aber etwas anderes (ICMP etc.) dann MUSS er das auch markieren (Internally in the switch, all VLANs are tagged)
Und hier nimmt der dann die PVID, die ich konfiguriert habe und die wird halt in den nicht die eine der VLAN-IDs oben (10, 15) sein sondern eine andere (damit dieser ICMP-Traffic eben nicht in VLAN 10, 15 landet).
Das ist dann ein Szenario wo bei einem Port im UNTAG-Modus nicht gilt PVID = VID und wo man (sofern man sie hat) die Auto-PVID-Funktion abschaltet und selbst Hand anlegt.
So jetzt genug Verwirrung gestiftet...
Die PVID greift nur bei inbound Traffic und sie bestimmt einzig nur was mit untagged Traffic passiert der an diesem Port auftaucht.
Die PVID bestimmt in welches VLAN dieser untagged Traffic vom Switch geforwarded wird und nicht mehr und nicht weniger. So ist diese Logik dann doch recht einfach.
Bessere Switches supporten AutoPVID wo man diese separate Zuordnung nicht machen muss. Viele der billigen Websmart Switches haben das aber nicht und da muss man dann eben doppelt Hand anlegen in der Konfig des Ports.
Vielleicht hilt dir dieser Thread noch zum Thema PVID:
Warum gibt es PVID bei VLANs?
Und ggf. auch die "VLAN Schnellschulung":
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Die PVID bestimmt in welches VLAN dieser untagged Traffic vom Switch geforwarded wird und nicht mehr und nicht weniger. So ist diese Logik dann doch recht einfach.
Bessere Switches supporten AutoPVID wo man diese separate Zuordnung nicht machen muss. Viele der billigen Websmart Switches haben das aber nicht und da muss man dann eben doppelt Hand anlegen in der Konfig des Ports.
Vielleicht hilt dir dieser Thread noch zum Thema PVID:
Warum gibt es PVID bei VLANs?
Und ggf. auch die "VLAN Schnellschulung":
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Zitat von @aqui:
Die PVID greift nur bei inbound Traffic und sie bestimmt einzig nur was mit untagged Traffic passiert der an diesem Port auftaucht.
Die PVID bestimmt in welches VLAN dieser untagged Traffic vom Switch geforwarded wird und nicht mehr und nicht weniger. So ist diese Logik dann doch recht einfach.
Die PVID greift nur bei inbound Traffic und sie bestimmt einzig nur was mit untagged Traffic passiert der an diesem Port auftaucht.
Die PVID bestimmt in welches VLAN dieser untagged Traffic vom Switch geforwarded wird und nicht mehr und nicht weniger. So ist diese Logik dann doch recht einfach.
Jo, klar. Aber mir ging ja um die Frage, warum die PVID frei konfigurierbar ist und nicht automatisch im UNTAG-Modus PVID=VID gelten kann. Die Fälle, dass die PVID nicht der VID entpricht, werden sich wahrscheinlich in Grenzen halten (zumindest im nicht so komplexen "Heimanwender"-Bereich). Deshalb ist man dort meist besser beraten, die Auto-PVID zu wählen, sofern die Geräte dort eine solche zur Verfügung stellen. Aber scheint dort wohl leider nicht regelmäßig der Fall zu sein....
Die Grundprinzipien sind mir bekannt. Aber danke.
warum die PVID frei konfigurierbar ist und nicht automatisch im UNTAG-Modus PVID=VID gelten kann
Bei Switches mit Auto PVID (z.B. Cisco) passiert ja genau das !Du kennst vermutlich nur diese Gruselswitches wo man es eben immer noch extra setzen muss...?!
dass die PVID nicht der VID entpricht, werden sich wahrscheinlich in Grenzen halten
Richtig ! Das ist fast immer der Fall. Bei den besseren SoHo Switches und im Premium Segment ist Auto PVID durchgehend Standard.
Moin,
ich habe leider aktuell nicht die Zeit, mich hier stärker zu beteiligen. Nur soviel:
Die meisten Hersteller unterscheiden zwischen Access-, Trunk- und Hybridports. Letztere werden teilweise auch mit "general" umschrieben. Wobei die damit verbundene Funktionalität je nach Hersteller oder sogar Produktserie oder Firmwarestand durchaus im Detail etwas abweichen kann und auch ggf. nochmal anpassbar ist.
Trunk- und Accessport kann man als Konfigurationsprofile auffassen, die typische Anforderungen abdecken.
Unter einem Accessport versteht man üblicher Weise, dass daran nur ein Endgerät angeschlossen ist, welches mit VLAN-Tags nicht umgehen kann. Dementsprechend erwartet man als Admin, dass ein solcher Port nur Member in einem einzigen VLAN ist und dessen Traffic sowohl ingress als auch egress untagged ist. Tagged am Accessport eingehender Traffic sollte bestenfalls für das Vlan akzeptiert werden, in dem der Port Member ist (was gleichzeitig der PVID des Ports entspricht).
An Trunkports hängen Vlan-fähige Infrastrukturkomponenten wie Switche, Router, Accesspoints, Server, Telefone usw. Hier können mehrere Vlans tagged und optional ein Vlan untagged übertragen werden. Bei letzterem folgt auch egress Traffic der PVID oder anders ausgedrückt: das VLAN, welches ingress als Native akzeptiert wird, wird auch zwingend egress untagged ausgegeben.
Hybrid-Ports sind demgegenüber wesentlich granularer konfigurierbar. Sie können so konfiguriert werden, dass sie den Traffic exakt so handhaben, wie bei den beiden vorstehenden Typisierungen erläutert. Man kann jedoch durchaus auch komplexere Szenarien abbilden. Das hier diskutierte Szenario der asymmetrischen Vlans ist nur mit Hybrid/General-Ports realisierbar.
Viele Billighersteller implementieren im UI nur Hybrid-/General-Ports und überlassen es dem Admin, das gewünschte Verhalten zu konfigurieren. Das kann man sicherlich schlecht finden, wenn man die damit verbundenen Freiheiten nicht benötigt oder damit vom Verständnis her überfordert ist.
Bei anderen Herstellern wiederum scheint es vordergründig nur Access- und Trunkports zu geben. Bei genauer Betrachtung stimmt dies aber meist nicht. Meist gibt es dann doch Features, die typische erweiterte Funktionalitäten eines Hybridports voraussetzen. Beispielsweise basieren sog. "community private Vlans" (Cisco geprägte Terminologie) schlicht auf dem Prinzip der asymmetrischen Vlans.
Gruß
sk
P.S. @apoth1 Du solltest Dich auch nochmal damit auseinandersetzen, wann ein Switch Traffic auf mehreren Ports rausgeschickt und wann nicht.
ich habe leider aktuell nicht die Zeit, mich hier stärker zu beteiligen. Nur soviel:
Die meisten Hersteller unterscheiden zwischen Access-, Trunk- und Hybridports. Letztere werden teilweise auch mit "general" umschrieben. Wobei die damit verbundene Funktionalität je nach Hersteller oder sogar Produktserie oder Firmwarestand durchaus im Detail etwas abweichen kann und auch ggf. nochmal anpassbar ist.
Trunk- und Accessport kann man als Konfigurationsprofile auffassen, die typische Anforderungen abdecken.
Unter einem Accessport versteht man üblicher Weise, dass daran nur ein Endgerät angeschlossen ist, welches mit VLAN-Tags nicht umgehen kann. Dementsprechend erwartet man als Admin, dass ein solcher Port nur Member in einem einzigen VLAN ist und dessen Traffic sowohl ingress als auch egress untagged ist. Tagged am Accessport eingehender Traffic sollte bestenfalls für das Vlan akzeptiert werden, in dem der Port Member ist (was gleichzeitig der PVID des Ports entspricht).
An Trunkports hängen Vlan-fähige Infrastrukturkomponenten wie Switche, Router, Accesspoints, Server, Telefone usw. Hier können mehrere Vlans tagged und optional ein Vlan untagged übertragen werden. Bei letzterem folgt auch egress Traffic der PVID oder anders ausgedrückt: das VLAN, welches ingress als Native akzeptiert wird, wird auch zwingend egress untagged ausgegeben.
Hybrid-Ports sind demgegenüber wesentlich granularer konfigurierbar. Sie können so konfiguriert werden, dass sie den Traffic exakt so handhaben, wie bei den beiden vorstehenden Typisierungen erläutert. Man kann jedoch durchaus auch komplexere Szenarien abbilden. Das hier diskutierte Szenario der asymmetrischen Vlans ist nur mit Hybrid/General-Ports realisierbar.
Viele Billighersteller implementieren im UI nur Hybrid-/General-Ports und überlassen es dem Admin, das gewünschte Verhalten zu konfigurieren. Das kann man sicherlich schlecht finden, wenn man die damit verbundenen Freiheiten nicht benötigt oder damit vom Verständnis her überfordert ist.
Bei anderen Herstellern wiederum scheint es vordergründig nur Access- und Trunkports zu geben. Bei genauer Betrachtung stimmt dies aber meist nicht. Meist gibt es dann doch Features, die typische erweiterte Funktionalitäten eines Hybridports voraussetzen. Beispielsweise basieren sog. "community private Vlans" (Cisco geprägte Terminologie) schlicht auf dem Prinzip der asymmetrischen Vlans.
Gruß
sk
P.S. @apoth1 Du solltest Dich auch nochmal damit auseinandersetzen, wann ein Switch Traffic auf mehreren Ports rausgeschickt und wann nicht.
Hallo zusammen,
ich bin mal so frech und grabe den Thread aus, da ich mir dieselbe Frage auch gestellt habe.
Ich lese öfters, dass der Traffic der dann untagged ausgegeben wird, beim Trunk wieder im selben PVID landet.
Da geht man aber davon aus, dass bei der Trunkpartner der Port dieselbe PVID konfiguriert bekommen hat, weil sonst kann der es ja nicht wissen - oder?
Wie werden eigentlich "PVID mismatches" erkannt? Durch die control frames?
Und gleich noch zwei peinliche Anfängerfragen obendrauf:
Eine PVID kann durchaus auf mehreren Ports verwendet werden und kann auch in mehreren Vlans Mitglied sein - richtig?
OT: Gibt es eigentlich noch Szenarien wo man ein proprietäres portbasiertes einem "richtigen" 802.1Q VLAN vorzieht?
Im Privatbereich oder gar SOHO Bereich? Oder hat das praktisch keine Bedeutung mehr?
Apropos Anfänger... habe hier eine interessante Seite gefunden: networkacademy.io
Habe damit nichts zu tun, die Seite gehört wohl einem (u.a.) CCIE aus Bulgarien.
Wäre event. jemand von den Profis so nett und könnte kurz 2-3 Seiten überfliegen?
Nur um sicher zu gehen, dass da alles Hand und Fuß hat - für einen Anfänger sieht es ja schnell mal gut aus.
Denn gerade auch die Animationen sind mMn. gut gemacht - vielleicht hilft es ja jemanden, neben den ganzen tollen Anleitungen von aqui und den zahlreichen anderen Beiträgen hier auf der Seite.
Danke und Grüße,
Martin
ich bin mal so frech und grabe den Thread aus, da ich mir dieselbe Frage auch gestellt habe.
Zitat von @aqui:
Untagged Port ausgehend: Die VLAN-Markierung wird überprüft und beim Versenden entfernt //
Untagged Port ausgehend: Die VLAN-Markierung wird überprüft und beim Versenden entfernt //
Zitat von @sk:
An Trunkports hängen Vlan-fähige Infrastrukturkomponenten wie Switche, Router, Accesspoints, Server, Telefone usw. Hier können mehrere Vlans tagged und optional ein Vlan untagged übertragen werden. Bei letzterem folgt auch egress Traffic der PVID oder anders ausgedrückt: das VLAN, welches ingress als Native akzeptiert wird, wird auch zwingend egress untagged ausgegeben.
An Trunkports hängen Vlan-fähige Infrastrukturkomponenten wie Switche, Router, Accesspoints, Server, Telefone usw. Hier können mehrere Vlans tagged und optional ein Vlan untagged übertragen werden. Bei letzterem folgt auch egress Traffic der PVID oder anders ausgedrückt: das VLAN, welches ingress als Native akzeptiert wird, wird auch zwingend egress untagged ausgegeben.
Ich lese öfters, dass der Traffic der dann untagged ausgegeben wird, beim Trunk wieder im selben PVID landet.
Da geht man aber davon aus, dass bei der Trunkpartner der Port dieselbe PVID konfiguriert bekommen hat, weil sonst kann der es ja nicht wissen - oder?
Wie werden eigentlich "PVID mismatches" erkannt? Durch die control frames?
Und gleich noch zwei peinliche Anfängerfragen obendrauf:
Eine PVID kann durchaus auf mehreren Ports verwendet werden und kann auch in mehreren Vlans Mitglied sein - richtig?
OT: Gibt es eigentlich noch Szenarien wo man ein proprietäres portbasiertes einem "richtigen" 802.1Q VLAN vorzieht?
Im Privatbereich oder gar SOHO Bereich? Oder hat das praktisch keine Bedeutung mehr?
Apropos Anfänger... habe hier eine interessante Seite gefunden: networkacademy.io
Habe damit nichts zu tun, die Seite gehört wohl einem (u.a.) CCIE aus Bulgarien.
Wäre event. jemand von den Profis so nett und könnte kurz 2-3 Seiten überfliegen?
Nur um sicher zu gehen, dass da alles Hand und Fuß hat - für einen Anfänger sieht es ja schnell mal gut aus.
Denn gerade auch die Animationen sind mMn. gut gemacht - vielleicht hilft es ja jemanden, neben den ganzen tollen Anleitungen von aqui und den zahlreichen anderen Beiträgen hier auf der Seite.
Danke und Grüße,
Martin
Ich lese öfters, dass der Traffic der dann untagged ausgegeben wird, beim Trunk wieder im selben PVID landet.
Das entscheidet einzig und allein die PVID Einstellung (Native VLAN) am Trunk Port. UNtagged Frames haben ja keinerlei VLAN Information und so muss man dem Switch in seiner Portkonfig sagen welche PVID bzw. Native VLAN ID er an dem Port nutzen soll um ungetaggte Pakete zu forwarden.In der Regel ist die PVID gleich so das von der einen Seite der ungetaggte VLAN Traffic aus VLAN x auch auf der anderen Seite in VLAN x landet.
Es ist aber nicht verboten wenn du auf der einen Seite aus VLAN x sendest diesen auf der anderen Seite in VLAN y forwardest (sog. VLAN Translation).
Auch das ist problemlos möglich.
Allerdings mss man bei solchen Aktien etwas aufpassen wenn man z.B. mit PVSTP (Per VLAN Spanning Tree) arbeitet, das es da nicht zu Problemen kommt. Mit billigen Single Span Switches ist das meist risikoärmer.
Eine PVID kann durchaus auf mehreren Ports verwendet werden
Das ist sogar ein Muss, denn die PVID ist immer und auf jedem Port definiert. Sowohl bei ungetaggten Access Ports als auch Trunk Ports. Logisch, denn eine VLAN Switch muss ja immer statisch vom Admin wissen in welchem VLAN der Port ungetaggten Traffic senden und empfangen soll. Da, wie oben schon gesagt, ungetaggtem Traffic ja intern die VLAN Information fehlt. Einfache Logik! 😉Siehe dazu auch die VLAN Schnellschulung die dies im Detail erklärt.
und kann auch in mehreren Vlans Mitglied sein - richtig?
Das ist richtig aber immer nur pro Port. Ein einzelner Port kann prinzipbedingt ja niemals Mitglied in mehreren ungetaggten VLANs gleichzeitig sein. Zumindestens nicht mit einer statischen Konfiguration.Gute VLAN Switches können sog. "Mac based VLANs" wo ein Radius Server im Hintergrund werkelt und dann je nach Mac Adresse am Port diesen Mac Adress spezifischen Traffic in unterschiedliche VLANs forwarden kann. Da gehts dann aber schon ins Eingemachte...
Gibt es eigentlich noch Szenarien wo man ein proprietäres portbasiertes einem "richtigen" 802.1Q VLAN vorzieht?
Nein, niemals. Sowas bindet dann immer an einen Hersteller was generell ein NoGo ist! Hier sollte man in jedem Falle immer Standard konform bleiben. Am Markt gibt es sowas auch gar nicht mehr außer ein paar seltene Ausnahmen im Billigbereich.Die Animationen auf der von dir zitierten Seite sind in der Tat sehr gut und beschreiben das VLAN Verhalten sehr übersichtlich. Und...danke für die 💐 !
P.S.: Öfter ist ja schon mehr als oft und lässt sich deshalb nicht mehr weiter steigern.