Layer 3 Troubleshooting: Routing-Probleme sauber analysieren

Layer 3 Troubleshooting ist die Disziplin, mit der Sie Routing-Probleme sauber analysieren, statt sich von Symptomen wie „kein Zugriff“, „nur manche Netze gehen“ oder „VPN ist langsam“ in die Irre führen zu lassen. Sobald ein Paket ein Subnetz verlassen soll, entscheidet Layer 3 über den Weg: Welche Route wird genutzt, über welches Gateway, in welcher VRF, mit welcher Policy? Ein kleiner Fehler – eine fehlende Rückroute, eine falsche Standardroute, ein fehlerhaftes Routing-Filter oder ein MTU-Thema im Tunnel – kann ganze Anwendungen lahmlegen, während DNS, Switches und WLAN scheinbar stabil wirken. Genau deshalb ist ein strukturierter Ansatz entscheidend: Sie prüfen zuerst die lokale IP-Basis (Adresse, Maske, Gateway), dann die Routing-Entscheidung (Longest Prefix Match, Metrik/Administrative Distance), danach den Pfad (Traceroute/MTR) und schließlich Spezialfälle wie asymmetrisches Routing, NAT, VRFs, ECMP und PMTUD. In diesem Leitfaden lernen Sie praxisnah, wie Sie Routing-Probleme nachvollziehbar eingrenzen, welche Messpunkte wirklich aussagekräftig sind und welche typischen Fehlerbilder in Unternehmensnetzwerken am häufigsten auftreten.

Layer 3 verstehen: Was Routing wirklich macht

Auf Layer 3 geht es um IP-Weiterleitung zwischen Netzen. Ein Router (oder ein Layer-3-Switch/Firewall) entscheidet anhand seiner Routing-Tabelle, wohin ein Paket als Nächstes gesendet wird. Die Entscheidung folgt in klassischen IP-Netzen dem Prinzip „Longest Prefix Match“: Die spezifischste Route (mit dem längsten Präfix) gewinnt. Danach kommen Metriken, Administrative Distances und – in komplexen Umgebungen – VRFs oder Policy-Based Routing. Die wichtigste Konsequenz fürs Troubleshooting: Wenn Sie wissen, welche Route ein Gerät nutzt, können Sie sehr schnell prüfen, ob der Pfad logisch überhaupt funktionieren kann.

• Routing-Tabelle: Liste bekannter Netze und Next Hops (oder Interfaces).
• Longest Prefix Match: spezifischste Route gewinnt (z. B. /24 vor /0).
• Default Route: „Route ins Unbekannte“ (0.0.0.0/0 bzw. ::/0).
• Rückroute: Ohne Rückweg ist ein Erfolg oft nur scheinbar oder gar nicht möglich.
• MTU/PMTUD: Große Pakete müssen den Pfad passieren können, sonst entstehen „komische“ Timeouts.

Für IPv4-Grundlagen ist RFC 791 (IPv4) eine robuste technische Referenz, für ICMP als Diagnosebaustein RFC 792 (ICMP).

Bevor Sie Layer 3 debuggen: Layer 1 und Layer 2 kurz ausschließen

Routing-Probleme werden häufig vermutet, obwohl die Ursache darunter liegt: falsches VLAN, defektes Kabel, Port-Errors oder ARP-Anomalien. Für sauberes Layer 3 Troubleshooting reicht ein kurzer Realitätscheck: Ist das Interface up? Ist das Endgerät im richtigen VLAN? Ist das Default Gateway erreichbar? Erst wenn diese Basics stimmen, lohnt es sich, Routingtabellen und Protokolle zu analysieren.

• Link/Interface up? Keine auffälligen Errors/Drops?
• Client hat eine IP im erwarteten Subnetz?
• Default Gateway ist pingbar (lokal erreichbar)?
• Keine IP-Konflikte (ARP zeigt stabile MAC-Zuordnung)?

Zum Verständnis des ARP-Übergangs (IPv4 im LAN) ist RFC 826 (ARP) hilfreich.

Der wichtigste Grundsatz: Routing ist immer Hinweg und Rückweg

