Site icon bintorosoft.com

Blackhole-Routing: FIB/RIB prüfen als Beweis

Red Snapper

Young it service man repairing computer

Blackhole-Routing bezeichnet eine Routing-Situation, in der Pakete zwar scheinbar korrekt geroutet werden, aber in der Praxis „verschwinden“: Der Traffic erreicht sein Ziel nicht, ohne dass ein eindeutiger Link-Down oder ein klarer Fehler im Monitoring sichtbar ist. Besonders tückisch wird es, wenn Monitoring nur Control-Plane-Indikatoren betrachtet (BGP/OSPF „up“, Interfaces „up“) und trotzdem Nutzer Timeouts melden. Das Hauptkeyword Blackhole-Routing steht in vielen Incident-Reports, aber als Beweis zählt am Ende nicht ein Bauchgefühl, sondern die technische Kette: Welche Route steht in der RIB (Routing Information Base), welche Route ist tatsächlich in der FIB (Forwarding Information Base) installiert, und wie wird der Traffic in Hardware oder Software wirklich weitergeleitet? Genau hier liegt der entscheidende Ansatz: Wer systematisch RIB und FIB prüft, kann Blackholing nicht nur vermuten, sondern nachweisen – und gleichzeitig die Ursache eingrenzen, etwa falsche Next-Hops, fehlende Rekursion, fehlerhafte Policy, VRF-Leaks oder eine unvollständige Programmierung in TCAM/ASIC.

Grundlagen: Was ist Blackhole-Routing und welche Varianten gibt es?

Im Kern bedeutet Blackhole-Routing, dass ein Router oder Switch Traffic für ein Präfix annimmt, aber nicht korrekt an einen gültigen nächsten Hop weiterleitet. Das kann in unterschiedlichen Formen auftreten:

Für die Fehlersuche ist die Unterscheidung wichtig, weil explizites Blackholing häufig gewollt und dokumentiert ist, während unbeabsichtigtes Blackholing meist als Incident auftritt und oft aus RIB/FIB-Divergenz resultiert.

RIB und FIB: Warum die Unterscheidung der Schlüssel zum Beweis ist

Die RIB (Routing Information Base) ist die „Wahrheit“ der Control Plane: Hier stehen alle gelernten Routen aus BGP, OSPF, statischen Einträgen, Connected, EVPN/VPN usw. Die FIB (Forwarding Information Base) ist die „Wahrheit“ der Data Plane: Sie enthält die tatsächlich für die Paketweiterleitung genutzten Einträge, oft in Hardware (ASIC/TCAM) oder in einer Software-FIB. In idealen Situationen entspricht die FIB dem aus der RIB ausgewählten Best Path. In realen Netzen können jedoch Abweichungen entstehen.

Typische Gründe für RIB/FIB-Divergenz

Der Beweis für Blackhole-Routing entsteht, wenn Sie zeigen können, dass (a) die RIB eine Route und einen Next-Hop vorgibt, (b) die FIB entweder keinen passenden Eintrag hat oder einen anderen Weiterleitungsweg nutzt, und (c) die Weiterleitung in der Datenebene zu Drops führt.

Symptome: Wie Blackholing in der Praxis aussieht

Blackhole-Routing ist selten ein „alles geht gar nicht“-Problem. Häufig ist es selektiv: bestimmte Subnetze sind nicht erreichbar, bestimmte Dienste brechen ab, während andere funktionieren. Typische Indikatoren:

Beweisführung: Systematisch RIB und FIB prüfen

Um Blackhole-Routing belastbar nachzuweisen, hilft ein klarer Ablauf. Ziel ist, jede Annahme durch einen überprüfbaren Zustand zu ersetzen: Welche Route ist gewählt, welcher Next-Hop ist aktiv, ist die Route wirklich in der FIB, und ist die L2-/Adjacency zur Weiterleitung stabil?

Schritt 1: Betroffenes Präfix eindeutig definieren

Starten Sie mit einem konkreten Ziel: eine IP oder ein Präfix, das nicht erreichbar ist. Prüfen Sie, ob das Problem IPv4, IPv6 oder beides betrifft. Notieren Sie außerdem den erwarteten Pfad (z. B. „über DCI“, „über Internet-Edge“, „über Firewall-Cluster“).

Schritt 2: RIB prüfen – welche Route ist aus Sicht der Control Plane aktiv?

In der RIB prüfen Sie:

Wenn die RIB schon hier „komisch“ aussieht (z. B. Next-Hop zeigt auf ein unerwartetes Segment), liegt die Ursache oft in Policies oder Route Leaks. Wenn die RIB plausibel ist, aber der Traffic trotzdem verschwindet, wird die FIB-Prüfung entscheidend.

