Blackhole-Routing finden (schnelle Methode fürs NOC)

Blackhole-Routing finden gehört zu den wichtigsten NOC-Aufgaben, weil der Fehler extrem „still“ ist: Traffic verschwindet, ohne dass klare Fehlermeldungen zurückkommen. Für Nutzer sieht das aus wie „Request timed out“, „App hängt“, „VPN verbindet nicht“ oder „nur manche Services gehen nicht“. Für das NOC ist es gefährlich, weil klassische Checks wie „Interface up“, „BGP established“ oder „Ping zum Gateway“ unauffällig sein können. Ein Blackhole entsteht typischerweise, wenn ein Router eine Route annimmt oder verteilt, den Traffic aber nicht korrekt weiterleitet – etwa durch falsche Next-Hops, Null-Routes, fehlende Rückrouten, VRF-Leaks, fehlerhafte Policy-Based Routing-Regeln, asymmetrische Pfade oder MTU/Fragmentierungsprobleme, die nur bestimmte Paketgrößen betreffen. Dieser Praxisleitfaden liefert eine schnelle Methode fürs NOC, um Blackhole-Routing reproduzierbar zu finden: von der sauberen Eingrenzung über eine Messkette entlang des Pfads bis zur Beweisführung mit Traceroute/MTR, Routing-Tabellen, ARP/NDP und Forwarding-Indikatoren. Ziel ist, innerhalb weniger Minuten eine belastbare Aussage zu treffen: Wo verschwindet der Traffic – und warum?

Was Blackhole-Routing ist (und warum es so schwer zu sehen ist)

Unter Blackhole-Routing versteht man eine Situation, in der Pakete zwar in Richtung eines Ziels geroutet werden, aber unterwegs verworfen werden oder nie beim Ziel ankommen – ohne dass der Absender eine klare Rückmeldung erhält. Das unterscheidet sich von „hartem“ Down (Link down) oder einer klaren Filtermeldung (ICMP Unreachable). Blackholes entstehen häufig in Layer 3, können aber durch Layer-4/Layer-7-Symptome sichtbar werden, weil Anwendungen auf Antworten warten und irgendwann timeouten.

• Typisches Symptom: Timeouts statt Fehlcodes (keine Antwort, keine Ablehnung).
• Warum Ping trügen kann: Ping testet nur ICMP und oft nur kleine Pakete; Blackholes können port- oder größenabhängig sein.
• Warum Monitoring trügen kann: Routing-Protokolle können „grün“ sein, während Forwarding/Pfad tatsächlich defekt ist.

Die häufigsten Ursachen im NOC-Alltag

In der Praxis lassen sich die meisten Blackholes in wiederkehrende Muster einordnen. Wenn Sie diese Muster kennen, können Sie schneller die richtigen Checks wählen.

• Null-Route / Sinkhole: Eine Route auf Null/Discard wurde (absichtlich oder versehentlich) gesetzt und zieht Traffic an.
• Falscher Next-Hop: Route zeigt auf einen Next-Hop, der nicht erreichbar ist oder in der falschen VRF liegt.
• RPF/uRPF-Drops: Reverse Path Forwarding verwirft Pakete, wenn die Rückroute nicht plausibel ist.
• Asymmetrisches Routing + Stateful Firewall: Hinweg geht über Gerät A, Rückweg über Gerät B; State fehlt, Antworten werden verworfen.
• VRF/Segmentierungsfehler: Route existiert in VRF1, Traffic kommt aber aus VRF2; Leak fehlt oder ist falsch.
• PMTUD/MTU-Blackhole: Kleine Pakete gehen, große nicht (ICMP „Fragmentation Needed“ wird gefiltert).
• Policy-Based Routing: PBR greift nur für bestimmte Quellen/Ports und schickt Traffic in ein Dead-End.
• Route-Learning/Redistribution: Falsche Redistribution erzeugt „bessere“ Route ohne funktionierenden Pfad.

Schnelle NOC-Methode: In 6 Schritten zum Blackhole-Nachweis

Diese Methode ist bewusst so aufgebaut, dass Sie sie auch unter Zeitdruck anwenden können. Jeder Schritt soll eine Entscheidung erzwingen und die Suche räumlich eingrenzen.

Schritt 1: Scope festlegen und Symptom schärfen

