Private VLAN (PVLAN) konfigurieren: Mehr Isolation im LAN

Wer in einem LAN mehr Isolation braucht als ein klassisches VLAN bieten kann, landet früher oder später bei Private VLANs. Genau darum geht es in dieser Anleitung: Private VLAN (PVLAN) konfigurieren, um Geräte innerhalb derselben Broadcast-Domäne voneinander zu trennen – ohne für jeden Host ein eigenes VLAN anlegen zu müssen. Das ist besonders attraktiv in Umgebungen wie Rechenzentren, Hosting, DMZ-Netzen, Shared-Access-Segmenten oder überall dort, wo viele Systeme im gleichen IP-Subnetz liegen, aber nicht miteinander sprechen sollen. Ein typisches Beispiel sind Server oder virtuelle Maschinen, die zwar alle das gleiche Default Gateway nutzen müssen, sich aber gegenseitig nicht direkt erreichen dürfen. PVLANs lösen dieses Problem auf Layer 2: Sie unterteilen ein „Primär-VLAN“ in sekundäre VLANs (isolated und community) und steuern präzise, welche Ports miteinander kommunizieren dürfen. Das Ergebnis ist mehr Sicherheit, weniger laterale Bewegung im Netz und ein klareres Segmentierungsmodell – vorausgesetzt, die Konfiguration ist sauber und konsequent. In den folgenden Schritten lernen Sie die PVLAN-Bausteine, die gängigen Cisco-Befehle, ein praxistaugliches Beispielsetup sowie die wichtigsten Prüf- und Troubleshooting-Kommandos, damit die Isolation nicht nur theoretisch existiert, sondern im Alltag zuverlässig funktioniert.

PVLAN-Grundlagen: Primär, sekundär, Promiscuous, Isolated und Community

Private VLANs erweitern das VLAN-Konzept um eine zweite Ebene. Statt nur „VLAN 100“ zu haben, definieren Sie ein Primär-VLAN und ordnen diesem eine oder mehrere sekundäre VLANs zu. Die Ports werden anschließend als PVLAN-Ports konfiguriert, die unterschiedliche Kommunikationsregeln haben.

• Primär-VLAN (Primary VLAN): Die übergeordnete Broadcast-Domäne, an die sekundäre VLANs gebunden werden.
• Isolated VLAN: Hosts in diesem sekundären VLAN können nur mit einem Promiscuous-Port sprechen, aber nicht untereinander.
• Community VLAN: Hosts in derselben Community dürfen untereinander kommunizieren und zusätzlich zum Promiscuous-Port.
• Promiscuous Port: „Gateway-Port“ – kann mit allen sekundären VLANs (Isolated + Communities) sprechen, typischerweise Richtung Default Gateway/Firewall/Router.
• Host Port: Endgeräte-Port, der entweder isoliert oder Community-gebunden ist.

Eine praxisnahe, herstellerseitige Beschreibung inklusive typischer Regeln und Einschränkungen finden Sie über den Anchor-Text Cisco TechNote zu Private VLANs (Promiscuous/Isolated/Community).

Wann PVLANs sinnvoll sind: typische Einsatzszenarien

PVLANs sind besonders dann hilfreich, wenn Sie Layer-2-Isolation innerhalb eines gemeinsamen IP-Subnetzes benötigen. Das reduziert die Zahl der VLANs und vereinfacht IP-Adressierung, ohne auf Isolation zu verzichten.

• Hosting/Colocation: Viele Kunden-Server im gleichen Subnetz, aber keine direkte Server-zu-Server-Kommunikation.
• DMZ-Design: Systeme dürfen nur zum Gateway/Load Balancer, aber nicht lateral zueinander.
• Shared VLAN in Virtualisierung: VMs sollen ein gemeinsames Netz nutzen, aber voneinander getrennt sein.
• IoT/Edge-Segmente: Geräte sollen nur zum zentralen Dienst sprechen, nicht miteinander.

Wichtig: PVLANs ersetzen keine Firewall. Sie verhindern vor allem direkte Layer-2-Kommunikation zwischen Hosts. Für feinere Zugriffskontrolle (Ports, Applikationsregeln, Benutzerkontext) benötigen Sie weiterhin ACLs/Firewall-Policies.

Planung: PVLAN-Design mit VLAN-IDs und Portrollen

Bevor Sie konfigurieren, planen Sie Ihr PVLAN-Layout. Ein praxistaugliches Beispiel:

