Routing-Tabelle prüfen: Die wichtigsten Checks bei L3-Problemen

Wenn Layer-3-Kommunikation hakt, ist das Routing-Tabelle prüfen fast immer der schnellste Weg zur Ursache. Viele L3-Probleme wirken auf den ersten Blick wie „Netzwerk down“: Anwendungen erreichen Server nicht, Standorte sind voneinander getrennt, Internetzugang ist sporadisch oder nur einzelne Subnetze sind betroffen. In der Praxis liegt die Ursache häufig nicht an der Leitung selbst, sondern an der Frage: Wohin schickt das Gerät Pakete für dieses Ziel? Genau das beantwortet die Routing-Tabelle. Sie ist die zentrale Entscheidungsmatrix jedes Routers, Layer-3-Switches, jeder Firewall und auch jedes Clients. Wer Routing-Tabellen systematisch lesen kann, findet Fehler schneller, vermeidet unnötige Änderungen und kann Ergebnisse sauber belegen. In diesem Artikel erhalten Sie einen praxiserprobten Leitfaden mit den wichtigsten Checks bei L3-Problemen: von Default Route und Longest Prefix Match über Next-Hop-Validierung, Interface-Zustände, VRFs und Policy-Based Routing bis hin zu typischen Fallen wie asymmetrischem Routing, Route Leaks oder ECMP. Ziel ist ein Standardablauf, den Sie im Betrieb wiederholen können – unabhängig vom Hersteller.

Warum L3-Probleme oft „unsichtbar“ sind

Layer 3 ist logisch, nicht physisch. Eine Verbindung kann auf Layer 1/2 einwandfrei sein (Link up, VLAN korrekt), und trotzdem scheitert die Kommunikation, weil die Pakete nicht den richtigen Weg nehmen. Zudem können L3-Probleme selektiv sein: Ein Zielnetz ist erreichbar, ein anderes nicht; Ping geht, aber Anwendungen nicht; oder nur der Rückweg fehlt. Genau deshalb ist eine Routing-Tabelle kein „Nice-to-have“, sondern das Diagnosewerkzeug Nummer eins. Sobald Sie den Pfad-Entscheidungen der Geräte folgen, lassen sich Probleme oft in Minuten statt Stunden lösen.

Routing-Tabelle verstehen: Die minimale Theorie, die Sie wirklich brauchen

Eine Routing-Tabelle besteht aus Einträgen (Routes) mit Zielpräfix (z. B. 10.10.20.0/24), einem Next Hop (nächster Router) oder einem Ausgangsinterface, sowie Bewertungsinformationen wie Administrative Distance (AD) und Metrik. Die wichtigste Regel lautet: Longest Prefix Match. Das Gerät wählt die Route mit dem spezifischsten Präfix, also dem längsten passenden Netzanteil. Ein /24 gewinnt gegen ein /16, ein /32 (Hostroute) gewinnt gegen alles andere.

• Connected Route: Direkt angeschlossenes Netz (Interface/SVI im Subnetz).
• Static Route: Manuell gesetzt (z. B. für Default Route oder Sonderpfade).
• Dynamic Route: Via Routingprotokoll gelernt (OSPF, BGP, EIGRP, IS-IS).
• Default Route: 0.0.0.0/0 (IPv4) bzw. ::/0 (IPv6) als „Fallback“.

Für grundlegende IP-Routing-Prinzipien ist RFC 1812 (Requirements for IPv4 Routers) eine gute Referenz; die IPv4-Basis ist in RFC 791 dokumentiert.

Die 10 wichtigsten Checks, wenn Sie die Routing-Tabelle prüfen

Check: Gibt es überhaupt eine passende Route zum Ziel?

Das klingt trivial, ist aber der häufigste Befund: Das Zielnetz ist nicht in der Routing-Tabelle. Dann wird entweder die Default Route verwendet (wenn vorhanden) oder das Paket verworfen. Besonders oft passiert das bei neuen VLANs/Subnetzen, nach Migrationen oder wenn Route-Advertisements fehlen.

• Ist das Zielpräfix vorhanden (z. B. 10.10.20.0/24)?
• Wenn nicht: Gibt es eine Default Route, die es trotzdem „irgendwohin“ schickt?
• Wenn ja: Ist das gewollt oder erzeugt es Blackholing?