• Was ist betroffen? Ein Ziel (eine IP/Prefix), eine App, ein Port (z. B. 443), oder „alles nach extern“?
• Wer ist betroffen? Einzelner Client, gesamtes Subnetz, Standort, nur VPN-User, nur eine VRF?
• Wann tritt es auf? dauerhaft oder intermittierend (wichtig für MTR/Time-Series)?

Schritt 2: Hostname von Routing trennen

Bevor Sie Routing jagen, schließen Sie DNS-Verwechslungen aus: Arbeiten Sie möglichst mit einer konkreten Ziel-IP und einem konkreten Port. Wenn DNS fehlerhaft ist, sieht es wie Routing aus („nicht erreichbar“), ist aber ein anderes Problem.

• Wenn die IP nicht bekannt ist: DNS-Auflösung separat prüfen und IP(s) notieren.
• IPv4 und IPv6 getrennt betrachten (AAA A vs. A), weil Blackholes häufig nur eine Adressfamilie treffen.

Schritt 3: Messkette aufbauen (Client → Gateway → Edge → Ziel)

Der schnellste Weg zur Lokalisation ist eine Messkette entlang des Pfads. Statt nur „Client → Ziel“ zu testen, prüfen Sie in Etappen. Damit sehen Sie, in welchem Segment das Blackhole beginnt.

• Client → Default Gateway: Wenn das schon instabil ist, ist es kein Blackhole-Routing, sondern lokal (L2/WLAN).
• Gateway → Edge/WAN-Next-Hop: Wenn hier Timeouts auftreten, liegt das Problem im Standort/Upstream.
• Edge → Ziel: Wenn nur diese Etappe scheitert, liegt es im Core/Provider/Zielnetz oder in Policies am Edge.

Schritt 4: Traceroute interpretieren – und sofort MTR nutzen, wenn es „komisch“ wirkt

Traceroute zeigt den Pfad als Momentaufnahme. Blackholes sind aber oft intermittierend oder betreffen nur bestimmte Probes. Wenn Traceroute unklare Hops („*“) oder scheinbaren Loss in der Mitte zeigt, ist MTR sinnvoll, weil es über Zeit misst und echte Muster sichtbar macht.

• Blackhole-Indiz: Traceroute endet immer ab Hop X, danach keine Antworten mehr, auch nicht vom Ziel.
• Kein Beweis: „Loss“ in der Mitte ohne Loss am Ziel ist oft nur ICMP Rate-Limit.
• Starker Beweis: Ab Hop X steigt Loss/RTT und bleibt bis zum Ziel (oder das Ziel bleibt vollständig ohne Antwort).

Schritt 5: Routing- und Forwarding-Checks am Verdachtshop

Sobald Sie den Verdachtshop (der letzte Hop, der zuverlässig antwortet) eingegrenzt haben, prüfen Sie dort nicht nur „Route existiert“, sondern ob Forwarding tatsächlich funktioniert.

• Route zum Zielprefix: Welche Route ist aktiv (Longest Prefix Match)? Welche Quelle (BGP, OSPF, Static)?
• Next-Hop-Auflösung: Ist der Next-Hop erreichbar (ARP/NDP)? Ist die Adjazenz stabil?
• Rückroute: Gibt es eine Rückroute zur Quell-IP/Quelle-VRF (wichtig für uRPF, Firewalls, NAT)?
• Policy/PBR: Greift eine Route-Map/Policy nur für bestimmte Traffic-Klassen?
• Drop-Counter: Gibt es Zähler für Drops (ACL, uRPF, Null-Route, TCAM/Policy Drop)?

Schritt 6: Beweisführung für Eskalation (Provider/Netzwerkteam)

Ein NOC-Ticket ist dann stark, wenn es nicht „es geht nicht“ sagt, sondern zeigt: Traffic verschwindet ab Punkt X. Dokumentieren Sie daher strukturiert: Pfad, Zeitpunkt, betroffene Ziele, und die Routing-/Forwarding-Indikatoren.

• Quelle (Standort, VLAN, VRF), Ziel-IP/Prefix, betroffener Port/Protokoll
• Traceroute/MTR-Auszug mit klar markiertem Abbruchpunkt
• Aktive Route + Next-Hop + Interface am Verdachtshop
• Hinweise auf uRPF/ACL/PBR/Null-Route oder MTU-Themen

