OSPF Route Redistribution: Stolperfallen und Best Practices

OSPF Route Redistribution (Umverteilung) ist der Prozess, bei dem Routen aus einer anderen Quelle (z. B. statische Routen, EIGRP oder BGP) in OSPF importiert werden. Das ist in Übergangsphasen und an Netzgrenzen oft nötig, birgt aber Risiken: unerwünschte Default Routes, Blackholes durch Over-Summarization, Routing-Loops und unkontrollierte LSA-Fluten. Mit klaren Filtern, sauberer Metrik-Strategie und kontrollierter Scope-Planung bleibt Redistribution betriebssicher.

Was passiert bei Redistribution in OSPF?

Redistributed Routen werden in OSPF als externe Routen behandelt und typischerweise als Externals in die Domain geflutet. Dadurch erhalten auch Router, die das ursprüngliche Protokoll nicht sprechen, Kenntnis dieser Netze.

• Quelle: Static, Connected, EIGRP, BGP, …
• Ziel: OSPF-Domain (Externals)
• Wirkung: mehr Routen/LSAs, potenziell größere Routing-Tabellen

Extern bedeutet: „kommt nicht aus OSPF selbst“

Externe Routen sind nicht das Ergebnis von OSPF-Link-State innerhalb der Area, sondern werden von einem ASBR (Autonomous System Boundary Router) eingespeist.

Die häufigsten Stolperfallen bei OSPF Redistribution

Die meisten Probleme entstehen nicht durch den Befehl an sich, sondern durch fehlende Kontrolle: was wird verteilt, mit welcher Metrik und wohin. Die folgenden Fehlerbilder sind in der Praxis besonders häufig.

• Zu viele Routen werden importiert (fehlender Filter)
• Unerwartete Default Route wird verteilt
• Routing-Loop durch beidseitige Redistribution
• Falsche Pfadwahl durch unpassende Metrik oder Administrative Distance
• Blackholes durch Summarization ohne Null Route

Best Practice 1: Immer filtern – nie „redistribute …“ ohne Policy

Ungefiltertes Redistribution ist ein Risiko, weil du schnell interne/temporäre Routen oder Transitnetze verteilst, die nicht global bekannt sein sollen. Nutze Route-Maps und Prefix-Lists, um nur definierte Präfixe zu importieren.

Beispiel: Nur bestimmte statische Routen in OSPF importieren

Router# configure terminal
Router(config)# ip prefix-list REDIST_STATIC seq 10 permit 172.16.10.0/24
Router(config)# ip prefix-list REDIST_STATIC seq 20 permit 172.16.20.0/24
Router(config)# route-map RM-REDIST-STATIC permit 10

Router(config-route-map)# match ip address prefix-list REDIST_STATIC

Router(config-route-map)# set metric 50

Router(config-route-map)# set metric-type type-1

Router(config-route-map)# end

Redistribution mit Route-Map aktivieren

Router# configure terminal
Router(config)# router ospf 1
Router(config-router)# redistribute static subnets route-map RM-REDIST-STATIC
Router(config-router)# end

Best Practice 2: Metric-Type (E1 vs. E2) bewusst wählen

OSPF kennt externe Routen in zwei Typen: E2 (Default in vielen Setups) und E1. Der Unterschied ist entscheidend für Pfadwahl in größeren Netzen.

• E2: Externe Metrik bleibt konstant, interne OSPF-Kosten werden nicht addiert
• E1: Interne OSPF-Kosten werden zur externen Metrik addiert (bessere Pfadsteuerung)

Merker: E1 berücksichtigt den Weg zum ASBR

$\text{E1 Cost}=\text{OSPF-intern}+\text{extern}$

Konfiguration: Metric-Type per Route-Map setzen

Router# configure terminal
Router(config)# route-map RM-REDIST-STATIC permit 10
Router(config-route-map)# set metric-type type-1
Router(config-route-map)# end

Best Practice 3: Metriken konsistent planen (und nicht „0“ lassen)

Bei Redistribution müssen Metriken explizit definiert werden, sonst entstehen unvorhersehbare Pfadpräferenzen. Plane eine klare Metrik-Strategie: z. B. WAN-Externals höher, interne Services niedriger, Default Route klar erkennbar.

Beispiel: Standardmetriken im OSPF-Prozess setzen

Damit nicht jede Redistribution-Regel eine eigene Metrik braucht, kannst du Default-Metriken definieren (Designabhängig).

