Routing-Blackhole: Identifikation mit Traceroute + Routing-Table-Check

Ein Routing-Blackhole gehört zu den frustrierendsten Fehlerbildern im Betrieb: Der Zielhost „existiert“, DNS stimmt, manchmal geht sogar ein Ping bis zu einem bestimmten Punkt – und trotzdem verschwinden Pakete irgendwo im Netz, ohne dass eine saubere Fehlermeldung zurückkommt. Genau deshalb sind zwei Werkzeuge in Kombination so wirkungsvoll: Traceroute zeigt Ihnen, wo ein Pfad sichtbar endet oder sich merkwürdig verhält, und der Routing-Table-Check zeigt, warum ein Router an dieser Stelle anders weiterleitet (oder gar nicht weiterleiten kann). In der Praxis scheitern viele Analysen daran, dass Traceroute isoliert betrachtet wird: „Hop 7 antwortet nicht, also ist Hop 7 kaputt.“ Das ist häufig falsch, weil ICMP-TTL-Exceeded bewusst gefiltert sein kann oder ECMP-Pfade variieren. Umgekehrt ist ein Routing-Table-Check ohne Pfadkontext oft zu abstrakt: Tabellen sind voll mit VRFs, Policies und Overlays, und man verliert die konkrete Fehlerdomäne aus dem Blick. Dieser Artikel zeigt Ihnen ein praxistaugliches Vorgehen, um Routing-Blackholes sicher zu identifizieren: wie Traceroute technisch funktioniert, wie Sie Hops und Timeouts richtig interpretieren, welche Routing-Tabellenfelder wirklich relevant sind (Longest Prefix Match, Next Hop, Recursion, RIB/FIB, VRF), und wie Sie aus beiden Sichtweisen eine belastbare Root-Cause-Hypothese ableiten.

Was ein Routing-Blackhole tatsächlich ist

Von einem Routing-Blackhole spricht man, wenn Pakete zwar an einen Router übergeben werden, aber unterwegs „verschluckt“ werden – ohne dass der Absender eine aussagekräftige Rückmeldung erhält. Der Abbruch kann auf mehreren Ebenen passieren: Der Router kennt keine Route (und sendet ggf. ICMP Unreachable), er hat eine Route in der RIB, aber nicht in der FIB (Weiterleitung fehlt), er hat einen Next Hop, kann ihn aber nicht auflösen (ARP/ND), oder eine Policy (ACL, PBR, uRPF, Firewall-State) verwirft Traffic selektiv. Ein Blackhole ist deshalb weniger ein einzelnes Symptom als eine Klasse von Ursachen, die sich im Resultat ähneln: Verbindungen hängen, Timeouts steigen, Retransmits nehmen zu.

• „Hard Blackhole“: Pakete werden verworfen, ohne ICMP-Feedback (z. B. ACL drop, uRPF drop, Firewall silent drop).
• „Soft Blackhole“: Pakete werden verworfen, aber mit Rückmeldung (z. B. ICMP Destination Unreachable), oder nur bestimmte Größen/Protokolle sind betroffen (z. B. PMTUD/MTU).
• „Policy Blackhole“: Forwarding ist vorhanden, aber Policy entscheidet anders als erwartet (PBR, VRF-Leak, Service-Chaining).

Traceroute verstehen: Warum es mehr ist als „Hop-Liste“

Traceroute nutzt ein einfaches Prinzip: Jeder Router reduziert beim Weiterleiten den IP-TTL (Time To Live) um 1. Wenn TTL = 0 erreicht ist, verwirft der Router das Paket und sendet typischerweise eine ICMP-Meldung „Time Exceeded“ zurück. Traceroute startet mit TTL=1, dann TTL=2, TTL=3 usw. So werden Router entlang des Pfads sichtbar. Entscheidend ist: Traceroute ist kein standardisiertes „einziges“ Verfahren. Je nach Betriebssystem und Optionen nutzt es UDP, ICMP oder TCP als Probe. Firewalls und Router behandeln diese Probes sehr unterschiedlich. Darum ist es wichtig, Traceroute-Ergebnisse stets im Kontext zu interpretieren und – wenn möglich – mit einem zweiten Probe-Typ zu verifizieren.

• UDP-Traceroute: sendet UDP an hohe Ports; Ziel antwortet oft mit „Port Unreachable“, wenn es erreicht wurde.
• ICMP-Traceroute: sendet ICMP Echo; Router antworten mit „Time Exceeded“, Ziel mit Echo Reply.
• TCP-Traceroute: sendet TCP SYN auf einen Zielport (z. B. 443); nützlich, wenn UDP/ICMP gefiltert ist.

