Site icon bintorosoft.com

Troubleshooting MPLS Blackholes: LFIB, CEF und Label Imposition prüfen

Red Snapper

Organized network. 3d render white isolated graphic background

MPLS Blackholes sind besonders unangenehm, weil sie oft selektiv auftreten: Routing wirkt „gesund“, BGP/OSPF Nachbarn sind up, aber bestimmte Prefixes sind nicht erreichbar oder nur in eine Richtung. Der Grund liegt fast immer in einer Inkonsistenz zwischen Control Plane (RIB/BGP/LDP/SR) und Data Plane (CEF/FIB/LFIB). Ein klassischer Fall: Die IP-Route existiert, aber die Label-Imposition (Push) fehlt oder zeigt auf ein falsches Out-Interface, oder die LFIB hat einen Swap/Pop-Eintrag, der nicht zur aktuellen Next-Hop-Reachability passt. Dieses Tutorial ist eine Profi-Checkliste, um MPLS Blackholes systematisch zu isolieren – mit Fokus auf LFIB, CEF und Label-Imposition auf Cisco IOS XE.

Was ein „MPLS Blackhole“ technisch ist

Ein Blackhole entsteht, wenn Pakete in der Data Plane verworfen werden, obwohl die Control Plane eine gültige Route anzeigt. In MPLS passiert das typischerweise an drei Stellen: beim Push (Ingress), beim Swap (Transit) oder beim Pop/Lookup (Egress).

Denkmodell

Blackhole ≈ Control Plane OK  +  Data Plane inkonsistent

Vorbereitung: Ein konkretes Zielprefix und ein konkreter Flow

Profis debuggen nie „MPLS allgemein“, sondern immer ein konkretes Prefix (z. B. PE-Loopback oder ein Kundenprefix) und einen konkreten Pfad (Ingress → Transit → Egress). Wähle ein Ziel, das zuverlässig reproduzierbar fehlschlägt.

Step 1: IP-Routing (RIB) vs. CEF (FIB) abgleichen

Der erste Check ist banal, aber entscheidend: Steht die Route nur in der RIB, oder ist sie wirklich in CEF programmiert? Viele Blackholes entstehen durch FIB-Programming-Verzögerungen oder falsche Next-Hop-Resolution.

RIB prüfen

show ip route <dst-ip>
show ip route <dst-prefix>

CEF prüfen (entscheidend)

show ip cef <dst-ip> detail
show ip cef exact-route <src-ip> <dst-ip>

Interpretation

Step 2: LFIB prüfen – existiert ein Label-Forwarding-Entry?

Wenn MPLS im Spiel ist, muss die Forwarding-Ebene einen passenden MPLS-Entry haben. Du prüfst die MPLS Forwarding Table: In-Label, Operation (Swap/Pop), Out-Label, Out-Interface, Next-Hop.

LFIB/LFWD Tabelle prüfen

show mpls forwarding-table
show mpls forwarding-table | include <dst-ip>

Transit-Muster erkennen

Step 3: Label Imposition am Ingress beweisen (Push)

Der häufigste „unsichtbare“ Fehler ist fehlende Imposition: Der Router forwardet IP, obwohl er MPLS pushen sollte – oder er pusht ein falsches Label/Stack. Du beweist Imposition über CEF-Details und die MPLS-Label-Zuordnung zum Next-Hop.

Imposition in CEF sichtbar machen

show ip cef <dst-ip> detail

Label-Bindings prüfen (LDP-basierter Transport)

show mpls ldp bindings <dst-prefix>
show mpls ldp neighbor

SR-basierter Transport (wenn SR-MPLS)

show segment-routing mpls sid-database
show mpls forwarding-table | include 160

Step 4: Next-Hop Reachability ist „die Wahrheit“

