Site icon bintorosoft.com

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

Red Snapper

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.

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.

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.

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“.

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 als Kernprinzip (MathML)

GewinnerRoute = Route mit maximaler Präfixlänge (/n)

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.

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.

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.

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.

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.

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.

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.

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“.

Outbound-Links für Standards und Hintergrundwissen

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