Inter-VLAN Routing Troubleshooting: SVI, ACLs und Gateway-Probleme

Inter-VLAN Routing Troubleshooting ist immer dann gefragt, wenn das LAN „eigentlich funktioniert“, aber Kommunikation zwischen Segmenten plötzlich ausfällt oder nur teilweise klappt: Clients kommen ins Internet, erreichen aber keine Server im Nachbar-VLAN; Drucker sind nur aus manchen Netzen erreichbar; VoIP-Telefone registrieren sich, aber Management-Zugriff geht nicht; oder nach einer VLAN-Erweiterung ist das neue Subnetz zwar per DHCP versorgt, aber nicht routbar. Der Kern des Problems liegt häufig am Default Gateway (SVI oder Router-Subinterface), an Access Control Lists (ACLs), die Verkehr unerwartet blockieren, oder an inkonsistenten Layer-2/Layer-3-Übergängen. Inter-VLAN Routing verbindet Broadcast-Domänen logisch über Layer 3 – damit wird aus einem reinen Switching-Thema eine Kombination aus VLAN-Transport, Gateway-Konfiguration, ARP/Neighbor-Mechanik, Routing-Entscheidungen und Security-Policies. In diesem Leitfaden lernen Sie, wie Sie Inter-VLAN Routing systematisch analysieren: Sie prüfen zuerst, ob Clients im richtigen VLAN landen, dann ob das Gateway (SVI) erreichbar ist, anschließend ob Routing und Rückwege stimmen und zuletzt, ob ACLs, Firewall-Regeln oder VRFs den Verkehr begrenzen. Ziel ist ein praxistauglicher Standardablauf, mit dem IT-Teams Störungen schnell eingrenzen, Änderungen sauber verifizieren und wiederkehrende Fehler langfristig vermeiden.

Inter-VLAN Routing kurz erklärt: Was passiert zwischen VLANs?

VLANs trennen Layer-2-Broadcast-Domänen. Ein Client in VLAN 10 kann ohne Router/L3-Switch nicht direkt mit einem Server in VLAN 20 sprechen, selbst wenn beide am selben Switch hängen. Inter-VLAN Routing bedeutet, dass ein Layer-3-Gerät (L3-Switch, Router oder Firewall) als Gateway für jedes VLAN fungiert und Pakete zwischen den Subnetzen weiterleitet. Typischerweise wird pro VLAN ein Gateway bereitgestellt – entweder als SVI (Switch Virtual Interface) auf einem L3-Switch oder als Router-Subinterface (Router-on-a-Stick) auf einem Router/Firewall-Port.

• SVI: Virtuelles Layer-3-Interface auf dem Switch, gekoppelt an VLAN-ID und Subnetz (z. B. VLAN 10 → 10.10.10.1/24).
• Router-on-a-Stick: Ein physischer Routerport mit mehreren 802.1Q-Subinterfaces (z. B. Gi0/0.10, Gi0/0.20).
• Default Gateway: IP-Adresse im VLAN, an die Clients Pakete senden, die außerhalb des eigenen Subnetzes liegen.

Die VLAN-Tagging-Grundlage kommt aus IEEE 802.1Q (VLAN Bridging); für IP-Grundlagen ist RFC 791 (IPv4) eine solide Referenz.

Typische Symptome: Woran Sie Inter-VLAN Routing Probleme erkennen

Inter-VLAN Probleme wirken oft wie „Routing kaputt“, sind aber häufig eine Mischung aus VLAN-Zuordnung, Gateway-Erreichbarkeit und Security-Policies. Achten Sie auf diese Muster – sie führen oft direkt zur richtigen Hypothese.

• Gateway nicht pingbar: Client hat IP, aber kann 10.10.10.1 nicht erreichen → VLAN/L2/ARP oder SVI down.
• Gateway pingbar, aber anderes VLAN nicht: Routing/ACL/Firewall oder Rückroute fehlt.
• Nur bestimmte Ports/Dienste gehen: ACLs/Firewall-Regeln blocken selektiv (z. B. ICMP erlaubt, TCP/445 blockiert).
• Nur ein VLAN betroffen: SVI fehlt/down, VLAN nicht bis zum L3-Gerät transportiert, DHCP-Relay/Helper falsch.
• Sporadische Effekte: ARP/Neighbor instabil, IP-Konflikt, MAC-Flapping, STP/Link-Flapping.

Der wichtigste Grundsatz: Erst L2-Korrektheit, dann L3-Analyse