Für ICMP-Grundlagen ist RFC 792 relevant, für IPv6-ICMP RFC 4443. Routerverhalten im IP-Forwarding wird u. a. in RFC 1812 beschrieben.

Typische Traceroute-Muster, die auf ein Blackhole hindeuten

Nicht jeder Stern (*) bedeutet ein Blackhole. Häufig ist nur das ICMP-Feedback blockiert, während der Datenverkehr durchgeht. Umgekehrt kann ein Traceroute „fertig“ aussehen, obwohl ein Blackhole existiert (z. B. weil nur TCP/443 betroffen ist, ICMP aber geht). Die folgenden Muster sind in der Praxis besonders hilfreich.

• Konstanter Abbruch an demselben Hop: mehrere Runs, gleicher Hop, danach keine Antworten mehr – Kandidat für Forwarding- oder Policy-Problem ab diesem Gerät.
• Abbruch erst ab bestimmter TTL, aber Ziel ist nicht erreichbar: häufig Next-Hop-Resolution, VRF-Fehler, oder Security-Filter hinter diesem Hop.
• Wechselnde Hops vor dem Abbruch: Hinweis auf ECMP/Load-Balancing; das Blackhole kann auf einem Teilpfad liegen.
• Traceroute endet „plausibel“, App fällt trotzdem aus: deutet auf Protokoll-/Port-spezifische Drops oder MTU/PMTUD hin; TCP-Traceroute testen.
• Nur einzelne Probes verlieren: vereinzelte Timeouts pro Hop sind normal (Rate-Limits für ICMP Time Exceeded).

Warum Traceroute allein nicht reicht: ECMP, Rate-Limits und Filter

Moderne Netze nutzen ECMP (Equal-Cost Multi-Path). Dadurch können Probes mit verschiedenen Quellports oder Sequenzen unterschiedliche Pfade nehmen. Viele Implementierungen hashen anhand von 5-Tuple (Src/Dst IP, Src/Dst Port, Protokoll). Das führt dazu, dass ein Traceroute wie „Zickzack“ aussieht oder bei jedem Run andere Hops zeigt. Zusätzlich rate-limitieren Router oft ICMP-Antworten, um Controlplane-Überlast zu vermeiden. Ein Stern in Traceroute kann also bedeuten: „Dieser Router hat gerade keine ICMP-Antwort geschickt“, nicht „Der Router leitet nicht weiter“.

• ECMP-Effekt: Unterschiedliche Hops pro Probe sind nicht automatisch ein Fehler.
• ICMP Rate-Limit: Time Exceeded wird gedrosselt, besonders bei vielen Probes.
• Security-Filter: ICMP kann blockiert sein, während TCP/UDP ok ist (oder umgekehrt).

Die zweite Hälfte: Routing-Table-Check mit Systematik

Wenn Traceroute Ihnen die wahrscheinliche Fehlerzone zeigt, liefert der Routing-Table-Check die Erklärung. Dabei sollten Sie zwei Tabellenkonzepte trennen: RIB (Routing Information Base, „was das Routing-Protokoll glaubt“) und FIB (Forwarding Information Base, „was die Hardware/Forwarding-Engine tatsächlich nutzt“). Ein Blackhole kann entstehen, wenn die RIB „gut“ aussieht, aber die FIB den Eintrag nicht installiert (z. B. wegen Ressourcen, Policy, fehlerhafter Recursion). Ebenso kann die Route korrekt sein, aber der Next Hop ist nicht erreichbar, weil ARP/ND fehlt oder ein Unterlay-Pfad kaputt ist.

• Longest Prefix Match: Welche Route gewinnt wirklich?
• Next Hop: Wohin soll weitergeleitet werden (IP, Interface, Tunnel)?
• Recursion: Muss der Next Hop über eine weitere Route aufgelöst werden?
• VRF/Route-Table: In welcher Instanz wird geroutet?
• RIB vs FIB: Ist die Route nur „gelernt“ oder auch „programmiert“?

Longest Prefix Match als Kernprinzip (MathML)

$\mathrm{GewinnerRoute}=\text{Route mit maximaler Präfixlänge}\left(\mathrm{/n}\right)$

Operativ bedeutet das: Eine scheinbar korrekte Default-Route kann durch eine spezifischere, aber falsche /32-/128-Route oder eine „Null Route“ übersteuert werden. Genau solche Fälle erzeugen klassische Blackholes.

Step-by-Step: Blackhole identifizieren mit Traceroute + Routing-Table-Check

Die folgende Abfolge ist bewusst so formuliert, dass sie in heterogenen Umgebungen (Multi-Vendor, VRF, Overlay) funktioniert und reproduzierbare Tickets erzeugt.