Der entscheidende technische Kern: Longest Prefix Match und „falsche bessere Route“

Viele Blackholes entstehen, weil eine spezifischere Route (längeres Präfix) plötzlich auftaucht und die eigentlich korrekte, weniger spezifische Route übersteuert. Das ist besonders häufig bei fehlerhafter Redistribution, versehentlichen Static Routes oder BGP-Ankündigungen mit zu spezifischen Prefixes.

Warum eine spezifischere Route so gefährlich ist

Router wählen bei konkurrierenden Routen zuerst die längste Präfixlänge (Longest Prefix Match). Eine /32 oder /128 schlägt fast alles – selbst wenn der Pfad dahinter nicht funktioniert. Das ist eine typische Blackhole-Falle: Monitoring sieht „Route vorhanden“, aber der falsche Next-Hop zieht Traffic ins Leere.

$\mathrm{Match}=\text{Longest Prefix}(\mathrm{DestinationIP},\mathrm{RoutingTable})$

Praxisregel: Wenn ein Blackhole plötzlich startet, prüfen Sie als Erstes, ob eine neue, spezifischere Route aufgetaucht ist. Das erklärt sehr viele „von jetzt auf gleich“ auftretende Ausfälle.

MTU-Blackhole erkennen: Wenn Ping geht, aber echte Daten hängen

Ein besonders tückischer Sonderfall ist das MTU-/PMTUD-Blackhole: Kleine Pakete kommen durch, große nicht. Dadurch wirken viele Checks unauffällig: Ping mit Standardgröße geht, DNS geht, TCP-Handshake geht – aber Downloads, TLS oder bestimmte API-Calls hängen. Ursache ist oft, dass ICMP-Meldungen für Path MTU Discovery (z. B. „Fragmentation Needed“) gefiltert werden.

Typische Indikatoren für MTU-Blackhole

• Login/Handshake klappt, danach „hängt“ die Session bei größeren Responses
• Nur VPN oder Tunnelpfade betroffen
• Nur bestimmte Ziele betroffen (andere Pfade haben andere MTU)

Praktische Beweisidee

• Vergleichen Sie kleine und große Payloads (z. B. ICMP mit gesetztem DF bei IPv4, oder gezielte TCP-Tests).
• Wenn kleine Pakete stabil gehen, große aber reproduzierbar scheitern, ist MTU ein Top-Verdacht.

uRPF und „stille Drops“: Blackhole durch Rückweglogik

Unicast Reverse Path Forwarding (uRPF) ist ein Sicherheitsmechanismus, der Pakete verwirft, wenn der Rückweg zur Quelladresse nicht über das erwartete Interface führt. In asymmetrischen Netzen oder bei falschen Routen kann uRPF wie ein Blackhole wirken: Pakete kommen an, werden aber still gedroppt.

• Indiz: Problem betrifft bestimmte Quellnetze, nicht alle.
• Indiz: Traceroute kann je nach Richtung oder Quelle unterschiedliche Abbruchstellen zeigen.
• Beweisidee: Prüfen, ob die Rückroute zur Quelle am Drop-Gerät plausibel ist (und ob uRPF aktiv ist).

Asymmetrie + Stateful Firewalls: Blackhole, obwohl Routing „stimmt“

In vielen Umgebungen ist nicht das Routing selbst falsch, sondern die Kombination aus asymmetrischen Pfaden und stateful Inspektion. Beispiel: Client → Internet geht über Firewall A, Rückweg kommt über Firewall B zurück. Firewall B kennt den State nicht und verwirft Antworten. Das sieht wie Blackhole aus (Timeout), obwohl beide Firewalls „gesund“ sind.

• Indiz: Nur bestimmte Sessions/Ports betroffen, insbesondere TCP/443, VPN, VoIP.
• Indiz: Ausfall tritt nach Routing-Änderungen, Failover oder ECMP-Änderungen auf.
• Beweisidee: Pfadvergleich Hinweg/Rückweg (Flow-Logs, Session-Logs, asymmetrische Traces aus zwei Richtungen).

NOC-Checkliste: Der schnellste Weg zum Blackhole-Fund

Diese Checkliste ist als „Runbook-Block“ gedacht: kurz, aber vollständig genug, um Blackholes zuverlässig einzugrenzen.