Check: Longest Prefix Match – gewinnt die „richtige“ Route?

Viele L3-Probleme entstehen, weil eine spezifischere Route unerwartet gewinnt. Beispiele: Eine alte /32-Hostroute zeigt auf einen stillgelegten Router. Oder ein /24 wird via BGP angekündigt, obwohl intern OSPF ein /16 kennt. Longest Prefix Match ist gnadenlos – und oft die Erklärung für „aber die Route ist doch da“.

• Gibt es mehrere passende Routen für das Ziel?
• Welche Route ist die spezifischste (größte Präfixlänge)?
• Ist diese Route aktuell und korrekt?

Check: Next Hop ist erreichbar und rekursiv auflösbar

Eine Route ist nur so gut wie ihr Next Hop. Wenn der Next Hop nicht erreichbar ist, ist die Route in vielen Systemen zwar sichtbar, aber faktisch unbrauchbar. Prüfen Sie daher immer rekursiv: Wie erreicht das Gerät den Next Hop selbst? Liegt dafür eine Connected Route vor? Gibt es ARP/Neighbor-Auflösung?

• Ist der Next Hop im selben Subnetz (direkt erreichbar) oder rekursiv über eine andere Route?
• Existiert ein gültiger ARP/Neighbor-Eintrag zum Next Hop (bei direkt angeschlossenen Netzen)?
• Ist das Ausgangsinterface up/up und nicht administrativ down?

Check: Ausgangsinterface und L2-Übergang prüfen

Routing endet oft an Layer 2. Ein Router kann die perfekte Route haben – wenn das Ausgangsinterface in einem falschen VLAN hängt oder STP/Trunk-Probleme vorliegen, kommt trotzdem nichts an. Deshalb gehört zur Routing-Tabellenprüfung immer ein kurzer Blick auf das Interface und seine Layer-2-Umgebung.

• Ist das Interface/SVI up und im richtigen VLAN?
• Gibt es Link-Flapping oder hohe Error-Counter?
• Bei SVIs: Ist das VLAN aktiv (Ports im VLAN vorhanden)?

Check: Administrative Distance und Metrik – welche Quelle gewinnt wirklich?

Wenn mehrere Routen mit gleicher Präfixlänge existieren, entscheidet das Gerät nach „Vertrauenswürdigkeit“ (Administrative Distance) und/oder Metrik. Wenn z. B. eine statische Route und eine dynamische Route konkurrieren, gewinnt häufig die mit geringerer AD. Dadurch kann eine „Notfallroute“ plötzlich aktiv werden, obwohl ein Routingprotokoll eigentlich korrekte Wege anbietet.

• Ist eine statische Route als „Floating Static“ gedacht (bewusst höhere AD), aber hat versehentlich eine niedrige AD?
• Hat ein IGP plötzlich eine schlechtere Metrik und wird verdrängt?
• Gibt es Route-Redistribution, die Metriken verfälscht?

Check: ECMP und Load-Balancing – wenn „mal geht, mal nicht“

Equal-Cost Multi-Path (ECMP) verteilt Traffic über mehrere gleichwertige Routen. Das ist normal und oft gewünscht. Problematisch wird es, wenn einer der ECMP-Pfade kaputt ist oder asymmetrisch wird. Dann erleben Sie intermittierende Fehler: Manche Flows funktionieren, andere nicht – abhängig vom Hashing.

• Existieren mehrere Next Hops für dasselbe Präfix (gleichwertige Routen)?
• Ist jeder Pfad wirklich gesund (Interface, Next Hop, Rückweg)?
• Ändert sich das Verhalten je nach Quellhost oder Port (Hashing-Indiz)?

Check: Rückweg und asymmetrisches Routing

Viele „Routing-Probleme“ sind eigentlich Rückweg-Probleme. Der Hinweg findet das Ziel, aber die Antwort nimmt einen anderen Pfad oder findet keinen Weg zurück. Besonders kritisch ist das bei stateful Firewalls und NAT: Wenn Hinweg über Firewall A und Rückweg über Firewall B geht, werden Sessions oft verworfen („out of state“). Asymmetrie entsteht häufig bei Dual-WAN, SD-WAN, PBR oder unvollständigen Routen.