Schritt 3: FIB prüfen – ist die Route wirklich im Forwarding installiert?

Die zentrale Frage lautet: Existiert ein FIB-Eintrag, der das Zielpräfix abdeckt, und zeigt er auf denselben Next-Hop wie die RIB? Prüfen Sie dabei auch:

Ein typischer Beweis für Blackholing ist die Situation: In der RIB ist Route X aktiv, aber in der FIB fehlt sie oder sie ist durch ein unerwartetes spezifischeres Präfix übersteuert. Dann kann die Datenebene nicht so forwarden, wie die Control Plane „verspricht“.

Schritt 4: Adjacency (ARP/ND) und Next-Hop-Auflösung prüfen

Selbst wenn Route und FIB stimmen, kann der Forwarding-Pfad scheitern, wenn der Next-Hop auf Layer 2 nicht auflösbar ist. Prüfen Sie daher:

Schritt 5: Data-Plane-Verifikation – Drops und Telemetrie

Um den Nachweis zu vervollständigen, ist ein Blick auf Data-Plane-Indikatoren hilfreich: Drops am Interface, ACL-Hits, PBR-Zähler, Firewall-Session-Logs, oder Flow-Telemetrie (NetFlow/IPFIX/sFlow). So schließen Sie aus, dass das Paket zwar korrekt geroutet wird, aber an einer Policy oder Security-Komponente verworfen wird.

Häufige Ursachen und wie RIB/FIB sie entlarvt

Die RIB/FIB-Prüfung ist nicht nur „Beweis“, sondern auch ein sehr schneller Weg zur Root-Cause-Klasse.

Falscher Next-Hop durch Policy oder Route Leak

Next-Hop rekursiv nicht erreichbar

FIB-Programmierung scheitert (Ressourcen/TCAM/ASIC)

Partielles Blackholing durch ECMP oder LAG

Blackhole-Routing vs. absichtliches Blackholing (DDoS-Abwehr)

In vielen Netzen wird Blackhole-Routing absichtlich eingesetzt, um Angriffe zu dämpfen – etwa durch statische Nullrouten oder BGP-Blackhole-Communities, die Traffic zu einem „discard“-Next-Hop lenken. Der entscheidende Unterschied ist die Dokumentation und Intention: Absichtliches Blackholing ist zeitlich begrenzt, nachvollziehbar und in Policies eingebettet. Unbeabsichtigtes Blackholing dagegen trifft häufig auch legitimen Traffic und ist nicht sauber begründet.

Für Hintergrundwissen zu BGP als Routing-Protokoll ist die Spezifikation zu BGP-4 (RFC 4271) hilfreich. Zum Konzept der Forwarding-Entscheidung und Longest Prefix Match bietet die Übersicht zu Longest Prefix Match eine gut verständliche Grundlage.

Praktische Strategien: Blackholing eingrenzen, ohne das Netz zu destabilisieren

Wenn ein Incident läuft, ist die Versuchung groß, „einfach Routes zu löschen“ oder Sessions zu resetten. Das kann jedoch Routing-Churn und weitere Ausfälle verursachen. Ein strukturierter Ansatz reduziert Risiko:

Stabilisieren vor Optimieren

Gezielte Verifikation statt breiter Maßnahmen

Policies und Guardrails nutzen

Messbarkeit: Warum der Beweis ohne FIB oft unvollständig bleibt

Viele Diagnosen bleiben stecken, weil nur die RIB betrachtet wird. In modernen Netzwerken mit Hardware-Forwarding, Offloads, VRFs und komplexen Policies ist die FIB der entscheidende Wahrheitsanker. Ein sauberer Beweis für Blackhole-Routing lautet daher sinngemäß: „Die Route ist in der RIB so und so, aber die FIB zeigt X (oder nichts), und genau daraus folgen Drops im Datenpfad.“ Diese Kette ist belastbar, nachvollziehbar und für Postmortems oder Provider-Eskalationen geeignet.

Outbound-Quellen für vertiefendes Verständnis

Für die Grundlagen von BGP und dessen Route-Auswahl dient RFC 4271 (BGP-4) als Standardreferenz. Für das Forwarding-Prinzip, das bei der FIB-Prüfung zentral ist, erklärt Longest Prefix Match die Logik hinter der Auswahl der spezifischsten Route. Wer zusätzlich den Zusammenhang zwischen Routing-Tabellen und Paketweiterleitung in IP-Netzen vertiefen möchte, findet in der Übersicht zu Routingtabellen eine verständliche Einordnung, die sich gut mit der praktischen RIB/FIB-Diagnose verknüpfen lässt.

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:

Lieferumfang:

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.

 

Exit mobile version