• 1) Ziel exakt definieren: Ziel-IP, Zielport, Protokoll, ggf. Hostname und aufgelöste IPs.
• 2) Traceroute mit passendem Probe-Typ: Wenn es um eine HTTPS-App geht, bevorzugt TCP-Traceroute auf 443. Wenn generisch, ICMP/UDP ergänzen.
• 3) Abbruchzone bestimmen: Der letzte konsistent antwortende Hop ist Ihre erste Router-Kandidatenliste.
• 4) Routing-Table auf diesem Hop prüfen: Gibt es eine Route zum Zielpräfix? Welche ist der Gewinner (Longest Prefix)?
• 5) Next Hop validieren: Ist der Next Hop erreichbar (ARP/ND ok)? Gibt es eine Recursive Route?
• 6) Reverse Path bedenken: Asymmetrische Rückwege sind häufige Blackhole-Ursache bei State-Firewalls und uRPF.
• 7) FIB-Status prüfen: Ist der Eintrag tatsächlich im Forwarding installiert?
• 8) Policy prüfen: ACL, PBR, VRF-Leaks, NAT, Security-Zonen – besonders dort, wo Traceroute „stumm“ wird.

Routing-Table-Check: Worauf Sie konkret achten sollten

Ein Routing-Table-Check ist mehr als „Route existiert“. Sie brauchen die Details, die Blackholes erklären. Die folgenden Punkte sind in der Praxis die häufigsten „aha“-Momente.

• Unerwartet spezifische Route: Eine /32-/128-Route oder ein sehr spezifisches Präfix leitet ins Leere.
• Null/Discard Route: Absichtliche Blackhole-Routen (DDoS-Mitigation, Summarization-Guard) greifen zu breit.
• Recursive Next Hop bricht: Next Hop wird über eine weitere Route aufgelöst, die fehlt oder falsch ist.
• VRF-Verwechslung: Route existiert in VRF A, Traffic läuft aber in VRF B (klassisch nach Changes).
• RIB ok, FIB fehlt: Route wird nicht programmiert (Ressourcen, Policy, Bug, inkompatibles Next-Hop-Interface).
• ECMP-Set enthält defekten Pfad: Ein Next Hop ist down, bleibt aber als ECMP-Kandidat aktiv (plattformabhängig).

Traceroute richtig „gegenprüfen“: Drei Varianten, die Klarheit schaffen

Wenn Traceroute ambivalent ist, hilft es, die Probe gezielt zu variieren. Damit können Sie herausfinden, ob Sie ein reines ICMP-Sichtbarkeitsproblem haben oder ein echtes Forwarding-Blackhole.

• TCP-Traceroute auf Applikationsport: Wenn UDP/ICMP gefiltert wird, ist dies oft die aussagekräftigste Methode.
• Traceroute mit fixer Quelladresse: In VRF- oder Multi-Interface-Systemen wichtig, weil unterschiedliche Quellen andere Policies/Routes nutzen.
• Mehrere Runs, gleiche Parameter: Identifizieren, ob ECMP/Hasing das Bild verändert; konsistente Abbrüche sind wichtiger als Einzelruns.

Blackhole vs. „nur ICMP gefiltert“: Eindeutige Unterscheidungsmerkmale

Ein häufiger Irrtum: „Traceroute zeigt Sterne, also ist da ein Blackhole.“ Ein belastbarer Nachweis entsteht erst, wenn Sie belegen, dass Nutzverkehr betroffen ist. Dafür sind zwei Signale besonders wertvoll: (1) TCP kann nicht aufgebaut werden oder bricht beim Datentransfer, und (2) Routing/Forwarding auf dem letzten sichtbaren Hop ist inkonsistent oder falsch.

• ICMP gefiltert: Traceroute zeigt Sterne, aber TCP-Verbindungen funktionieren stabil; Routing-Table ist konsistent.
• Echtes Blackhole: TCP-Handshake/Datentransfer scheitert, und Routing-Table/FIB/Next-Hop-Resolution zeigt einen klaren Bruch.
• Policy Blackhole: Ping geht, TCP geht nicht; Routing ist korrekt, aber ACL/PBR/NAT-State verwirft.

Häufige Root Causes, die Sie mit diesem Vorgehen schnell finden

Die meisten Routing-Blackholes lassen sich auf wenige Muster reduzieren. Wenn Sie diese im Kopf haben, interpretieren Sie Traceroute und Routing-Tabellen deutlich schneller.