• Primär-VLAN 100 (PVLAN-Primary)
• Isolated VLAN 101 (PVLAN-Isolated)
• Community VLAN 102 (PVLAN-Community A)
• Community VLAN 103 (PVLAN-Community B)

Portrollen:

• Promiscuous Port: Uplink zur Firewall oder zum Default Gateway (z. B. Gi1/0/48)
• Isolated Host Ports: „Single-Tenant“-Hosts, die nur zum Gateway sollen (z. B. Gi1/0/1–Gi1/0/10)
• Community Host Ports: Hosts, die untereinander sprechen dürfen, aber nicht zu anderen Communities (z. B. Gi1/0/11–Gi1/0/20)

Best Practice: Dokumentieren Sie bereits in der Planung, welche Ports zu welcher PVLAN-Rolle gehören und welcher Uplink als Promiscuous-Port dient. PVLAN-Konfigurationen sind sehr logisch, aber auch sehr konsequent: Ein einzelner falsch zugeordneter Port kann Isolation aufheben oder Kommunikation blockieren.

Voraussetzungen und typische Hinweise vor der Konfiguration

Je nach Switch-Plattform und IOS/IOS XE-Version gibt es Einschränkungen. In vielen Cisco-Implementierungen gilt zudem: PVLANs arbeiten am zuverlässigsten, wenn Sie die VLAN- und Trunk-Struktur bewusst und restriktiv halten. Einige Umgebungen erfordern VTP Transparent Mode, andere arbeiten ohnehin ohne VTP. Prüfen Sie daher vorab, welche Betriebsart in Ihrer Umgebung vorgesehen ist.

• PVLAN-Unterstützung des Switch-Modells und der Software prüfen (show version).
• VLAN-Konzept und Trunks planen (PVLANs nicht „nebenbei“ über zufällige Uplinks transportieren).
• Default Gateway/Firewall-Port als Promiscuous-Port definieren.
• Erwartetes Kommunikationsmodell festlegen (wer darf mit wem sprechen?).

Plattformspezifische Details finden Sie in den offiziellen Konfigurationsguides, z. B. über den Anchor-Text Cisco IOS XE VLAN Configuration Guide (Private VLANs).

Schritt 1: Primär- und sekundäre VLANs anlegen

Im ersten Schritt legen Sie die VLANs an und definieren deren PVLAN-Rolle. Das Primär-VLAN bekommt den Typ „primary“, die sekundären VLANs den Typ „isolated“ oder „community“.

enable
configure terminal
vlan 100
private-vlan primary
vlan 101
private-vlan isolated
vlan 102
private-vlan community
vlan 103
private-vlan community

Primär-VLAN mit sekundären VLANs verknüpfen

Jetzt verbinden Sie die sekundären VLANs mit dem Primär-VLAN. Das geschieht über die Association.

vlan 100
private-vlan association 101,102,103
end

Prüfen:

show vlan private-vlan
show vlan brief

Schritt 2: Promiscuous Port konfigurieren (Gateway-Port)

Der Promiscuous-Port ist die zentrale „Ausnahme“: Er darf mit allen Hosts in den sekundären VLANs kommunizieren. Typischerweise hängt hier die Firewall oder ein Layer-3-Gateway, über das der Verkehr aus dem PVLAN herausgeht.

Beispiel: Gi1/0/48 ist der Uplink zur Firewall. Er wird als PVLAN Promiscuous Port gesetzt und erhält eine Mapping-Liste, die Primär-VLAN 100 auf die sekundären VLANs abbildet.

configure terminal
interface gigabitethernet1/0/48
description Uplink zur Firewall (PVLAN Promiscuous)
switchport mode private-vlan promiscuous
switchport private-vlan mapping 100 101,102,103
no shutdown
end

Prüfen:

show running-config interface gigabitethernet1/0/48
show interfaces switchport gigabitethernet1/0/48

Schritt 3: Host Ports konfigurieren (Isolated und Community)

Host Ports sind die Ports, an denen Endgeräte hängen. Sie werden als „private-vlan host“ gesetzt und anschließend mit einer Host-Association an Primär- und sekundäres VLAN gebunden.

Isolated Host Ports (nur zum Gateway, nicht untereinander)

Beispiel: Gi1/0/1 bis Gi1/0/10 sollen isoliert sein (VLAN 101).

configure terminal
interface range gigabitethernet1/0/1 - 1/0/10
description PVLAN Isolated Hosts
switchport mode private-vlan host
switchport private-vlan host-association 100 101
spanning-tree portfast
no shutdown
end

