Wenn Geräte in getrennten Subnetzen nicht kommunizieren, liegt die Ursache fast immer in einer von drei Ebenen: falsches VLAN-Tagging am Switchport, fehlendes Inter-VLAN-Routing am Layer-3-Gerät oder eine ACL beziehungsweise Firewall-Regel, die den Verkehr verwirft. Prüfen Sie diese drei Punkte in dieser Reihenfolge.
Symptome
- Ping in ein anderes Subnetz läuft in Timeout, im gleichen VLAN funktioniert er
- Client erhält keine oder eine APIPA-Adresse (169.254.x.x) trotz aktivem DHCP-Relay
- tracert bricht am Default-Gateway oder am Core-Switch ab
- DNS-Auflösung funktioniert, aber TCP-Verbindungen auf Port 443 oder 445 schlagen fehl
- Voice- oder IoT-VLAN sieht die Management-Ressourcen nicht mehr nach einem Switch-Tausch
Häufige Ursachen
Falsches VLAN am Access-Port
Der Switchport ist einem falschen Access-VLAN zugewiesen oder als Trunk ohne das benötigte VLAN in der Allowed-List konfiguriert. Nach Patchfeld-Umzügen tritt das besonders häufig auf.
Fehlendes Inter-VLAN-Routing
Die VLANs existieren sauber auf Layer 2, aber es gibt keine SVI beziehungsweise kein Router-on-a-Stick, das die Subnetze verbindet. Ohne Layer-3-Instanz bleibt jedes VLAN eine Insel.
Subnetzmaske oder Gateway falsch
Die Maske ist zu klein gewählt, sodass das Zielnetz irrtümlich als lokal gilt und ARP statt Routing verwendet wird. Ein falsches Default-Gateway hat denselben Effekt.
ACL oder Firewall blockiert Ost-West-Traffic
Segmentierung ist gewollt: Eine Zonenregel verwirft Verkehr zwischen VLANs. Das ist erst ein Problem, wenn eine legitime Ausnahme fehlt oder eine Regel zu breit greift.
DHCP-Relay fehlt oder zeigt ins Leere
Clients im neuen VLAN erreichen den zentralen DHCP-Server nicht, weil auf der SVI kein ip helper-address gesetzt ist oder auf eine alte Serveradresse verweist.
Schritt-für-Schritt-Lösung
- Symptom eindeutig eingrenzen: gleiches VLAN, anderes VLAN oder extern
Testen Sie von einem betroffenen Client aus drei Pings: das eigene Gateway, einen Host im gleichen Subnetz und einen Host im Zielsubnetz. Nur so trennen Sie Layer-2-, Layer-3- und Firewall-Probleme sauber voneinander. Notieren Sie die Ergebnisse, bevor Sie etwas ändern. - Switchport- und VLAN-Zuordnung am Access-Switch prüfen
Melden Sie sich am zuständigen Switch an und lassen Sie sich die Portkonfiguration ausgeben (bei Cisco IOS etwa show interfaces status und show vlan brief). Vergleichen Sie das konfigurierte VLAN mit der Doku. Prüfen Sie bei Trunk-Ports zusätzlich die Allowed-VLAN-Liste. - Layer-3-Interface (SVI) und Routing-Tabelle kontrollieren
Prüfen Sie, ob für jedes betroffene VLAN eine SVI mit korrekter IP und Subnetzmaske existiert und Status up/up meldet. Kontrollieren Sie danach die Routing-Tabelle, ob beide Zielnetze als direkt verbunden oder über eine gültige Route erreichbar sind. - IP-Konfiguration am Client mit dem Netzplan abgleichen
Rufen Sie ipconfig /all beziehungsweise ip a auf. IP, Maske und Gateway müssen zum Soll-Subnetz passen. Häufigster Fehler ist eine /24-Maske, obwohl das Netz als /23 geplant ist, oder ein Gateway aus einem anderen VLAN. - DHCP-Relay und Adressvergabe verifizieren
Bei APIPA-Adressen prüfen Sie auf der SVI die Konfiguration ip helper-address <DHCP-Server>. Auf dem DHCP-Server müssen Scope, Ausschlussbereiche und Optionen (Gateway, DNS) für das VLAN existieren. Ein Leasetest mit ipconfig /release und /renew bestätigt den Fix. - Firewall- und ACL-Regeln zwischen den Zonen auswerten
Öffnen Sie die Regelbasis der Firewall oder die ACL auf dem Layer-3-Switch und filtern Sie nach Quell- und Ziel-Subnetz. Prüfen Sie Trefferzähler und Logs. Fehlt eine explizite Allow-Regel, greift die implizite Deny-Regel am Ende – genau dann bleibt der Traffic stumm. - Mit tcpdump oder Wireshark am Uplink mitschneiden
Wenn Konfiguration und Routing korrekt aussehen, spiegeln Sie den Uplink-Port (SPAN) und schneiden Sie den Verkehr mit. So sehen Sie, ob Pakete das Segment überhaupt verlassen, ob Antworten zurückkommen und ob ein Gerät ICMP-Unreachable schickt. - Änderung sauber dokumentieren und Regressionen ausschließen
Speichern Sie die Konfiguration (write memory bzw. commit), aktualisieren Sie den Netzplan und tragen Sie die Änderung ins Change-Log ein. Testen Sie danach angrenzende Dienste wie Drucken, Voice und Backup, damit die Korrektur nichts anderes bricht.
Typische Symptome bei Segmentierungsfehlern und ihre wahrscheinliche Ursache
| Symptom | Wahrscheinliche Ursache | Erster Prüfschritt |
|---|---|---|
| Ping ins eigene Gateway schlägt fehl | Falsches Access-VLAN am Switchport | show interfaces status am Access-Switch |
| Ping ins Gateway ok, in anderes Subnetz Timeout | Kein Inter-VLAN-Routing oder ACL blockiert | Routing-Tabelle und ACL-Trefferzähler prüfen |
| Client bekommt 169.254.x.x | DHCP-Relay fehlt oder Scope leer | ip helper-address auf SVI kontrollieren |
| tracert endet am Core-Switch | Fehlende Route oder Deny-Regel | show ip route und Firewall-Log |
| Nur bestimmte Ports blockiert | Zonenregel zu restriktiv | Firewall-Regelwerk nach Port filtern |
| Nach Switch-Tausch alles offline | Trunk-Allowed-List unvollständig | show interfaces trunk am Uplink |
So beugen Sie vor
- VLAN-, Subnetz- und ACL-Design in einer versionierten IPAM-Doku pflegen
- Switchkonfigurationen regelmäßig sichern und automatisiert diff-prüfen
- Neue Segmente vor Produktivsetzung mit Test-Clients gegen alle Zonen prüfen
- Monitoring auf SVI-Status, DHCP-Poolauslastung und ACL-Denies einrichten
Häufige Fragen
Wie unterscheide ich ein VLAN-Problem von einem Routing-Problem?
Testen Sie zuerst den Ping auf das eigene Default-Gateway. Klappt der nicht, liegt der Fehler auf Layer 2, meist am VLAN-Tag des Switchports. Erreichen Sie das Gateway, aber kein anderes Subnetz, ist es ein Layer-3- oder Firewall-Thema. Diese Zweiteilung spart die meiste Zeit.
Warum funktioniert DHCP nur in einem meiner VLANs?
Der DHCP-Server steht üblicherweise in einem anderen Segment. Ohne ip helper-address auf der SVI des Client-VLANs werden DHCP-Broadcasts nicht weitergeleitet, und die Clients fallen auf APIPA zurück. Prüfen Sie die Helper-Adresse und, ob am Server ein passender Scope für dieses Subnetz existiert.
Sollten alle Subnetze untereinander erreichbar sein?
Nein, das widerspricht dem Zweck der Segmentierung. Gast-, IoT- und OT-Netze sollten bewusst isoliert bleiben und nur definierte Ports zu klar benannten Zielen dürfen. Legen Sie Ausnahmen als explizite Allow-Regeln an und dokumentieren Sie den Business-Grund direkt in der Regel.