Blackhole Routing: Nachweis-Techniken im Provider-Maßstab

Blackhole Routing ist im Provider-Betrieb ein Sammelbegriff für ein besonders unangenehmes Fehlerbild: Pakete werden gesendet, aber verschwinden irgendwo im Netz – ohne dass sofort klar ist, wo und warum. Dabei kann „Blackhole“ vieles bedeuten: ein bewusstes Blackhole (z. B. DDoS-Blackholing per BGP Community), ein unbeabsichtigtes Blackhole durch falsche Routing-Policy, ein Next-Hop-Problem, ein MTU/PMTUD-Knick, ein ECMP-Teilpfad mit Drops oder ein stateful Edge-System, das Rückverkehr verwirft. Für Kunden wirkt es oft identisch: Timeouts, Retransmissions, hohe Latenz und sporadischer Paketverlust. Im Provider-Maßstab ist der entscheidende Unterschied zur klassischen Störung: Sie können das Problem nicht mehr „per Hand“ auf einem einzelnen Router finden. Sie brauchen Nachweis-Techniken, die skalieren – also Beweise, die über Telemetrie, Flow-Daten, synthetische Messungen und Routing-Daten zusammengeführt werden. Dieser Artikel zeigt praxisnahe Methoden, um Blackhole Routing sicher nachzuweisen: Wie Sie den Drop-Ort eingrenzen, Underlay und Overlay unterscheiden, ECMP-Selektivität berücksichtigen, BGP- und IGP-Indizien korrekt interpretieren und ein Evidence Pack erstellen, das sowohl intern (RCA) als auch extern (Carrier/Vendor/Peer-Eskalation) belastbar ist.

Was „Blackhole Routing“ im Provider-Kontext wirklich umfasst

Im Provider-Umfeld spricht man von Blackhole Routing, wenn ein Paket den Sender verlässt, aber am erwarteten Ziel nicht ankommt – und es keine eindeutige „Hard Failure“-Anzeige gibt. Das kann bewusst oder unbeabsichtigt passieren:

• Intentional Blackholing: Traffic wird absichtlich verworfen, z. B. als DDoS-Mitigation (Remote Triggered Black Hole, RTBH) oder als lokale Policy (Discard/Null Route).
• Unintentional Blackholing: Traffic wird unbeabsichtigt verworfen, z. B. durch falsche Next-Hop-Auflösung, ACL/Policer, MTU-Probleme oder falsche Pfadwahl.
• Partial Blackholing: nur bestimmte Flows, Größen oder Richtungen sind betroffen (typisch bei ECMP, Mikrobursts, stateful Geräten).

Der Schlüssel für den Betrieb ist die Trennung: „Wird bewusst gedroppt?“ (Policy/Blackhole-Mechanik) oder „verschwindet unbeabsichtigt?“ (Fehler/Degradation). Erst danach sind Mitigation und Kommunikation sauber möglich.

Warum Blackholes im Provider-Maßstab schwer zu beweisen sind

Blackholes sind selten „alles oder nichts“. Im Carrier-Netz sind Pfade redundant, Traffic ist verteilt, und viele Systeme priorisieren Datenebene und Telemetrie unterschiedlich. Typische Komplexitätsfaktoren:

• ECMP/LAG: nur ein Teilpfad dropt, daher sind nur einige Kunden oder Flows betroffen.
• Asymmetrie: Hin- und Rückweg laufen anders; ein stateful System (Firewall/CGNAT) kann Rückpakete verwerfen.
• Policy-Schichten: IGP, iBGP, eBGP, TE-Policy und ACL/CoPP greifen gleichzeitig.
• Messpunkt-Problem: ein einzelner Ping/Traceroute ist kein Beweis; Sie brauchen Messpunkte entlang des Pfads.

Der Provider-Ansatz lautet deshalb: Beweisführung über mehrere unabhängige Signale, die zusammen ein konsistentes Bild ergeben.

Taxonomie: Häufige Blackhole-Ursachen und ihre typischen Signaturen

Für skalierbares Troubleshooting hilft eine grobe Klassifizierung. Sie reduziert Suchraum und beschleunigt die ersten 10 Minuten.

• Routing/Next-Hop Blackhole: Route vorhanden, aber Next Hop nicht erreichbar oder nicht rekursiv auflösbar; Route bleibt im RIB, fehlt aber in der FIB.
• Policy/Filter Blackhole: ACL/Policer/CoPP dropt; oft selektiv nach Protokoll/Port/Größe.
• MTU/PMTUD Blackhole: kleine Pakete ok, große droppen; ICMP „Packet Too Big“/„Frag Needed“ fehlt oder wird geblockt.
• ECMP-Partial Failure: nur Flows auf einem Pfad droppen; per-member Queue Drops oder Errors.
• Intentional Blackholing (RTBH/Null Route): klarer Drop, oft mit Community/Policy nachweisbar.
• Stateful Edge Blackhole: Rückverkehr wird ohne State verworfen (Firewall/CGNAT); „one-way flows“ und Session-miss-Drops.

Nachweis-Grundprinzip: Messpunkte entlang des Pfads