Community Host Ports (untereinander + zum Gateway)

Beispiel: Gi1/0/11 bis Gi1/0/15 sollen Community A (VLAN 102) nutzen, Gi1/0/16 bis Gi1/0/20 Community B (VLAN 103).

configure terminal
interface range gigabitethernet1/0/11 - 1/0/15
description PVLAN Community A Hosts
switchport mode private-vlan host
switchport private-vlan host-association 100 102
spanning-tree portfast
no shutdown
interface range gigabitethernet1/0/16 - 1/0/20
description PVLAN Community B Hosts
switchport mode private-vlan host
switchport private-vlan host-association 100 103
spanning-tree portfast
no shutdown
end

Prüfen:

show interfaces switchport gigabitethernet1/0/1
show interfaces switchport gigabitethernet1/0/11

Kommunikationsregeln in der Praxis: Was darf jetzt mit wem sprechen?

Wenn das PVLAN sauber aufgebaut ist, gelten typische Regeln:

• Isolated ↔ Isolated: nicht erlaubt (Host-zu-Host blockiert)
• Isolated ↔ Community: nicht erlaubt
• Community A ↔ Community A: erlaubt
• Community A ↔ Community B: nicht erlaubt
• Alle Hosts ↔ Promiscuous: erlaubt (z. B. Richtung Gateway/Firewall)

Das ist genau der Kernnutzen: viele Hosts im gleichen IP-Subnetz, aber kontrollierte L2-Kommunikation.

PVLAN über mehrere Switches: Warum „nur am Access-Switch“ nicht reicht

Ein häufiger Fehler in realen Umgebungen ist, PVLAN nur auf dem Access-Switch zu konfigurieren, aber nicht auf den Zwischenkomponenten. PVLAN-Verhalten muss entlang des Pfads konsistent sein, sonst verlieren Sie Isolation oder erreichen nicht die gewünschte Kommunikation. Wenn Traffic über Trunks oder Port-Channels zu einem Distribution-Switch geht, müssen die PVLANs dort ebenfalls korrekt gehandhabt werden (inklusive primärer/sekundärer VLANs und ggf. PVLAN-Trunks).

• PVLAN-Konfiguration auf allen relevanten Switches konsistent umsetzen.
• Allowed VLANs auf Trunks restriktiv und bewusst planen.
• PVLAN-Topologie dokumentieren (welcher Switch trägt welche PVLANs?).

Cisco weist in den Konfigurationsguides explizit darauf hin, PVLANs auch auf Zwischenkomponenten sauber zu konfigurieren; siehe dazu die offiziellen Hinweise im Anchor-Text Configuring Private VLANs (Catalyst 9200, PDF).

Layer-3-Gateway und PVLAN: wo sitzt das Default Gateway?

In PVLAN-Designs hängt das Default Gateway typischerweise am Promiscuous-Port (Firewall oder Router) und bedient das gemeinsame IP-Subnetz des Primär-VLANs. Die Hosts bleiben im gleichen IP-Netz, erhalten aber durch PVLAN-Regeln L2-Isolation. Das bedeutet:

• Alle PVLAN-Hosts verwenden dasselbe IP-Subnetz (z. B. 10.10.10.0/24).
• Das Gateway ist eine IP in diesem Subnetz (z. B. 10.10.10.1) und hängt am Promiscuous-Port.
• Interne Host-zu-Host-Kommunikation wird auf Layer 2 eingeschränkt.

Wenn Sie mit einem Layer-3-Switch als Gateway arbeiten, müssen Sie sehr genau prüfen, wie Ihr Plattformdesign PVLAN und SVIs unterstützt. Häufig ist ein externes Gateway (Firewall/Router) am Promiscuous-Port die klarste, betriebssichere Variante.

Verifikation: So prüfen Sie PVLAN-Isolation zuverlässig

Nach der Konfiguration sollten Sie die Isolation nicht nur „glauben“, sondern testen und über Show-Befehle verifizieren. Bewährt hat sich ein Mix aus Kontrollkommandos und echten Connectivity-Tests.

Wichtige Show-Befehle

• show vlan private-vlan (PVLAN-Struktur: primary/secondary/associations)
• show interfaces switchport <IF> (Portrolle: host/promiscuous, Zuordnung)
• show running-config interface <IF> (Mapping/Host-Association überprüfen)
• show mac address-table (MAC-Lernen pro Port/VLAN-Kontext)