• Statische Route auf falschen Next Hop: Nach Umbau zeigt die Route noch auf eine alte Transit-IP.
• BGP-Fehlankündigung: Ein Präfix wird von einem falschen Standort announced; Traffic landet in einem Segment ohne Rückweg. Für BGP-Grundlagen ist RFC 4271 relevant.
• Summarization + Null Route: Null Routes sollen Leaks verhindern, greifen aber durch falsche Präfixe zu breit.
• VRF-Leak fehlerhaft: Route wird geleakt, aber ohne korrekten Next Hop oder ohne Rückroute.
• uRPF/Stateful Firewall: Asymmetrischer Rückweg führt zu Drops, obwohl Forward-Routing korrekt ist.
• ARP/ND-Auflösung fehlt: Route zeigt auf einen Next Hop, der auf L2 nicht erreichbar ist (VLAN fehlt, Interface down, falsche Subnetzmaske).
• MTU/PMTUD-Blackhole: Kleine Pakete gehen durch, größere werden verworfen, weil ICMP „Fragmentation Needed“ geblockt ist. Für PMTUD ist RFC 1191 eine passende Referenz.

Routing-Table-Check in VRF- und Overlay-Umgebungen

In modernen Netzen ist „die Routing-Tabelle“ selten eindeutig. VRFs, Overlays und Service-Chaining bedeuten, dass derselbe Zielpräfix in mehreren Instanzen unterschiedlich behandelt wird. Dadurch entsteht ein typischer Blackhole-Fall: Traceroute aus einer Perspektive sieht „ok“ aus, aus einer anderen Perspektive bricht es. Die Lösung ist, die Perspektive bewusst zu kontrollieren.

• VRF korrekt auswählen: Routing-Table-Check immer in der Instanz durchführen, in der der Traffic tatsächlich läuft.
• Underlay vs. Overlay trennen: Tunnel-Endpunkte müssen im Underlay erreichbar sein, sonst wirkt das Overlay wie ein Blackhole.
• Policy-Reihenfolge beachten: PBR/Service-Chaining kann Routing „überschreiben“, ohne dass es in der Standard-Route sichtbar ist.

Dokumentation für Tickets: Welche Evidence Blackholes schnell eskalierbar macht

Die beste technische Analyse hilft wenig, wenn das Ticket unklar ist. Gerade bei Blackholes ist eine saubere Evidence-Struktur entscheidend, damit Netzwerkteams, Security und Plattformteams schnell die gleiche Realität sehen.

• Symptom präzise: Was fällt aus (Port/Protokoll), seit wann, aus welchen Quellen (Standort/VRF)?
• Traceroute-Output zusammengefasst: letzter konsistent antwortender Hop, Abbruchzone, Probe-Typ (ICMP/UDP/TCP) und Zielport.
• Routing-Table-Ergebnis: Gewinnerroute (Präfix), Next Hop, VRF, ECMP-Set, Recursion-Status.
• FIB/Forwarding-Status: Eintrag programmiert ja/nein, Next-Hop-Resolution (ARP/ND) ok ja/nein.
• Rückweg-Hinweis: Gibt es Hinweise auf asymmetrisches Routing oder stateful Drops?
• Change-Korrelation: letzter Change an Routing, VRF, Firewall, Trunks, Overlays.

Praxis-Checkliste: „Blackhole bestätigt“ in klaren Kriterien

Wenn Sie im NOC eine eindeutige Entscheidung brauchen, helfen harte Kriterien. Diese Checkliste ist bewusst konservativ: Sie minimiert False Positives durch „nur ICMP gefiltert“.

• Traceroute (passender Probe-Typ) bricht konsistent ab und der Zielservice ist nicht erreichbar.
• Routing-Table zeigt eine Route, deren Next Hop nicht erreichbar ist, oder eine unerwartete Gewinnerroute (z. B. Null Route / zu spezifisch / falsche VRF).
• oder: Routing-Table ist korrekt, aber Policy/State (uRPF, ACL, Firewall) verwirft Traffic selektiv (Port/Protokoll-spezifisch).
• RIB/FIB-Check zeigt Inkonsistenz (gelernt, aber nicht weiterleitbar).

Outbound-Links für Standards und Hintergrundwissen

• RFC 791 (IPv4) als Grundlage für TTL und IP-Forwarding-Verhalten.
• RFC 792 (ICMP) für „Time Exceeded“ und „Destination Unreachable“-Mechanismen.
• RFC 1812 (Requirements for IP Version 4 Routers) für Router-Forwarding- und ICMP-Verhalten in der Praxis.
• RFC 1191 (Path MTU Discovery) für MTU-Blackholes, die wie Routing-Blackholes wirken können.
• RFC 4271 (BGP) für typische Blackhole-Ursachen durch Fehlankündigungen und Routing-Divergenz.

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.