Im Provider-Maßstab ist „Beweisen“ gleichbedeutend mit „Eingrenzen“. Sie brauchen mindestens zwei Messpunkte, besser drei oder mehr. Der Grund: Wenn Sie nur am Ziel messen, wissen Sie nicht, wo das Paket verloren ging. Wenn Sie nur in der Mitte messen, wissen Sie nicht, ob es vom Sender kam. Der praktische Ansatz:

• Sender-nahe Messung: Belegt, dass Pakete tatsächlich gesendet werden (und in das Netz gelangen).
• Core-/Transit-Messung: Belegt, ob Traffic durch die Mitte kommt (und ob Pfade konsistent sind).
• Ziel-nahe Messung: Belegt, ob Traffic ankommt und wie er verarbeitet wird.

Drop-Ort über Differenz von Countern (MathML)

$\mathrm{Loss}=\mathrm{Packets}\_\mathrm{sent}-\mathrm{Packets}\_\mathrm{received}$

In der Praxis ersetzen Sie „sent/received“ durch Messwerte aus Telemetrie: Interface-Counter, Flow-Daten, synthetische Probes, oder — wenn möglich — Paket- oder Sample-Daten.

Technik 1: Synthetische Probes mit Multi-Flow-Strategie

Synthetische Probes (Ping, UDP-Probes, TCP-Connect) sind schnell und skalierbar, wenn Sie sie richtig nutzen. Der häufigste Fehler ist „ein einzelner Ping“. Bei ECMP kann ein einzelner Flow zufällig auf einem guten Pfad landen und damit das Blackhole maskieren. Deshalb ist Multi-Flow-Probing entscheidend.

• Mehrere Flows erzeugen: variieren Sie Source Ports (bei UDP/TCP) oder nutzen Sie mehrere Source IPs, um unterschiedliche ECMP-Hashes zu treffen.
• Bidirektional messen: Hin- und Rückweg separat prüfen (Asymmetrie/Stateful Devices).
• Groß vs. klein: unterschiedliche Paketgrößen testen, um MTU/PMTUD-Probleme aufzudecken.

PMTUD-Indiz als Größenvergleich (MathML)

$\mathrm{PMTUD\_Suspect}\Leftarrow \mathrm{SmallPackets}\_\mathrm{ok}\wedge \mathrm{LargePackets}\_\mathrm{fail}$

Für Grundlagen zu PMTUD sind RFC 1191 (IPv4) und RFC 8201 (IPv6) hilfreiche Referenzen.

Technik 2: Flow-Daten (NetFlow/IPFIX) und „One-Way“-Signaturen

Flow-Daten skalieren besonders gut, weil sie nicht jeden Paketinhalt brauchen, aber dennoch Richtung, Volumen und Zeitfenster abbilden. Für Blackholes sind zwei Muster besonders wertvoll:

• One-way flows: Sie sehen Outbound-Flows, aber kaum Inbound-Bytes/Packets zurück (Hinweis auf Blackhole oder stateful Drop).
• AS-/Prefix-spezifischer Impact: nur bestimmte Ziele oder Ziel-ASNs zeigen Abbrüche (Policy-/Peering-/Pfadproblem).

Im Provider-Maßstab ist das besonders nützlich, weil Sie nicht „einen Kundenfall“ debuggen, sondern schnell erkennen müssen, ob ein ganzer Region-/Peer-/PoP-Slice betroffen ist.

Technik 3: Interface- und Queue-Telemetrie pro Pfad, nicht nur aggregiert

Viele Blackholes sind Partial Failures. Deshalb ist die wichtigste Regel: Telemetrie muss „per Pfad“ sichtbar sein. Aggregierte Werte (z. B. LAG gesamt) können den defekten Member verstecken.

• Per-LAG-Member Counter: CRC/FEC, Discards, Queue Drops pro Member.
• Per-Next-Hop Sicht (ECMP): falls möglich, Drops und Auslastung pro Next Hop.
• Queue Drops statt nur Interface Drops: Drops passieren oft in Queues/Buffering, nicht als „Errors“ am Interface.

Wenn nur einige Kunden betroffen sind, ist per-member Telemetrie fast immer der schnellste Weg, den „schlechten“ Pfad zu finden.

Technik 4: Routing-Daten: RIB/FIB-Differenz, Next-Hop-Reachability, Policy-Hits

Blackholes sind häufig routinglogisch: Route vorhanden, aber Forwarding funktioniert nicht. Typische Nachweisfragen:

• Ist die Route im RIB und in der FIB? Wenn nur im RIB, kann Next-Hop-Resolution oder Policy die Installation verhindern.
• Ist der Next Hop rekursiv erreichbar? Ein fehlender IGP- oder static path kann ein stilles Blackhole erzeugen.
• Gibt es ACL/Policer Hits? Ein hoher Hit-Counter auf einer Drop-Policy ist ein direkter Beweis.
• Route-Selection-Änderungen: Best-Path wechselte kurz vor dem Incident (BGP, TE, IGP-Metrik)?

Für BGP-Grundlagen ist RFC 4271 relevant; für Multipath-Verhalten sind RFC 2991 und RFC 2992 nützlich.