Viele Routing-Fehler entstehen nicht, weil der Hinweg fehlt, sondern weil der Rückweg fehlt oder über einen anderen Pfad läuft. Das Ergebnis ist oft asymmetrisches Routing: Paket A geht von Client zu Server über Router 1, die Antwort geht über Router 2 zurück. In Netzen mit stateful Firewalls oder NAT ist das häufig fatal, weil die Rückpakete nicht zum passenden State passen oder weil NAT-Translationen nicht gefunden werden. Deshalb gehört zur Standarddiagnose immer: „Gibt es eine Rückroute vom Zielnetz zum Quellnetz?“

• Symptom: Ping funktioniert manchmal, TCP-Verbindungen hängen oder brechen ab.
• Typischer Befund: Traceroute zeigt unterschiedliche Pfade je Richtung (oder je Standort).
• Best Practice: Immer sowohl aus Quell- als auch aus Zielperspektive prüfen (wenn möglich).

Toolbox für Layer 3 Troubleshooting

Sie brauchen keine riesige Werkzeugkiste, sondern klare Werkzeuge für klare Fragen: Ist ein Netz erreichbar? Welche Route wird genutzt? Wo endet der Pfad? Wird DNS verwechselt mit Routing? Die folgenden Tools reichen in den meisten Umgebungen aus.

• ipconfig/ip: IP, Gateway, DNS, Interface-Status am Client prüfen. Referenzen: ipconfig und ip(8).
• Ping: Basis-Erreichbarkeit und Latenzindikator. Referenz: Windows ping.
• Traceroute/Tracert: Pfad-Hops und Abbruchstelle erkennen. Referenz: Windows tracert.
• MTR: Pfadstatistik über Zeit, ideal bei sporadischen Problemen. Referenz: mtr(8).
• Routing-Table/Protokollstatus: „show route“, „show ip route“, „ip route“, je nach Plattform.
• Paketmitschnitt: Wireshark/tcpdump, wenn Handshakes, PMTUD oder Retransmissions bewiesen werden müssen. Einstieg: Wireshark-Dokumentation.

Routing-Probleme systematisch eingrenzen: Der praxiserprobte Ablauf

Ein strukturierter Ablauf verhindert, dass Sie im Kreis laufen. Der Kern ist Segmentierung: Sie testen Schritt für Schritt vom Client bis zum Ziel – und parallel die logische Routing-Entscheidung auf den beteiligten Geräten.

Schritt: Lokale IP-Basis verifizieren

• IP-Adresse und Subnetzmaske korrekt?
• Default Gateway im gleichen Subnetz und erreichbar?
• DNS ist nicht das Problem? (Test mit externer IP vs. Domain)

Schritt: Ziel in Kategorien einteilen

• Im gleichen Subnetz: Dann ist es kein Routing-Problem, sondern eher Layer 2/ARP.
• In anderem internen Subnetz: Inter-VLAN-Routing/Core-Routen prüfen.
• Extern/Internet: Default Route, NAT, WAN-Edge, Providerpfad prüfen.
• Über VPN/SD-WAN: Tunnel-Routen, Policy, MTU/MSS, Rekeying/State prüfen.

Schritt: Pfad messen, aber richtig interpretieren

• Ping zu Gateway, dann zu einem Router-Hop, dann zum Ziel.
• Traceroute: Wo endet der Pfad? Wo steigt die Latenz dauerhaft?
• MTR bei sporadischen Problemen, aber „Loss in der Mitte“ kritisch interpretieren.

Schritt: Routing-Entscheidung auf dem entscheidenden Hop prüfen

• Welche Route matcht das Zielpräfix (Longest Prefix Match)?
• Next Hop erreichbar? ARP/NDP ok?
• Ist die Route aktiv oder nur im RIB, aber nicht im FIB (platform-spezifisch)?
• Wird durch Policy-Based Routing oder VRF eine andere Tabelle genutzt?

Die häufigsten Routing-Fehlerbilder und ihre Ursachen

Fehlende oder falsche Default Route

Wenn interne Netze erreichbar sind, aber alles Externe nicht, ist die Default Route ein Top-Kandidat. In Unternehmensumgebungen kann die Default Route absichtlich nur auf bestimmten VRFs oder nur auf dem WAN-Edge existieren. Fehler entstehen bei Änderungen, Failover oder wenn ein dynamisches Routingprotokoll Default nicht mehr announct.

• Symptom: Intern ok, Internet tot (oder nur über bestimmte Router/Standorte).
• Prüfung: Existiert 0.0.0.0/0? Zeigt sie auf den richtigen Next Hop?
• Fix: Default Route korrekt setzen/announcen, Failover-Logik prüfen.

