Site icon bintorosoft.com

Subnetting-Fehlerdiagnose: Wenn Routen “verschwinden” oder blackholen

Red Snapper

Die Subnetting-Fehlerdiagnose gehört im Telco- und Provider-Betrieb zu den wichtigsten Skills, weil ein scheinbar kleiner Adressierungsfehler ganze Services „verschwinden“ lassen kann. Typische Symptome wirken auf den ersten Blick wie Routing- oder Hardwareprobleme: Routen tauchen nicht in der Tabelle auf, Prefixe werden nicht mehr announced, Traffic endet im Blackhole, oder nur bestimmte Ziele sind nicht erreichbar, während andere funktionieren. In der Praxis steckt sehr häufig eine Subnetting-Ursache dahinter: falsche Präfixlängen, überschneidende Netze, fehlerhafte Summarisierung, inkonsistente Masken auf beiden Seiten eines Links oder ein unbewusst gesetztes Null-Route-Summary. Gerade in Provider-Netzen multiplizieren sich solche Fehler, weil Adressierung direkt mit Policies verknüpft ist: IGP-Filter, BGP-Import/Export, VRF-Leaks, Aggregation-Design, FIB-Programmierung und Security-Regeln basieren auf Prefixen. Wenn ein Prefix nicht so aussieht, wie die Policy es erwartet, wird es stillschweigend verworfen – und aus Sicht des NOC „verschwindet“ es. Dieser Artikel zeigt eine praxistaugliche Vorgehensweise, um Subnetting-Fehler systematisch zu finden: von den häufigsten Ursachen über Checklisten und Denkmodelle (Longest Prefix Match, Summaries, Route-Leaks) bis zu konkreten Diagnosepfaden, wenn Routen nicht installiert werden oder Traffic blackholed. Ziel ist ein Troubleshooting-Workflow, der auch unter Incident-Druck zuverlässig funktioniert.

Was bedeutet „Route verschwindet“ vs. „Traffic blackholed“?

Bevor Sie analysieren, sollten Sie das Symptom präzisieren. Im Betrieb werden beide Fälle oft gleich beschrieben („Route weg“), haben aber unterschiedliche Ursachen.

Die beste Diagnose beginnt daher immer mit der Frage: Ist die Route im Routing (Control Plane) vorhanden? Und ist sie im Forwarding (Data Plane) wirksam?

Das wichtigste Denkmodell: Longest Prefix Match und „wer gewinnt?“

Im IP-Routing gilt das Longest Prefix Match: Von mehreren passenden Routen wird die Route mit der längsten Präfixlänge gewählt (also die spezifischste). Dieses Prinzip ist die häufigste Ursache für „plötzliche“ Blackholes nach Subnetting-Änderungen, Summarisierungen oder neuen Leaks.

Häufigste Subnetting-Ursachen, wenn Routen „verschwinden“

Viele „verschwundene“ Routen sind nicht weg, sondern werden nicht installiert oder nicht propagiert. In Provider-Netzen passiert das besonders oft durch Policies und Aggregation.

Häufigste Subnetting-Ursachen für Blackholing

Blackholes sind besonders gefährlich, weil „Routing sieht gut aus“, aber Pakete verschwinden. Subnetting spielt hier häufig über Summaries, Null-Routes und Next-Hop-Fehler hinein.

Ein strukturierter Troubleshooting-Workflow in 10 Minuten

Diese Reihenfolge ist praxistauglich, weil sie schnell zwischen Control Plane und Data Plane trennt und Subnetting-Fehler sichtbar macht.

Subnetting-Fallen bei BGP: „Network“-Statement, Aggregates und Präfixfilter

Viele „verschwundene“ Routen in BGP sind Subnetting-Probleme, weil BGP sehr strikt ist: Ein Prefix wird nur announced, wenn er exakt „passt“ – je nach Plattform entweder exakt im Routing Table existiert oder durch eine Policy erzeugt wird.

Subnetting-Fallen bei IGP: Summaries, Areas/Levels und Redistribution

In IGPs (OSPF/IS-IS) sind Subnetting-Probleme oft indirekt: nicht die Route selbst ist falsch, sondern die Verteilung, Summarisierung oder die Inter-Area/Inter-Level-Logik.

Der Klassiker: Überlappende Netze und inkonsistente Masken

Subnetting-Fehler sind besonders gemein, wenn zwei Netze überlappen oder wenn Masken nicht übereinstimmen. Das führt selten zu einem klaren Fehler, sondern zu „wackeliger“ Erreichbarkeit.

Null-Routes und Summaries: Sinnvoller Schutz, häufige Blackhole-Quelle

Viele Provider nutzen Null-Routes für Summaries bewusst: Sie verhindern, dass Traffic für „nicht existierende“ Teilnetze irgendwohin wandert. Das ist grundsätzlich richtig. Problematisch wird es, wenn die spezifischen Routen nicht überall vorhanden sind oder wenn ein Teilnetz gerade migriert wird.

VRF, Leaks und Subnetting: Wenn das Netz im falschen Kontext landet

Im Multi-Tenant-Telco ist „Route weg“ häufig „Route in der falschen VRF“. Subnetting verstärkt das, weil viele Policies VRF-spezifische Container erwarten und Overlaps bewusst zulassen.

Diagnose von Blackholes: Rückweg und Stateful Geräte

Wenn Traffic blackholed, aber Routen vorhanden sind, prüfen Sie sehr früh den Rückweg. Besonders bei Firewalls, CGNAT und Load Balancern sind asymmetrische Pfade ein häufiger Effekt von Subnetting-Änderungen (neue Summaries, neue spezifische Prefixe).

Praktische Prüfungen, die Subnetting-Fehler sichtbar machen

Prävention: Subnetting-Standards, die „Verschwinden“ verhindern

Viele Subnetting-Fehlerdiagnosen sind wiederkehrend. Telcos reduzieren sie deutlich durch Standards, die Policies und Automatisierung vereinfachen.

Checkliste: Wenn Routen verschwinden oder blackholen

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Exit mobile version