• Ziel definieren: IP/Prefix, Port, IPv4/IPv6 getrennt.
• Scope definieren: Wer/wo ist betroffen (VLAN, VRF, Standort, VPN).
• Messkette: Client→GW, GW→Edge, Edge→Ziel.
• Traceroute + MTR: Abbruchpunkt und Stabilität über Zeit identifizieren.
• Longest Prefix Match prüfen: Gibt es eine neue spezifische Route (/32, /128, /24 statt /16)?
• Next-Hop-Auflösung: ARP/NDP, Adjazenz, Interface, VRF-Konsistenz.
• Policy prüfen: PBR, ACL, uRPF, Null-Route, QoS/Policer (Drops).
• MTU prüfen: Verdacht bei „klein geht, groß hängt“, besonders bei VPN/Tunneln.
• Beweise sichern: Zeitstempel, Pfad, Route/Next-Hop, relevante Drop-/Error-Counter.

Monitoring-Daten, die Blackholes schneller sichtbar machen

Blackholes sind einfacher zu finden, wenn Sie Monitoring nicht nur auf „Device up“ und „BGP up“ reduzieren, sondern Forwarding-nahe Signale einbeziehen. Schon wenige zusätzliche Zeitreihen können die Diagnose beschleunigen.

• Interface Drops/Discards: plötzlicher Anstieg kann auf Queueing oder Policy-Drops hinweisen.
• Routing-Change Events: Route-Flaps, neue spezifische Prefixes, Next-Hop-Wechsel.
• Firewall/ACL Drop Counters: „stille“ Drops sind häufig Blackhole-ähnliche Ursachen.
• Flow-Daten (NetFlow/IPFIX): Traffic geht raus, aber keine Antworten zurück (asymmetrischer Hinweis).
• End-to-End SLO Checks: synthetische Tests (DNS, TCP/443, HTTP) aus mehreren Standorten.

Dokumentation für Eskalationen: So wirkt die Analyse überzeugend

Gerade bei Provider-Fällen oder teamübergreifenden Übergaben ist die Beweisführung entscheidend. Eine gute Eskalation belegt, dass es sich nicht um „DNS“, „App“ oder „Client“ handelt, sondern um ein Blackhole im Pfad oder ein policy-basiertes Drop-Verhalten.

• Reproduzierbarkeit: „Seit 10:42 Uhr tritt es konstant auf“ oder „alle 15–20 Minuten für 30–60 Sekunden“.
• Abbruchpunkt: „Traceroute/MTR endet ab Hop X (Edge-Router Y), Ziel antwortet nicht“.
• Routing-Kontext: „Aktive Route ist /24 via Next-Hop Z; vorher war es /16 via Next-Hop W“.
• Forwarding-Indiz: „ARP/NDP fehlt“ oder „uRPF/ACL Drops steigen im Fehlerfenster“.
• Abgrenzung: „DNS ok“, „Gateway ok“, „nur dieses Prefix betroffen“ – damit ist der Zuständigkeitsbereich klar.

Outbound-Referenzen für Standards und tieferes Verständnis

• RFC-Editor (Netzwerkstandards, Routing- und IP-Grundlagen)
• RFC 1812 (Requirements for IP Version 4 Routers)
• Wireshark-Dokumentation (Paketanalyse zur Bestätigung von Drops, Retransmits und MTU-Effekten)
• RIPE Atlas Messplattform (externe Perspektive zur Abgrenzung Provider/Zielnetz)

Wenn Sie im NOC Blackhole-Routing schnell finden wollen, zählt vor allem ein reproduzierbarer Ablauf: Ziel-IP und Scope sauber definieren, eine Messkette entlang des Pfads aufbauen, Traceroute/MTR korrekt interpretieren, dann am Verdachtshop Route, Next-Hop und Forwarding-Realität prüfen. Die stärksten Blackhole-Indizien sind eine neue spezifischere Route (Longest Prefix Match), eine nicht auflösbare Next-Hop-Adjazenz, policy-bedingte stille Drops (uRPF/ACL/PBR) und MTU-Effekte, die Ping nicht zeigt. Mit diesen Bausteinen wird aus einem diffusen Timeout-Problem eine lokalisierbare Routing-Störung, die Sie mit klaren Beweisen eskalieren können.

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.