Fehlende Rückroute oder falsche Summarization

Ein Klassiker: Der Server hat eine Route zum Clientnetz nicht, oder ein Router fasst Netze falsch zusammen (Summarization) und schickt Rückverkehr in die falsche Richtung. Das fällt oft erst bei bestimmten Subnetzen auf.

• Symptom: Verbindungsaufbau hängt, ACKs fehlen, nur manche Subnetze betroffen.
• Prüfung: Rückroute am Zielgateway/Firewall prüfen, Traceroute „von der anderen Seite“.
• Fix: Routen ergänzen, Summary korrigieren, Filter/Redistribution überprüfen.

Asymmetrisches Routing in Kombination mit stateful Firewalls/NAT

Asymmetrie ist nicht per se falsch, aber bei stateful Geräten häufig problematisch. NAT verschärft das, weil Übersetzungen nur dort existieren, wo sie erstellt wurden. Wenn Rückverkehr über ein anderes Gerät geht, scheitert die Session.

• Symptom: Sporadische Ausfälle, besonders bei Failover, ECMP oder Multi-Uplink.
• Prüfung: Session-Logs/NAT-States, Pfadvergleich, ECMP-Hashing.
• Fix: Symmetrie erzwingen (Policy/Design), State-Synchronisation prüfen, ECMP bewusst steuern.

Routing-Filter, Redistribution-Fehler, „Route fehlt nur im einen Protokoll“

In Netzen mit OSPF/BGP/EIGRP/ISIS entstehen Probleme oft nicht durch Linkausfall, sondern durch Policy: Prefix-Lists, Route-Maps, Redistribution-Regeln oder Max-Prefix Limits. Dann ist das Netz physisch erreichbar, aber die Route kommt nicht an.

• Symptom: Route existiert lokal, aber nicht auf anderen Routern; nur bestimmte Präfixe fehlen.
• Prüfung: Routen-Advertisments und Filterregeln prüfen, „show route received/advertised“.
• Fix: Filter korrigieren, Redistribution gezielt und dokumentiert anpassen.

VRF/Segmentierungsfehler: Route existiert, aber in der falschen Tabelle

In modernen Umgebungen ist VRF (oder ähnliche Segmentierung) Standard. Ein häufiges Fehlerbild: Die Route ist vorhanden, aber in der falschen VRF; oder ein Interface ist der falschen VRF zugeordnet. Für den Admin wirkt es wie „Routing kaputt“, obwohl es ein Segmentierungsproblem ist.

• Symptom: Ping innerhalb der VRF ok, aber Cross-VRF nicht; oder Dienste sind „nur in einem Segment“ erreichbar.
• Prüfung: VRF-Zuordnung von Interfaces, Routing-Table pro VRF, Leaking-Regeln.
• Fix: VRF korrekt zuordnen, Route-Leaking sauber definieren, Policies dokumentieren.

MTU/PMTUD-Probleme: „Manche Dinge gehen, manche nicht“

Routing kann perfekt aussehen, aber große Pakete scheitern. Dann laden kleine Seiten, während große Uploads oder bestimmte TLS-Verbindungen hängen. Ursache ist oft eine zu kleine MTU in Tunneln oder blockiertes PMTUD (ICMP Fragmentation Needed). Das ist ein typischer Layer-3-„Sonderfall“, der sich wie ein Applikationsproblem tarnt.

• Symptom: Bestimmte Websites/Apps hängen, große Transfers brechen ab, VPN instabil.
• Prüfung: MTU testen (DF-Bit), ICMP-Meldungen prüfen, MSS-Clamping-Settings.
• Fix: Tunnel-MTU korrekt setzen, MSS clampen, ICMP für PMTUD policy-konform erlauben.

Traceroute richtig nutzen: Was es zeigt und was nicht

Traceroute ist bei Routing-Problemen extrem nützlich, aber nur, wenn Sie es richtig interpretieren. „Sternchen“ bedeuten oft ICMP-Filterung oder Rate-Limiting, nicht zwingend einen Ausfall. Entscheidend ist: Wo endet der Pfad wirklich? Und bleibt ein Latenzsprung bis zum Ziel bestehen? Für Windows ist die Optionserklärung in Microsofts tracert-Dokumentation hilfreich.

