Route Redistribution sauber designen: Tagging, Filtering, Loop Prevention

Route Redistribution ist einer der häufigsten Auslöser für Routing-Incidents: plötzlich explodiert die Routing-Tabelle, Traffic nimmt unerwartete Pfade oder es entstehen Loops zwischen IGP und BGP. Der Grund ist simpel: Redistribution verbindet unterschiedliche Routing-Domänen mit unterschiedlichen Metriken, Präferenzen und Failure-Mechanismen. Sauberes Design bedeutet deshalb: nur explizit erlaubte Prefixes redistributen (Filtering), jede redistributete Route markieren (Tagging) und Rückkopplungen konsequent verhindern (Loop Prevention). Dieser Artikel zeigt ein praxistaugliches Vorgehensmodell und robuste Konfigurationsmuster auf Cisco Routern.

Warum Redistribution gefährlich ist (und wann sie sinnvoll ist)

Redistribution ist notwendig, wenn zwei Routing-Protokolle oder Routing-Quellen Informationen austauschen müssen, z. B. OSPF ↔ BGP, static ↔ OSPF oder IS-IS ↔ BGP. Gefährlich wird es, wenn du „alles“ redistributest oder Metriken/Tags nicht sauber setzt.

• Sinnvoll: Edge-Router, der Default/Internet aus BGP ins IGP bringt
• Sinnvoll: Migration zwischen IGPs (OSPF ↔ IS-IS) in Übergangsphasen
• Riskant: bidirektionale Redistribution ohne Policy/Tags

Grundprinzip: „Whitelist statt Blacklist“

Die wichtigste Regel ist operativ: Nur Prefixes, die du explizit erlaubst, dürfen in die andere Domäne. Alles andere wird verworfen. So verhinderst du Route-Leaks und LSDB-/RIB-Explosionen.

• Prefix-Lists als Whitelist
• Route-Maps für Policy (Tagging, Metric, Set community)
• Default: deny

Tagging: Jede redistributete Route bekommt ein Herkunftslabel

Tags sind dein Loop-Prevention-Werkzeug Nummer 1. Du markierst Routen beim Eintritt in Domäne B mit einem Tag, und du verhinderst beim Rückweg, dass getaggte Routen wieder zurück redistributet werden. Ohne Tags ist bidirektionale Redistribution fast immer ein Risiko.

Tagging-Logik

$\text{Import(A→B)} \to \text{tag = A}, \text{Export(B→A)} \to \text{deny if tag = A}$

Tagging mit Route-Map (Beispiel)

route-map RM_OSPF_TO_BGP permit 10
 match ip address prefix-list PL_OSPF_EXPORT
 set tag 100

Filtering: Prefix-Lists sauber bauen (mit Aggregation)

Filtering beginnt beim IP-Plan. Wenn du zusammenhängende Bereiche sauber planst, kannst du mit wenigen Prefix-List-Einträgen viel abdecken. Achte darauf, nicht aus Versehen „zu breit“ zu erlauben.

Beispiel: Nur ausgewählte interne Netze exportieren

ip prefix-list PL_OSPF_EXPORT seq 10 permit 10.10.0.0/16 le 24
ip prefix-list PL_OSPF_EXPORT seq 20 permit 10.20.0.0/16 le 24
ip prefix-list PL_OSPF_EXPORT seq 100 deny 0.0.0.0/0 le 32

Metriken: Warum „metric 1“ fast nie richtig ist

Wenn du Routen redistributest, musst du eine Metrik in der Ziel-Domäne definieren. Ohne definierte Metrik wirken Routen oft „zu attraktiv“ oder „zu teuer“. In OSPF ist außerdem die Wahl zwischen E1 und E2 relevant.

• OSPF External E2: Standard, Kosten unabhängig vom internen Pfad
• OSPF External E1: addiert internen Pfad → bessere Exit-Pfadwahl
• IS-IS: Level und Metrik sauber setzen, sonst suboptimale Pfade

OSPF: E1 vs. E2 als Denkmodell

$\text{E1}=\text{internal}+\text{external}, \text{E2}\approx \text{external only}$

Loop Prevention: Drei Ebenen, die zusammenarbeiten

Robuste Loop-Prevention ist redundant: Tags sind die Hauptlinie, aber du ergänzt sie durch Filter, Domänengrenzen und – wo sinnvoll – unterschiedliche Administrative Distance/Preference-Modelle.

• Ebene 1: Tags (deny Rückimport)
• Ebene 2: Prefix-Filtering (nur Whitelist)
• Ebene 3: Domänengrenzen (Redistribution nur an definierten Punkten)

Praxispattern 1: Static → OSPF (kontrolliert, mit Tag)