• Hat das Zielnetz eine Route zurück zum Quellnetz?
• Geht der Rückweg über das gleiche Security-Gateway (bei stateful Geräten)?
• Gibt es Policy-Based Routing, das nur eine Richtung beeinflusst?

Check: VRF/Segmentation – prüfen Sie die richtige Routing-Tabelle

In modernen Netzen gibt es nicht „die eine“ Routing-Tabelle. VRFs trennen Routing-Domänen, damit z. B. Gäste, IoT und Produktion logisch isoliert bleiben. Ein häufiger Fehler: Sie prüfen die Routing-Tabelle im Default VRF, aber der Traffic läuft in VRF „GUEST“ oder „WAN“. Dann wirkt es so, als gäbe es „keine Route“, obwohl sie in einer anderen Tabelle existiert.

• In welcher VRF liegt das Interface/SVI der Quelle?
• In welcher VRF liegt das Ziel oder der Uplink?
• Gibt es Route Leaks/Import-Export-Regeln, die gewollt oder ungewollt wirken?

Check: PBR/Policy Routing – wenn die Routing-Tabelle ignoriert wird

Policy-Based Routing (PBR) oder SD-WAN Policies können die normale Routing-Entscheidung übersteuern. Dann ist die Routing-Tabelle zwar korrekt, aber Traffic wird nach Policy in einen anderen Next Hop geschickt. Typische Symptome: Nur bestimmte Anwendungen oder Portgruppen sind betroffen, oder nur Traffic aus einem bestimmten Subnetz.

• Gibt es PBR/SD-WAN-Regeln auf dem Eingangsinterface?
• Matchen die Regeln auf Port/DSCP/Applikation und ändern den Next Hop?
• Ist der Policy-Pfad vollständig (inkl. Rückweg und NAT/Firewall-Policies)?

Check: Blackhole/Null Routes und Summary-Routen

Blackhole-Routen (Null0/Discard) werden oft bewusst eingesetzt, z. B. für Summaries oder DDoS-Mitigation. Wenn jedoch ein Summary falsch gesetzt ist oder spezifische Routen fehlen, „verschluckt“ ein Blackhole Traffic. Das führt zu klaren Symptomen: Pakete verschwinden, Traceroute endet abrupt, und es gibt keine Antwort.

• Gibt es Null/Discard-Routen, die das Zielpräfix (oder ein übergeordnetes Summary) matchen?
• Fehlen spezifischere Routen, die eigentlich über dem Blackhole liegen müssten?
• Ist die Summary-Strategie konsistent (IGP/BGP Redistribution)?

Praktische Tools: Welche Kommandos wirklich helfen

Die Befehle unterscheiden sich je Plattform, aber das Prinzip ist immer gleich: Route Lookup, Interface-Status, ARP/Neighbor, und bei Bedarf Traceroute. Unter Linux ist die Manpage zu ip-route(8) eine gute Referenz, um Routing-Tabellen und Policy Rules zu verstehen. Für Traceroute als Pfadindikator gilt: Es zeigt nicht immer den exakten Datenpfad (ICMP/TTL-Verhalten), ist aber hervorragend, um „wo endet es?“ zu beantworten.

• Route Lookup: „show ip route <ziel>“ oder „ip route get <ziel>“ (plattformabhängig)
• Interface Status: „show interfaces“ / „show ip interface brief“ / „ip link“
• ARP/Neighbor: „show arp“ / „ip neigh“ (zeigt L2-Erreichbarkeit zum Next Hop)
• Traceroute/MTR: Pfadindikator und Paketverlust/Latenz über Hops

Die häufigsten L3-Fallen, die beim Routing-Tabelle prüfen auffallen

Falsche Default Route oder fehlender Default

Ohne Default Route kann ein Netzsegment nicht „ins Unbekannte“ routen. Mit einer falschen Default Route routet es ins Leere. Beides führt zu typischen Aussagen wie „Intern geht, Internet nicht“ oder „Nur bestimmte Ziele gehen“. Prüfen Sie die Default Route daher immer explizit, insbesondere nach Providerwechseln, HA-Failover oder SD-WAN-Umstellungen.

Überlappende oder doppelte Subnetze

Überlappende RFC1918-Adressräume (z. B. 10.0.0.0/8 an mehreren Orten) führen zu schwer verständlichen Routings. Die Routing-Tabelle kann „korrekt“ sein – aber das falsche Zielnetz wird gematcht. Das tritt häufig bei Firmenzusammenschlüssen, Partner-VPNs oder Multi-Cloud-Anbindungen auf.