• Abbruch früh: lokales Routing/ACL/Firewall oder Next Hop unreachable.
• Abbruch am WAN-Edge: Provider-Link, Default Route, NAT/Policy.
• Abbruch „draußen“: Provider/Peering/Zielnetz; dokumentieren und eskalieren.
• Sternchen in der Mitte: oft unkritisch, wenn Ziel trotzdem erreichbar ist.

Praxisfälle: Routing-Probleme schnell enttarnen

Fall: Nur ein Subnetz erreicht den Server nicht

• Wahrscheinlich: Rückroute fehlt oder Filter blockiert genau dieses Präfix.
• Check: Route auf Server-Gateway/Firewall, Prefix-Lists/Policies, Traceroute von beiden Seiten.
• Fix: Route ergänzen/announcen, Filter anpassen, Summaries prüfen.

Fall: Nach Failover sind Verbindungen instabil

• Wahrscheinlich: Asymmetrie, ECMP-Hash, State/NAT nicht synchron.
• Check: Pfadvergleich, Session-/NAT-Logs, ECMP-Policies.
• Fix: Symmetrie erzwingen, State-Sync prüfen, Failover-Design überarbeiten.

Fall: VPN steht, aber bestimmte Apps hängen

• Wahrscheinlich: MTU/MSS oder Split-Tunnel-Routen fehlen.
• Check: MTU-Tests, MSS-Clamping, Routen im Tunnel, DNS/Split-DNS.
• Fix: Tunnel-MTU/MSS sauber, Routen/Policies korrigieren.

Dokumentation und E-E-A-T im Troubleshooting: So arbeiten Profis

Routing-Probleme lösen Sie schneller, wenn Sie sauber dokumentieren: Welche Quelle, welches Ziel, welches Subnetz, welcher Zeitpunkt, welcher Pfad? Bei Provider- oder Hersteller-Eskalationen sind diese Daten entscheidend. Gute Dokumentation besteht nicht aus „geht nicht“, sondern aus überprüfbaren Fakten.

• Scope: Welche Netze/Ziele sind betroffen? Welche funktionieren?
• Messpunkte: Client, Gateway, Zwischenrouter, Zielsystem.
• Beweise: Traceroute/MTR, Routing-Table-Auszüge, Logs (Zeitstempel).
• Änderungen: Was wurde geändert, warum, mit welchem Ergebnis?

Best Practices: Routing-Probleme langfristig vermeiden

Viele Layer-3-Incidents entstehen durch fehlende Standards: unklare Summaries, „wildes“ Redistribution, ungetestete Filter, unübersichtliche VRFs oder fehlende Baselines. Mit wenigen Maßnahmen reduzieren Sie die Häufigkeit massiv.

• Adress- und Routing-Design dokumentieren: VRFs, Summaries, Default-Handling, Transit-Netze.
• Änderungen testen: Vorher/Nachher-Pfade, Route-Visibility, Rückwege.
• Monitoring: BGP/OSPF Nachbarschaften, Route-Counts, Link-Status, Latenz zu Kernzielen.
• Policy-Governance: Prefix-Lists/Route-Maps mit Review-Prozess und klarer Namenskonvention.
• MTU-Standards: Tunnel-Design mit definierter MTU/MSS, PMTUD policy-konform ermöglichen.

Checkliste: Layer 3 Troubleshooting in der richtigen Reihenfolge

• IP-Basis prüfen: IP/Subnetz/Gateway korrekt, Gateway erreichbar.
• Segmentieren: gleiches Subnetz (kein Routing) vs. anderes Subnetz (Routing) vs. Internet (Default/NAT).
• Pfad messen: Ping/Traceroute, bei sporadisch MTR über Zeit.
• Routing-Entscheidung prüfen: Longest Prefix Match, Next Hop erreichbar, richtige VRF.
• Rückroute prüfen: Zielnetz kennt den Weg zurück? Asymmetrie ausgeschlossen?
• Policies prüfen: Filter, Redistribution, PBR, ECMP-Verhalten.
• Edge prüfen: NAT/Stateful Firewall, Session-Timeouts, Failover-Sync.
• MTU/PMTUD prüfen: große Pakete, Tunnel-MTU, MSS-Clamping.
• Beweise dokumentieren: Zeiten, Outputs, Pfade, betroffene Präfixe.

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.