Typisch am Edge: Ein statisches Netz oder eine Default Route soll ins OSPF. Wichtig: nur definierte Prefixes und ein Tag, damit es bei komplexeren Designs nicht zurückleakt.

Prefix-List + Route-Map

ip prefix-list PL_STATIC_TO_OSPF seq 10 permit 0.0.0.0/0
route-map RM_STATIC_TO_OSPF permit 10
 match ip address prefix-list PL_STATIC_TO_OSPF
 set tag 200

OSPF Redistribution

router ospf 10
 redistribute static subnets route-map RM_STATIC_TO_OSPF

Praxispattern 2: OSPF → BGP (Enterprise Edge Export)

Dieses Pattern ist üblich, wenn interne Netze ins BGP (z. B. zum Provider oder ins DC) exportiert werden sollen. Du whitelists Prefixes und setzt Tags/Communities zur Nachverfolgung.

Prefix-List + Route-Map

ip prefix-list PL_OSPF_TO_BGP seq 10 permit 10.10.0.0/16 le 24
ip prefix-list PL_OSPF_TO_BGP seq 20 permit 10.20.0.0/16 le 24
route-map RM_OSPF_TO_BGP permit 10

match ip address prefix-list PL_OSPF_TO_BGP

set tag 300

BGP Redistribution

router bgp 65000
 redistribute ospf 10 route-map RM_OSPF_TO_BGP

Praxispattern 3: BGP → OSPF (Default und selektive Externals)

Das gefährlichste Pattern ist BGP → OSPF, weil du sehr schnell zu viele Routen ins IGP ziehen kannst. In Enterprise ist deshalb die Default Route (0.0.0.0/0) das Standardmuster, optional ergänzt um wenige „must-have“ Prefixes.

Nur Default aus BGP ins OSPF

ip prefix-list PL_BGP_TO_OSPF seq 10 permit 0.0.0.0/0
route-map RM_BGP_TO_OSPF permit 10

match ip address prefix-list PL_BGP_TO_OSPF

set metric 20

set metric-type type-1

set tag 400
router ospf 10

redistribute bgp 65000 subnets route-map RM_BGP_TO_OSPF

Bidirektionale Redistribution: Nur mit klarer Boundary und Tags

Bidirektional (A↔B) ist der Worst Case. Wenn es notwendig ist (Migration), dann nur an exakt definierten Routern, mit strikten Whitelists und Tag-Blocking in beide Richtungen. Zusätzlich ist ein Staged Rollout Pflicht.

Beispiel: Tag-Blocking beim Rückimport

route-map RM_BGP_TO_OSPF deny 5
 match tag 300
route-map RM_BGP_TO_OSPF permit 10
 match ip address prefix-list PL_BGP_TO_OSPF
 set tag 400

Verification: Beweise statt Bauchgefühl

Nach jeder Redistribution-Änderung musst du prüfen: Welche Prefixes wurden übernommen, welche Tags/Metriken sind gesetzt, und gibt es unerwartete Routen. Diese Checks sind auch ideal für Drift Detection.

OSPF Seite prüfen

show ip route ospf
show ip ospf database external
show ip ospf database nssa-external

BGP Seite prüfen

show ip bgp
show ip bgp <prefix>

Route-Map/Prefix-List prüfen

show route-map
show ip prefix-list

Typische Fehler (Pitfalls) und schnelle Gegenchecks

Die meisten Redistribution-Probleme sind Copy/Paste-Fehler oder ein zu breites Match. Unter Zeitdruck prüfst du zuerst „wird zu viel redistributet?“ und „gibt es Rückkopplung?“.

• Prefix-List zu breit: plötzlich tausende Routen im IGP
• Kein Tagging: bidirektionaler Loop
• Metric falsch: falscher Exit, Traffic zieht auf den falschen Router
• Stub/NSSA falsch: Externals landen in der falschen Area

Quick Checks

show ip route | include O E|O IA|O N
show ip ospf database external | count
show ip bgp | count
show logging | include OSPF|BGP

Operational Best Practices: Redistribution als Change-Produkt

Redistribution gehört in ein Change Runbook: Pre-Checks (RIB/LSDB Größen), Change in kleinen Schritten, Post-Checks und ein klarer Rollback. Damit verhinderst du „Redistribution-Fail“ als Major Incident.

• Pre: Route counts, LSDB counts, CPU baseline
• Change: erst Filter/Tags, dann redistribute aktivieren
• Post: Counts vergleichen, kritische Prefixes testen

Runbook-Commands

show ip route summary
show ip ospf database external | count
show ip bgp summary
show processes cpu sorted
show ip prefix-list
show route-map

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

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

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.