Router# configure terminal
Router(config)# router ospf 1
Router(config-router)# default-metric 100
Router(config-router)# end

Best Practice 4: Beidseitige Redistribution vermeiden (Loops!)

Wenn du OSPF in ein anderes Protokoll redistribuierst und umgekehrt, entstehen schnell Loops: Routen werden exportiert, importiert und kommen „anders“ zurück. In Migrationsphasen ist das der häufigste Grund für instabiles Routing.

• Nur eine klare Redistribution-Grenze definieren (ein ASBR)
• Im Rückweg filtern oder Tagging nutzen
• Wenn bidirektional nötig: Route-Tags konsequent einsetzen

Tagging nutzen, um reimportierte Routen zu blocken (Prinzip)

Router# configure terminal
Router(config)# route-map RM-REDIST-STATIC permit 10
Router(config-route-map)# set tag 100
Router(config-route-map)# end

Router# configure terminal
Router(config)# route-map RM-BLOCK-REIMPORT deny 10
Router(config-route-map)# match tag 100
Router(config-route-map)# exit
Router(config)# route-map RM-BLOCK-REIMPORT permit 20
Router(config-route-map)# end

Default Route Redistribution: mit Vorsicht und klarer Absicht

Eine verteilte Default Route kann sinnvoll sein (z. B. Außenstellen), aber sie kann auch das gesamte Netz in ein Blackhole schicken, wenn sie von der falschen Stelle kommt. Verteile Defaults nur kontrolliert.

Default Route in OSPF announcen (bewusst)

default-information originate verteilt eine Default Route, wenn der Router selbst eine Default Route hat (oder je nach Option immer).

Router# configure terminal
Router(config)# router ospf 1
Router(config-router)# default-information originate
Router(config-router)# end

Default Route nur mit Policy/Tracking verteilen (Best Practice)

Router# show ip route | include 0.0.0.0
Router# show ip ospf database external | include 0.0.0.0

Area-Design beachten: Stub und NSSA beeinflussen Externals

Stub Areas blockieren externe LSAs, NSSA erlaubt lokale Externals (mit Übersetzung am ABR). Wenn du Redistribution einsetzt, musst du Area-Typen berücksichtigen, sonst „verschwinden“ Externals in bestimmten Areas.

• Stub/Totally Stubby: Externals kommen nicht hinein
• NSSA: lokale Externals möglich, werden am ABR übersetzt
• Normal Areas: Externals werden verteilt

Area-Typ prüfen

Router# show ip ospf
Router# show running-config | section router ospf

Summarization und Null Routes: Blackholes verhindern

Wenn du extern redistribuierte Netze zusammenfasst, kann Traffic für nicht vorhandene Teilnetze in die Summary laufen. Setze eine Null Route als „Safety Net“, damit Over-Summarization kontrolliert gedroppt wird.

Null Route für ein Summary (Beispiel)

Router# configure terminal
Router(config)# ip route 172.16.0.0 255.255.0.0 null0
Router(config)# end

Verifikation: Ist die Redistribution korrekt und kontrolliert?

Nach der Konfiguration willst du drei Dinge prüfen: Welche Routen wurden importiert, wie sehen Metrik/Typ aus und wie groß ist die Auswirkung auf LSDB/Routing-Tabelle.

Redistributed Routen in der Tabelle prüfen

Router# show ip route ospf
Router# show ip route | include O E1|O E2

LSDB-Externals prüfen

Router# show ip ospf database external
Router# show ip ospf database external | include 172.16.

Route-Map/Prefix-List Wirkung prüfen

Router# show route-map
Router# show ip prefix-list REDIST_STATIC
Router# show running-config | section route-map

Häufige Fehler und schnelle Fixes

Wenn nach Redistribution „zu viel“ oder „zu wenig“ passiert, liegt es meist an fehlenden subnets, falschen Match-Kriterien oder einem Area-Typ, der Externals blockiert.

• Keine Routen sichtbar: subnets fehlt (bei vielen Quellen nötig)
• Zu viele Routen: fehlender Filter (Prefix-List/Route-Map)
• Externals in Stub Area erwartet: Area-Typ blockt sie
• Pfadwahl komisch: E1/E2 oder Metriken inkonsistent

Quick-Checks

Router# show running-config | section router ospf
Router# show ip route | include O E1|O E2
Router# show ip ospf database external
Router# show route-map
Router# show ip prefix-list

Konfiguration speichern

Wenn nur die gewünschten Routen importiert werden und Pfadwahl/Metriken passen, speichere die Konfiguration.

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.