Connectivity-Tests (Praxis)

• Host in Isolated VLAN pingt Gateway: sollte funktionieren.
• Zwei Hosts im Isolated VLAN pingen sich gegenseitig: sollte scheitern.
• Zwei Hosts in derselben Community pingen sich: sollte funktionieren.
• Hosts in Community A und B pingen sich: sollte scheitern.

Diese Tests sind in der Praxis oft aussagekräftiger als jede einzelne Konfigzeile, weil sie direkt zeigen, ob die Isolation im Betrieb greift.

Häufige Fehlerbilder und Troubleshooting

PVLAN-Konfigurationen sind logisch, aber streng. Die meisten Probleme lassen sich auf wenige Ursachen zurückführen.

Problem: Hosts erreichen nicht einmal das Gateway

• Promiscuous Port fehlt Mapping: switchport private-vlan mapping prüfen.
• Host Ports falsch assoziiert (Primary/Secondary vertauscht): host-association prüfen.
• VLANs nicht korrekt als primary/secondary definiert oder nicht assoziiert: show vlan private-vlan.
• Gateway/Firewall-Port ist nicht wirklich am Promiscuous-Port angeschlossen (Verkabelung/Portauswahl).

Problem: Isolation greift nicht, Hosts können doch miteinander sprechen

• Hosts hängen versehentlich in einer Community statt Isolated.
• Ein Trunk/Intermediate Switch transportiert VLANs ohne PVLAN-Logik, wodurch Isolation ausgehebelt wird.
• Ports sind nicht im PVLAN-Mode, sondern klassisch Access/Trunk konfiguriert.

Problem: PVLAN über mehrere Switches „bricht“

• PVLANs sind nicht auf allen Zwischen-Switches konfiguriert (Konfigkonsistenz fehlt).
• Allowed VLANs auf Trunks schließen sekundäre VLANs aus.
• Port-Channel/Trunk-Konfiguration ist inkonsistent zwischen Mitgliedsports und Port-Channel-Interface.

Best Practices: Mehr Isolation ohne Betriebschaos

PVLANs bringen Isolation, können aber auch komplex werden, wenn sie ohne Regeln wachsen. Diese Best Practices helfen, die Lösung wartbar zu halten:

• Restriktive Planung: Nur so viele Communities wie nötig, Isolated für „Single-Tenant“-Hosts.
• Klare Portrollen: Promiscuous-Ports eindeutig beschreiben und dokumentieren.
• Konsequente Trunk-Strategie: PVLANs nicht „quer“ durchs Netz tragen, ohne die Zwischenpfade zu kontrollieren.
• Dokumentation: Primär/sekundär VLANs, Zuordnung, Portlisten, Gateway-Port, Abhängigkeiten.
• Security-Konzept ergänzen: PVLAN ist Layer-2-Isolation; ergänzen Sie Policies mit ACLs/Firewall, wo notwendig.

Als herstellerneutrale Grundlage für Sicherheitsprinzipien wie Segmentierung und Minimierung der Angriffsfläche eignet sich der Anchor-Text CIS Controls.

Konfiguration speichern und Backup einplanen

PVLAN-Änderungen sind oft zentral für Isolation. Speichern Sie daher nach erfolgreicher Verifikation die Konfiguration, damit sie nach Neustart erhalten bleibt:

copy running-config startup-config

Zusätzlich ist ein externes Backup empfehlenswert (z. B. per SCP/SFTP), damit Sie bei Hardwaretausch oder Rollback schnell reagieren können. Eine Cisco-Referenz zu sicheren Transfers finden Sie über den Anchor-Text Cisco Secure Copy (SCP) und SFTP.

Weiterführende Orientierung: PVLAN-Konzepte und Cisco-Referenzen

PVLANs sind ein spezialisiertes Feature, dessen exakte Befehle und Einschränkungen je nach Switch-Serie und IOS/IOS XE-Version variieren können. Für ein praxisnahes Konfigurationsbeispiel (inklusive Verifikation und Troubleshooting) ist der Anchor-Text Cisco TechNote zu PVLANs besonders hilfreich. Für plattformspezifische Details und Beispiele (Primary/Isolated/Community, Zuordnung und Verifikation) nutzen Sie zudem den Anchor-Text Configuring Private VLANs (Catalyst 9200) oder den Anchor-Text VLAN Configuration Guide (Catalyst 9600, Private VLANs), um Syntax und Plattformverhalten verlässlich abzugleichen.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.