Inter-VLAN Routing scheitert häufig schon vor dem Routing: Der Client steckt im falschen VLAN oder der VLAN-Transport zum L3-Gateway ist unterbrochen. Deshalb gilt: Bevor Sie Routingtabellen und ACLs anfassen, prüfen Sie, ob der Client wirklich im erwarteten VLAN ist und das Gateway im gleichen Segment erreichbar ist.

• Client-IP/Subnetz passt zum VLAN-Design?
• Default Gateway korrekt gesetzt?
• Client-MAC wird im richtigen VLAN am erwarteten Switchport gelernt?
• VLAN wird über Trunks/Uplinks bis zum L3-Gerät transportiert (Allowed VLANs)?

SVI Troubleshooting: Wenn das Gateway „eigentlich da sein sollte“

Eine SVI ist das Herzstück des Inter-VLAN Routings auf Layer-3-Switches. Viele Störungen sind simpel: Die SVI ist administrativ down, das VLAN ist nicht aktiv, die IP ist falsch oder es gibt einen Duplicate Gateway. Eine SVI kann außerdem „operational down“ sein, wenn im VLAN kein aktiver Port existiert (plattformabhängig). Genau deshalb ist das Prüfen von SVI-Status und VLAN-Aktivität einer der schnellsten Diagnose-Schritte.

Häufige SVI-Fehlerquellen

• SVI administrativ deaktiviert: Interface ist shutdown oder nicht konfiguriert.
• VLAN nicht vorhanden/inkonsistent: VLAN-ID fehlt auf dem Switch oder nicht bis zum L3-Gerät erlaubt.
• VLAN „nicht aktiv“: keine aktiven Ports im VLAN (je nach Plattform bleibt SVI down).
• Falsche IP/Subnetzmaske: Gateway passt nicht zum Subnetz der Clients.
• Duplicate Gateway: ein weiteres Gerät nutzt dieselbe Gateway-IP (führt zu ARP-Flapping).
• VRF falsch: SVI in falscher VRF, Clients im Default VRF (oder umgekehrt).

Praktische Checks

• Gateway-Erreichbarkeit: Ping vom Client zur SVI-IP (z. B. 10.10.10.1).
• ARP/Neighbor: Hat der Client einen stabilen ARP-Eintrag zum Gateway? ARP-Grundlage: RFC 826 (ARP).
• MAC-Learning: Wird die Client-MAC im VLAN korrekt gelernt? Gibt es MAC-Flapping?
• VLAN-Transport: Trunks/Uplinks führen das VLAN wirklich (Allowed VLANs, kein Native-VLAN-Mismatch).

Gateway-Probleme: Wenn Clients zwar eine IP haben, aber „nicht rauskommen“

Das Default Gateway ist der erste Layer-3-Hop für Clients. Wenn hier etwas nicht stimmt, wirkt das Netzwerk „kaputt“, obwohl die Verbindung auf Layer 2 steht. Gateway-Probleme lassen sich oft sehr schnell eingrenzen, wenn Sie sauber zwischen „im Subnetz“ und „außerhalb“ unterscheiden: Alles im gleichen Subnetz braucht kein Routing, alles außerhalb braucht das Gateway.

Typische Gateway-Fehlerbilder

• Falsches Gateway per DHCP: Clients bekommen 10.10.10.254 statt 10.10.10.1 (Option 3 falsch).
• Gateway-IP doppelt: ARP zeigt wechselnde MACs für dieselbe Gateway-IP (Instabilität).
• Gateway erreichbar, aber nur ICMP: Ping klappt, Anwendungen nicht → ACL/Firewall oder stateful Policies.
• Gateway nur aus manchen Ports erreichbar: VLAN-Zuordnung/Trunk-Problem oder Security-Features (DAI/Port Security).

Der schnellste Beweis: Drei Pings in der richtigen Reihenfolge

• Ping 1: Client → eigenes Gateway (lokales VLAN ok?)
• Ping 2: Client → Ziel-IP in anderem VLAN (Inter-VLAN Routing ok?)
• Ping 3: Ziel-IP → Client-IP (Rückweg ok?)

Wenn Ping 2 scheitert, aber Ping 1 funktioniert, ist der Fehler oft Routing/ACL. Wenn Ping 2 klappt, aber Anwendungen scheitern, ist es häufig eine Policy- oder Port-Thematik.

ACLs und Firewall-Regeln: Wenn „Routing stimmt“, aber Traffic trotzdem nicht durchkommt