Route Redistribution mit Nebenwirkungen

Wenn OSPF in BGP redistribuiert wird (oder umgekehrt), können unerwartete Routen entstehen, die Longest Prefix Match oder AD/Metrik-Entscheidungen kippen. Typische Symptome: Pfade ändern sich nach Changes, oder ein Standort zieht plötzlich Traffic an, der nicht zu ihm gehört. Hier helfen Route Policies/Filters und saubere Summaries.

Statische Routen als „Quick Fix“, die später stören

Ein häufiger Operativfehler: Eine Störung wird mit einer statischen Route „umgangen“, die später vergessen wird. Wochen später gewinnt diese Route aufgrund AD/Prefix und verursacht neue Störungen. Beim Routing-Tabelle prüfen sollten Sie daher immer fragen: Welche statischen Routen sind historisch und warum existieren sie?

Ein reproduzierbarer Diagnose-Ablauf für L3-Probleme

Wenn Sie einen Standardablauf benötigen, der in nahezu jeder Umgebung funktioniert, nutzen Sie dieses Schema. Es basiert auf dem Gedanken, dass jedes Routing-Problem eine klare „Entscheidung“ an einem Knoten hat.

Schritt: Problem präzisieren

• Welche Quelle (IP/Subnetz) kann welches Ziel (IP/Subnetz) nicht erreichen?
• Ist es nur ein Dienst/Port oder jeglicher IP-Verkehr?
• Seit wann? Nach welchem Change?

Schritt: Source-Gateway prüfen

• Kann die Quelle ihr Default Gateway erreichen?
• Ist die Quelle im richtigen VLAN/Subnetz?
• Gibt es ARP-Anomalien oder IP-Konflikte?

Schritt: Route Lookup am ersten L3-Hop

• Welche Route wird für das Ziel tatsächlich gewählt (Longest Prefix Match)?
• Welcher Next Hop/Interface ist eingetragen?
• Ist der Next Hop erreichbar (ARP/Neighbor, Interface up)?

Schritt: Iteration hop-by-hop bis zum Ziel

• Wiederholen Sie den Route Lookup auf dem nächsten Router/L3-Switch.
• Identifizieren Sie den Knoten, an dem die Route fehlt oder in einen falschen Pfad kippt.
• Prüfen Sie dort VRF/PBR/ACL/Firewall-Policies als mögliche Übersteuerung.

Schritt: Rückweg verifizieren

• Route Lookup vom Ziel zurück zur Quelle.
• Asymmetrie prüfen, besonders bei stateful Firewalls und NAT.
• Bei VPN/Cloud: Route Leaks und Security Policies berücksichtigen.

Outbound-Links für vertiefende Referenzen

• RFC 1812: Anforderungen an IPv4-Router (Routing-Verhalten, Weiterleitung, ICMP)
• RFC 791: IPv4-Grundlagen
• ip-route(8): Routing-Tabellen und Policy Routing unter Linux
• RFC 3022: Traditional NAT (relevant bei Edge-Routing und Rückwegproblemen)

Checkliste: Routing-Tabelle prüfen bei L3-Problemen

• Zielroute vorhanden? Wenn nicht: Default Route vorhanden oder Drop?
• Longest Prefix Match: Welche Route gewinnt tatsächlich (Spezifität prüfen)?
• Next Hop erreichbar: ARP/Neighbor, rekursive Auflösung, Interface up?
• Richtige Tabelle: VRF/VRF-Lite korrekt, nicht im falschen Kontext prüfen.
• AD/Metrik: Gewinnt die richtige Quelle (statisch/dynamisch), Floating Statics korrekt?
• ECMP: Mehrere Pfade? Ist jeder Pfad gesund? Intermittierende Fehler möglich.
• Rückweg: Gibt es eine Route zurück? Asymmetrie bei stateful Geräten vermeiden.
• PBR/SD-WAN: Übersteuert eine Policy die Routing-Tabelle?
• Blackhole/Null Routes: Gibt es Discard-Summaries, die Traffic schlucken?
• Vorher/Nachher belegen: Route Lookup, Interface-Status und Counter mit Zeitstempel dokumentieren.

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.