Technik 5: RTBH und bewusstes Blackholing sicher nachweisen

Intentional Blackholing ist im Provider-Betrieb legitim, muss aber sauber nachweisbar sein, damit es nicht als „mysteriöse Störung“ eskaliert. Typische Merkmale:

• Route zu Null/Discard: Präfix wird intern auf Null geroutet oder auf ein Discard-Interface.
• Community-getrieben: Blackhole-Community am BGP-Announcement (RTBH-Workflow).
• Scope klar: nur betroffene Präfixe/Targets, zeitlich begrenzt, dokumentiert.

Best Practice im Incident: immer prüfen, ob ein Blackhole-Community-Workflow ausgelöst wurde (automatisch oder manuell), bevor man „Interconnect kaputt“ vermutet. Als praxisnaher Rahmen für Routing-Sicherheitsprozesse eignet sich MANRS.

Technik 6: Overlay vs. Underlay trennen (EVPN/VXLAN, Tunnel, SR)

In modernen Provider-Netzen existieren Overlays (EVPN/VXLAN, L3VPN, SR Policies). Blackholes können in beiden Ebenen entstehen. Der Nachweis ist nur sauber, wenn Sie trennen:

• Underlay-Beweis: VTEP/PE-to-PE Reachability, MTU, Pfadstabilität, Drops auf Transportlinks.
• Overlay-Beweis: Route Distribution (EVPN Route Types, VPN Labels), Next-Hop/Label-Stack plausibel, Policies korrekt.

Für VXLAN als Hintergrund ist RFC 7348 relevant, für EVPN RFC 7432. Im RCA ist diese Trennung entscheidend, weil ein „Overlay-Blackhole“ häufig bei grünem Underlay auftritt.

Provider-Runbook: Blackhole-Nachweis in Minuten

Im NOC zählt Geschwindigkeit. Dieses Runbook ist bewusst als schnelle Entscheidungslogik gebaut.

Schritt: Scope und Signatur

• Welche Region/PoP? Ist das Problem regional oder global?
• Welche Richtung? nur inbound, nur outbound oder bidirektional?
• Welche Größe/Protokolle? nur große Pakete, nur UDP, nur TCP?
• Welche Selektivität? nur bestimmte Kunden/ASNs (ECMP/Peering-Selektivität)?

Schritt: Multi-Flow-Probes und Größenvergleich

• Mehrere Flows: verschiedene Ports/Quellen, um ECMP-Pfade zu treffen.
• Small vs. Large: PMTUD/MTU-Indiz prüfen.
• Bidirektional: beide Richtungen messen.

Schritt: Pfadtelemetrie

• Per-member Drops: LAG-Mitglieder, Spine-Uplinks, Edge-Links.
• Queue Drops: korreliert Loss mit Queueing?
• Errors/FEC/CRC: Degradation statt Hard Down.

Schritt: Routing-Checks

• RIB/FIB Konsistenz: Route installiert? Next Hop erreichbar?
• Policy-Hits: ACL/Policer/CoPP Drop-Counter steigen?
• RTBH? Blackhole-Communities oder Discard-Routen aktiv?

Schritt: Evidence Pack erstellen (für RCA und Eskalation)

• Zeitfenster (UTC): Start, Peak, Mitigation, Stabilitätsfenster.
• Beispiel-Flows: 3–5 betroffene 5-Tuples, inklusive Richtung und Paketgröße.
• Probe-Ergebnisse: multi-flow, bidirektional, small/large.
• Telemetry: per-interface/per-member Drops/Errors, Queue Drops, Auslastung.
• Routing-Snapshots: RIB/FIB, Next-Hop-Reachability, Policy-Hit-Counter, ggf. Community/RTBH-Indizien.
• Flow-Summaries: one-way flow Anteil, Top-Ziel-ASNs, Traffic-Shift.

Häufige Fehlinterpretationen, die Blackhole-Diagnosen verzögern

• „BGP ist up, also läuft es“: Control Plane kann stabil sein, während die Data Plane dropt (MTU, Queueing, Partial Failure).
• „Traceroute zeigt Hop X“: ICMP kann gerate-limited sein; ECMP kann Pfade variieren; Hop-Loss ist kein Beweis.
• „Interface ist up, also ist der Link ok“: Optik-Degradation oder einzelne LAG-Member können still droppen.
• „Nur einige Kunden, also Kundenseite“: ECMP macht providerseitige Partial Failures selektiv sichtbar.

Outbound-Ressourcen

• RFC 2991 (Multipath Issues in Next-Hop Selection)
• RFC 2992 (Analysis of an ECMP Algorithm)
• RFC 1191 (Path MTU Discovery IPv4)
• RFC 8201 (Path MTU Discovery IPv6)
• RFC 4271 (BGP-4, Routing-Policy-Kontext)
• RFC 7348 (VXLAN, falls Blackholes im Overlay-Kontext auftreten)
• RFC 7432 (EVPN, Overlay-Control-Plane im Provider-Umfeld)
• MANRS (Operational Best Practices für Routing-Sicherheit und Incident-Prozesse)

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.