Zwischen VLANs wird Verkehr in vielen Unternehmen bewusst eingeschränkt: Mitarbeiternetze dürfen nicht auf IoT, Gäste dürfen nicht auf interne Server, Voice darf nur zu Call-Manager, und Management ist nur aus Admin-Netzen erlaubt. Diese Regeln werden als ACLs auf SVIs, als Policies auf Firewalls oder als zentrale Security-Zonen umgesetzt. Das führt zu einem typischen Troubleshooting-Fehler: Man prüft nur „ist die Route da“ – und übersieht, dass die Pakete zwar geroutet, aber anschließend verworfen werden.

Typische ACL-Fallen

• Nur ICMP erlaubt: Ping geht, TCP/UDP nicht – Nutzer melden „geht manchmal“.
• Reihenfolge und Implicit Deny: Eine „permit any“ fehlt am Ende, oder eine zu breite deny-Regel steht oben.
• Falsche Richtung: ACL inbound am SVI blockt bereits beim Eingang; outbound-Regeln werden anders gedacht.
• Stateful vs. stateless: Klassische ACLs sind stateless – Rückverkehr muss explizit erlaubt sein.
• Overlapping Subnets: ACL matcht falsche Netze, weil Adressierung inkonsistent ist.

Praktische Vorgehensweise bei Policy-Problemen

• Testen Sie gezielt Ports (z. B. TCP/443, TCP/3389) statt nur Ping.
• Prüfen Sie Logs: Firewalls und viele Switches können „deny hits“ zählen oder loggen.
• Nutzen Sie Referenz-Services: DNS, HTTPS, SSH – klar definierte Ports erleichtern Beweisführung.

Routing-Entscheidung auf dem L3-Gerät: Warum das richtige Ziel trotzdem falsch geroutet werden kann

Inter-VLAN Routing wirkt „lokal“, aber in größeren Umgebungen hängen VLANs an mehreren L3-Grenzen, VRFs oder Firewalls. Dann ist die Frage: Welcher Router/Switch ist für dieses VLAN wirklich das Gateway? Und wohin routet er den Verkehr weiter? Auch innerhalb eines Standorts kann „falsches Routing“ auftreten, wenn z. B. ein anderes Gerät eine spezifischere Route ankündigt oder wenn Policy-Based Routing (PBR) den Pfad verändert.

• Longest Prefix Match: spezifischste Route gewinnt (z. B. /24 vor /0).
• VRF-Segmentierung: Route existiert in VRF A, aber der Traffic ist in VRF B.
• PBR: Verkehr wird nicht nach Routing-Tabelle, sondern nach Policy weitergeleitet.
• Asymmetrie: Hinweg über L3-Switch, Rückweg über Firewall → stateful Geräte brechen Sessions.

DHCP Relay und „Clients im VLAN ohne funktionierendes Routing“

Ein häufiges Missverständnis: „DHCP funktioniert, also muss das VLAN ok sein.“ DHCP kann jedoch auch dann funktionieren, wenn Inter-VLAN Routing kaputt ist – etwa weil DHCP-Relay noch korrekt arbeitet oder weil ein lokaler DHCP-Server im VLAN antwortet, während das Gateway oder die ACLs Verkehr blocken. Daher ist DHCP nur ein Teilindikator, kein Beweis für funktionierendes Routing.

• DHCP ok, Gateway nicht pingbar: VLAN/Trunk/ARP/DAI oder Gateway-IP-Konflikt.
• DHCP ok, andere VLANs nicht erreichbar: ACLs oder Routing/Rückwege fehlen.
• DHCP fails nur in einem VLAN: VLAN nicht bis zum Relay/Gateway transportiert oder Helper falsch.

Der Standard-Workflow: Inter-VLAN Routing Troubleshooting Schritt für Schritt

Dieser Ablauf ist als Runbook gedacht. Er ist bewusst so strukturiert, dass Sie mit wenigen Tests schnell entscheiden, ob Sie bei VLAN/L2, SVI/Gateway, Routing oder ACLs ansetzen müssen.

Schritt: Client-Realität erfassen

• IP/Subnetz/Gateway/DNS am Client prüfen (DHCP-Server notieren).
• Stimmt das Subnetz zum vorgesehenen VLAN?
• Kann der Client das Default Gateway pingen?

Schritt: VLAN-Zuordnung und L2-Transport verifizieren

• Client-MAC im richtigen VLAN am richtigen Port gelernt?
• Ist der Access-Port im richtigen VLAN (kein falsches Portprofil)?
• Transportiert die Trunk-Kette das VLAN (Allowed VLANs, Tagging korrekt)?