Viele MPLS Blackholes sind keine „Label“-Probleme, sondern Next-Hop-Probleme: Das Label zeigt auf einen Next-Hop, der im IGP nicht (mehr) erreichbar ist, oder der Traffic nimmt durch ECMP einen Pfad, der keine MPLS-Fähigkeit hat (z. B. Interface ohne MPLS).

Checks

show ip route <next-hop>
show ip cef <next-hop> detail
show mpls interfaces

Step 5: ECMP und „ein Pfad ist kaputt“

Selektive Blackholes sind oft ECMP-induziert: Ein Hash landet auf einem Next-Hop, der kein gültiges Label-Forwarding hat oder MTU/Drops produziert. Deshalb ist exact-route (oder ein Flow-basierter Test) wichtig.

ECMP sichtbar machen

show ip cef <dst-ip> internal
show ip cef exact-route <src-ip> <dst-ip>

Praxis-Tipp

Step 6: PHP und Egress-Blackholes (Pop & Lookup)

Wenn Transport ok ist, kann der Egress trotzdem blackholen: Nach PHP (Outer Label weg) muss das verbleibende Label (VPN) oder das IP Lookup in der richtigen VRF stimmen. Fehler sind häufig: falsche RT-Imports, fehlende VPN-Labels, CEF in der VRF nicht programmiert.

L3VPN Checks (Egress)

show ip bgp vpnv4 all summary
show ip route vrf <VRF> <customer-prefix>
show ip cef vrf <VRF> <dst-ip> detail
show mpls forwarding-table

Step 7: MTU/Fragmentierung als „Blackhole-Light“

Viele Blackholes sind eigentlich MTU-Drops: kleine Pakete gehen, große nicht. In MPLS wird das durch Label-Stack und Encapsulation verstärkt. Du prüfst MTU, Drops und testest mit DF-Pings.

MTU & Drops

show interfaces | include MTU|drops|error
ping <dst> df-bit size 1472 repeat 5
ping <dst> df-bit size 1400 repeat 5

Step 8: Plattform-Drops und Punt Paths (IOS XE/QFP)

Wenn Control Plane und Tabellen „gut“ aussehen, kann die Hardware-Dataplane droppen (ACL/QoS/CoPP/ASIC). Auf IOS XE Plattformen mit QFP sind Drop-Statistiken ein sehr schneller Hinweis, ob es ein Data-Plane Drop und kein Routing-Problem ist.

QFP Drops

show platform hardware qfp active statistics drop
show platform hardware qfp active interface statistics

Fault Isolation Map: Wo ist der Break Point?

Ein sauberer Abschluss jeder Analyse ist: an welchem Hop bricht es? Du nutzt MPLS Traceroute und korrelierst den Hop mit LFIB/CEF und Interface Counters. So wird aus „MPLS kaputt“ eine konkrete Reparaturmaßnahme.

MPLS Traceroute

traceroute mpls ipv4 <remote-pe-loopback>

Hop-Korrelation

show mpls forwarding-table | include Pop|Swap
show ip cef <dst-ip> detail
show interfaces <out-if>

Typische Root Causes (und der passende Fix)

Diese Ursachen sind in realen Backbones am häufigsten. Der Schlüssel ist, sie schnell anhand der Checks oben zu erkennen.

Quick-Runbook: MPLS Blackhole Debug (Copy & Paste)

Dieses Paket ist die „unter Zeitdruck“-Sequenz, die in den meisten Fällen innerhalb weniger Minuten den Fehlerbereich eingrenzt.

! 1) RIB/CEF
show ip route <dst-ip>
show ip cef <dst-ip> detail
show ip cef exact-route <src-ip> <dst-ip>

! 2) MPLS/LFIB

show mpls interfaces

show mpls forwarding-table | include 

show mpls ldp neighbor

show mpls ldp bindings 


! 3) Path/OAM

traceroute mpls ipv4 


! 4) Drops/MTU

show interfaces | include MTU|drops|error

ping  df-bit size 1472 repeat 5

show platform hardware qfp active statistics drop

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

Sie erhalten

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.

Exit mobile version