Schritt: SVI/Gateway prüfen

• Existiert die SVI für das VLAN und ist sie operational up?
• Ist die IP/Subnetzmaske korrekt?
• Gibt es Hinweise auf Duplicate IP (ARP-Flapping für Gateway-IP)?

Schritt: Inter-VLAN Connectivity testen

• Testziel in anderem VLAN auswählen (z. B. Server oder Testhost).
• Ping/Traceroute nur als Indikator, danach Porttests (TCP/443, TCP/22, etc.).
• Wenn möglich: Test in beide Richtungen (Rückweg prüfen).

Schritt: ACLs/Firewall-Policies prüfen

• Gibt es ACLs am SVI (inbound/outbound)?
• Gibt es Firewall-Zonenregeln zwischen VLANs?
• Treffen die Regeln wirklich auf Quell- und Zielsubnetz/Ports zu?
• Gibt es Logs oder Hit-Counter, die die Blockade belegen?

Schritt: Routing/VRF/PBR prüfen

• Welche Route nutzt das Gateway zum Zielnetz (Longest Prefix Match)?
• Existiert die Rückroute vom Zielnetz zum Quellnetz?
• Ist der Traffic in der richtigen VRF?
• Gibt es PBR/Policy-Routing, das den Pfad verändert?

Schritt: Beweisführung und Nachmessung

• Vorher/Nachher-Messung mit identischen Tests (Gateway-Ping, Porttest, ggf. MTR/Traceroute).
• Counter/Logs sichern: ACL hits, Drops, ARP-Anomalien, Interface Errors.
• Änderung dokumentieren: was wurde geändert, warum, mit welchem Ergebnis.

Häufige Praxisfehler und wie Sie sie vermeiden

• Nur Ping testen: Ping ist hilfreich, aber ICMP kann erlaubt sein, während TCP/UDP blockiert sind.
• VLAN vs. Subnetz verwechseln: IP passt nicht zum VLAN, aber man debuggt „Routing“.
• Rückweg ignorieren: Hinweg funktioniert, Rückweg fehlt – stateful Firewalls brechen Sessions.
• Native VLAN unterschätzen: Untagged Frames auf Trunks erzeugen „Geisterprobleme“.
• Änderungen ohne Beweis: Ohne Messpunkte ist nicht klar, ob der Fix wirklich wirkt.

Best Practices: Inter-VLAN Routing dauerhaft stabil betreiben

• SVI-Standards: Namenskonvention, IP-Plan, VRF-Zuordnung, eindeutige Gateway-IP pro VLAN.
• Trunk-Standards: Allowed VLANs konsistent, Native VLAN bewusst, Port-Channels konsistent.
• ACL-Design: dokumentierte Zonen/Flows, stateless vs. stateful bewusst, Logging für kritische Denies.
• Monitoring: Gateway-Erreichbarkeit pro VLAN, ARP-Anomalien, Drops/Discards, ACL hit counters.
• Change-Disziplin: Nach VLAN- oder Policy-Änderungen standardisierte Tests ausführen.

Für allgemeine Grundlagen zu Routing und IP ist die strukturierte Dokumentation des RFC-Editors hilfreich, z. B. über RFC Editor als Startpunkt für Primärquellen.

Checkliste: Inter-VLAN Routing Troubleshooting für IT-Teams

• Client prüfen: IP/Subnetz/Gateway/DNS und DHCP-Server dokumentieren.
• Gateway prüfen: Ping zur SVI/Gateway-IP; ARP-Eintrag stabil?
• VLAN/L2 prüfen: Client-MAC im richtigen VLAN am richtigen Port; Trunks transportieren VLAN (Allowed VLANs/Tagging).
• SVI prüfen: existiert, up, richtige IP/Mask/VRF; keine Duplicate Gateway-IP.
• Inter-VLAN Test: Ping/Porttests zu Ziel in anderem VLAN; Rückweg testen.
• ACL/Firewall prüfen: inbound/outbound, implicit deny, Logs/Hit-Counter, stateful Besonderheiten.
• Routing prüfen: Longest Prefix Match, VRF, PBR, Rückrouten/Asymmetrie.
• Fix verifizieren: Vorher/Nachher identisch testen; Counter/Logs prüfen.
• Dokumentieren: Ursache, betroffene VLANs/SVIs/Policies, Änderung, Ergebnis, Präventionsmaßnahme.

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.