Route Redistribution: OSPF und EIGRP sauber verbinden

In vielen Unternehmensnetzwerken wächst die Routinglandschaft historisch: Ein Bereich nutzt OSPF, ein anderer EIGRP, dazu kommen statische Routen, VPNs oder Provider-Anbindungen. Spätestens wenn diese Domänen miteinander kommunizieren müssen, führt kein Weg an Route Redistribution vorbei. Genau darum geht es hier: OSPF und EIGRP sauber verbinden, ohne sich durch Routing-Loops, unerwartete Pfadwahl oder unkontrollierte Routenfluten Probleme ins Netz zu holen. Redistribution bedeutet vereinfacht: Ein Router (oder Layer-3-Switch) nimmt Routen aus einem Routingprotokoll auf und „übersetzt“ sie in ein anderes. Das klingt simpel, ist aber ein klassischer Bereich, in dem kleine Konfigurationsfehler große Auswirkungen haben. OSPF und EIGRP verwenden unterschiedliche Metriken, unterschiedliche Routen-Typen und unterschiedliche Mechanismen zur Pfadwahl. Ohne Filter- und Markierungsstrategie kann eine bidirektionale Redistribution schnell zu Rückkopplungen führen: Routen werden importiert, wieder exportiert, gewinnen plötzlich an Priorität – und das Netzwerk entscheidet „anders als gedacht“. Dieser Artikel vermittelt Ihnen ein praxistaugliches Vorgehen: klare Designprinzipien, saubere Filter, sinnvolle Seed-Metriken, Tagging gegen Loops sowie konkrete Cisco-Konfigurationsbeispiele, damit OSPF und EIGRP zuverlässig miteinander arbeiten und im Betrieb nachvollziehbar bleiben.

Grundprinzip: Was bedeutet Route Redistribution wirklich?

Route Redistribution ist die kontrollierte Übernahme von Routen aus einer Quelle (z. B. OSPF) in eine Ziel-Routingdomäne (z. B. EIGRP). Dabei entstehen auf dem Redistributor neue Routentypen: OSPF-Routen werden in EIGRP zu „externen“ EIGRP-Routen, und EIGRP-Routen werden in OSPF zu „externen“ OSPF-Routen. Der Redistributor ist damit ein kritischer Knoten im Design, vergleichbar mit einer Grenze zwischen Routingwelten.

• Einseitige Redistribution: Nur in eine Richtung (z. B. OSPF → EIGRP). Einfacher und weniger riskant.
• Bidirektionale Redistribution: In beide Richtungen (OSPF ↔ EIGRP). Häufig notwendig, aber deutlich fehleranfälliger.
• Kontrollpunkte: Filter, Metriken, Tags, Administrative Distance und Summaries bestimmen, wie stabil das Ergebnis ist.

Wenn Sie das Protokollverhalten standardnah vertiefen möchten, sind diese Referenzen hilfreich: RFC 2328 (OSPFv2) und RFC 7868 (EIGRP). Für Cisco-spezifische Konfigurationsoptionen sind Cisco OSPF Dokumentation und Cisco EIGRP Dokumentation geeignete Einstiegspunkte.

Warum OSPF und EIGRP nicht „einfach so“ zusammenspielen

OSPF ist ein Link-State-Protokoll mit einer Cost-basierten Metrik und Konzepten wie Areas, LSAs und externen Routentypen (E1/E2). EIGRP ist ein (in RFC-Form standardisiertes) Distance-Vector-nahes Protokoll mit DUAL und einer zusammengesetzten Metrik, die standardmäßig aus Bandbreite und Delay berechnet wird. Daraus ergeben sich zentrale Unterschiede:

• Metrikmodell: OSPF braucht eine „Cost“, EIGRP braucht (mindestens) eine Seed-Metrik oder Default-Metric, sonst werden Routen nicht sinnvoll übernommen.
• Routentypen: OSPF kennt interne und externe Routen (E1/E2), EIGRP kennt interne und externe (mit Feasible Distance/Reported Distance Logik).
• Policy-Charakter: Redistribution ist immer Policy. Ohne Filter können Sie mehr Routen verteilen, als Sie eigentlich möchten.
• Loop-Gefahr: Besonders bei bidirektionaler Redistribution ohne Tagging und klare Grenzen.

Design vor Konfiguration: Drei Fragen, die Sie klären müssen

Bevor Sie einen einzigen Redistribution-Befehl setzen, sollten Sie drei Designfragen beantworten. Das verhindert, dass Sie später mit „unerklärlicher“ Pfadwahl kämpfen.

• Welche Präfixe müssen wirklich domänenübergreifend sichtbar sein? Nicht jedes interne VLAN muss überall beworben werden.
• Wer ist der Redistributor? Ein einzelner Border-Router ist einfacher zu kontrollieren als mehrere parallele Redistributoren.
• Welche Richtung ist nötig? Wenn möglich, einseitig redistributen und Rückwege über Summaries/Default lösen.

Praxis-Tipp: Wenn Sie bidirektional redistributen müssen, planen Sie zwingend eine Tagging-Strategie und definieren Sie, welche Seite „autoritativer“ sein soll, falls Pfade konkurrieren.

Beispiel-Topologie für die Konfigurationsbeispiele

Für die Beispiele nehmen wir ein klassisches Übergangsszenario:

• Links: OSPF-Domäne (Area 0) mit Netzen 10.10.0.0/16
• Rechts: EIGRP-Domäne (AS 100) mit Netzen 10.20.0.0/16
• In der Mitte: Border-Router BR1, der an beiden Domänen hängt

Ziel: Netze aus OSPF sollen in EIGRP sichtbar sein und umgekehrt – aber kontrolliert, ohne Schleifen und ohne unnötige Präfixe.

Schlüsselkonzept: Seed-Metrik richtig setzen

Die wichtigste Regel bei Redistribution lautet: Ohne Seed-Metrik keine saubere Übernahme. OSPF kann externen Routen eine Metrik geben, und EIGRP benötigt für externe Routen eine zusammengesetzte Metrik. Zwei typische Ansätze:

• Default-Metric im Zielprotokoll setzen (global innerhalb des Routingprozesses).
• Seed-Metrik pro Redistribution-Statement bzw. per Route-Map setzen (feiner steuerbar).

EIGRP braucht eine explizite Metrik

EIGRP verwendet eine Metrik, die in Cisco-CLI meist als fünf Werte angegeben wird: bandwidth delay reliability load mtu. Ein verbreitetes, praxistaugliches Beispiel (nicht universell, aber funktional) ist:

• Bandwidth: 100000 (in Kbit/s, z. B. 100 Mbit/s als Referenz)
• Delay: 10 (in Zehner-Mikrosekunden-Einheiten, abhängig von Plattformdarstellung)
• Reliability: 255 (maximal)
• Load: 1 (minimal)
• MTU: 1500

Wichtig ist weniger der exakte Wert, sondern Konsistenz und Dokumentation. Seed-Metriken sollten nachvollziehbar sein und zur gewünschten Pfadwahl passen.

OSPF extern: E1 oder E2 bewusst wählen

Wenn Sie EIGRP-Routen in OSPF redistributen, entstehen externe OSPF-Routen. OSPF kennt zwei externe Typen:

• E2: Externe Metrik bleibt konstant, interne Kosten zur ASBR werden nicht addiert (häufig Default).
• E1: Externe Metrik plus interne Kosten zur ASBR werden addiert (oft sinnvoller, wenn es mehrere ASBRs gibt).

In Designs mit mehreren Redistributoren ist E1 häufig die bessere Wahl, weil die Nähe zum Redistributor berücksichtigt wird.

Einseitige Redistribution: OSPF nach EIGRP (einfacher Einstieg)

Wenn Sie zunächst nur OSPF-Netze in die EIGRP-Domäne bringen möchten, ist das Risiko geringer. Sie brauchen vor allem eine saubere Filterung und eine Seed-Metrik.

Konfiguration auf BR1: OSPF → EIGRP

configure terminal
router eigrp 100
no auto-summary
redistribute ospf 1 metric 100000 10 255 1 1500
end

Damit würden grundsätzlich alle OSPF-Routen in EIGRP erscheinen. In der Praxis ist das meist zu breit. Deshalb ist der nächste Schritt: filtern.

Filterung mit Prefix-List und Route-Map

Beispiel: Nur 10.10.0.0/16 soll von OSPF nach EIGRP:

configure terminal
ip prefix-list OSPF-TO-EIGRP seq 5 permit 10.10.0.0/16
route-map RM-OSPF-TO-EIGRP permit 10
match ip address prefix-list OSPF-TO-EIGRP
router eigrp 100
no redistribute ospf 1 metric 100000 10 255 1 1500
redistribute ospf 1 route-map RM-OSPF-TO-EIGRP metric 100000 10 255 1 1500
end

Best Practice: Starten Sie bei Redistribution immer mit einem „deny by default“-Denken. Erlauben Sie nur, was wirklich benötigt wird.

Einseitige Redistribution: EIGRP nach OSPF

Der umgekehrte Weg ist ähnlich, aber OSPF erwartet eine Metrik und optional den externen Typ (E1/E2).

Konfiguration auf BR1: EIGRP → OSPF

configure terminal
router ospf 1
redistribute eigrp 100 subnets metric 50 metric-type 1
end

Wichtige Details:

• subnets: sorgt dafür, dass auch nicht-classful Präfixe korrekt übernommen werden.
• metric: setzt eine externe OSPF-Metrik.
• metric-type 1: erzeugt E1, häufig sinnvoll bei mehreren potenziellen ASBRs.

Filterung mit Prefix-List und Route-Map in OSPF

Beispiel: Nur 10.20.0.0/16 soll aus EIGRP nach OSPF:

configure terminal
ip prefix-list EIGRP-TO-OSPF seq 5 permit 10.20.0.0/16
route-map RM-EIGRP-TO-OSPF permit 10
match ip address prefix-list EIGRP-TO-OSPF
router ospf 1
no redistribute eigrp 100 subnets metric 50 metric-type 1
redistribute eigrp 100 subnets metric 50 metric-type 1 route-map RM-EIGRP-TO-OSPF
end

Bidirektionale Redistribution: Der kritische Teil

Wenn Sie OSPF und EIGRP in beide Richtungen verbinden müssen, steigt die Komplexität deutlich. Der Kern des Problems: Eine Route, die aus OSPF nach EIGRP importiert wurde, darf nicht wieder zurück nach OSPF exportiert werden – sonst drohen Rückkopplungen, instabile Pfadwahl oder unerwartete Präferenzwechsel. Die professionelle Lösung besteht aus drei Bausteinen:

• Tagging: importierte Routen erhalten ein Tag, das beim Rückexport geprüft und geblockt wird.
• Filterung: nur benötigte Präfixe werden redistributet.
• Klare Präferenz: Administrative Distance und Metriken so setzen, dass ein Protokoll nicht „aus Versehen“ gewinnt.

Tagging-Konzept: Routen markieren und Rückkopplung verhindern

In OSPF können externe Routen getaggt werden. Dieses Tag können Sie in Route-Maps auswerten. Ein praxistaugliches Muster:

• Alles, was aus EIGRP nach OSPF geht, bekommt OSPF-Tag 200.
• Wenn OSPF-Routen nach EIGRP redistributet werden, blocken wir alle Routen, die bereits Tag 200 tragen (also ursprünglich aus EIGRP kamen).

EIGRP → OSPF: Tag setzen

configure terminal
route-map RM-EIGRP-TO-OSPF permit 10
match ip address prefix-list EIGRP-TO-OSPF
set tag 200
router ospf 1
redistribute eigrp 100 subnets metric 50 metric-type 1 route-map RM-EIGRP-TO-OSPF
end

OSPF → EIGRP: Rückkopplung blocken (Tag matchen)

Hier prüfen wir in der Route-Map: Wenn eine OSPF-Route Tag 200 hat, wird sie nicht in EIGRP redistributet.

configure terminal
route-map RM-OSPF-TO-EIGRP deny 5
match tag 200
route-map RM-OSPF-TO-EIGRP permit 10
match ip address prefix-list OSPF-TO-EIGRP
router eigrp 100
redistribute ospf 1 route-map RM-OSPF-TO-EIGRP metric 100000 10 255 1 1500
end

Dieses Muster ist in der Praxis sehr wirkungsvoll: Sie verhindern, dass eine Route „im Kreis“ wieder zurückkommt, und behalten Kontrolle über die Richtung.

Administrative Distance: Pfadwahl stabil halten

Selbst wenn Sie Loops verhindern, kann es passieren, dass Router zwischen zwei Protokollen „springen“, wenn die Präferenz nicht klar ist. Cisco verwendet Administrative Distance (AD), um zu entscheiden, welches Protokoll bei gleicher Präfixlänge gewinnt. Typisch gilt: OSPF interne Routen und EIGRP interne Routen haben unterschiedliche AD-Werte; externe Routen wiederum ebenfalls. In Redistribution-Szenarien sollten Sie bewusst prüfen, ob eine extern redistributete Route nicht plötzlich eine unerwünschte Priorität erhält.

• Ziel: Das interne Protokoll soll intern dominieren, und extern redistributete Routen sollen nicht „aus Versehen“ lokale, bessere Pfade verdrängen.
• Praxis: AD-Anpassungen sind möglich, aber sollten sparsam und dokumentiert eingesetzt werden.

Wenn Sie mit AD arbeiten, setzen Sie es strategisch und testen Sie Pfadwahl nach Ausfällen. Unkoordinierte AD-Änderungen können Troubleshooting erschweren.

Summarization statt „Route-Flut“: Weniger ist oft mehr

In gemischten OSPF/EIGRP-Umgebungen ist Summarization einer der wichtigsten Stabilitätshebel. Statt viele /24-Routen zu redistributen, fassen Sie Standortpräfixe zusammen und redistributen nur die Summaries. Das senkt die Größe der Routingtabellen und reduziert die Wahrscheinlichkeit von unerwarteten Pfaden.

• EIGRP Summarization: oft interfacebasiert möglich (z. B. Richtung Border).
• OSPF Summarization: häufig an ABRs/ASBRs sinnvoll (designabhängig).
• Voraussetzung: IP-Adressplanung muss aggregierbar sein.

Best Practice: Planen Sie Standorte oder Zonen so, dass sie in zusammenhängenden Blöcken liegen (z. B. 10.20.0.0/16 pro Standort), damit Summarization technisch und organisatorisch einfach bleibt.

Verifikation: So prüfen Sie, ob Redistribution korrekt und sicher läuft

Nach der Konfiguration ist Verifikation Pflicht. Prüfen Sie nicht nur, ob Routen auftauchen, sondern auch Routentyp, Tagging und Pfadwahl.

OSPF-Seite prüfen

• show ip ospf neighbor (OSPF stabil?)
• show ip route ospf (OSPF-Routen, externe Typen E1/E2)
• show ip ospf database external (externe LSAs, hilfreich für Tagging/Typen)

EIGRP-Seite prüfen

• show ip eigrp neighbors (EIGRP stabil?)
• show ip route eigrp (interne vs. externe EIGRP-Routen)
• show ip eigrp topology (Successor/Feasible Successor, externe Kennzeichnung)

Border-Router prüfen

• show running-config | section router ospf
• show running-config | section router eigrp
• show route-map (Route-Maps, Trefferzähler, Reihenfolge)
• show ip prefix-list (Prefix-Lists, Matches)

Praxis-Tipp: Route-Maps sollten Treffer haben. Wenn eine Route-Map „0 matches“ zeigt, ist die Filterlogik oft falsch (z. B. falsche Prefix-List, falsche Reihenfolge, fehlendes „permit“ am Ende).

Häufige Fehlerbilder und schnelle Fixes

Redistribution-Probleme sind meist wiederkehrende Muster. Diese Ursachen tauchen besonders häufig auf:

Routen werden nicht übernommen

• Fehlende Seed-Metrik: EIGRP kann ohne Metric keine externen Routen sauber übernehmen.
• Fehlendes „subnets“ in OSPF: Präfixe werden nicht übernommen oder nur classful.
• Filter blockt alles: Prefix-List zu restriktiv oder Route-Map falsch.

Routen flappen oder Pfade sind „unerwartet“

• Bidirektional ohne Tagging: Rückkopplung führt zu wechselnder Pfadwahl.
• Unklare Präferenz: AD/Metrik führt dazu, dass extern redistributete Routen interne Pfade verdrängen.
• Zu viele Präfixe: LSDB/Routingtable wächst, Konvergenz wird schwerer.

Blackholing durch Summaries

• Summary umfasst Netze, die nicht existieren: Traffic landet im „Nirvana“.
• Fehlende spezifische Rückwege: Summaries sind nur in eine Richtung sauber umgesetzt.

Lösung: Summaries nur verwenden, wenn IP-Planung passt, und immer Rückwege/Failover testen.

Best Practices: OSPF und EIGRP sauber verbinden

• So wenig Redistribution wie nötig: Wenn möglich, einseitig redistributen oder mit Default/Summaries arbeiten.
• Nur ein definierter Border: Wenige Redistributoren reduzieren Komplexität.
• Seed-Metriken dokumentieren: Werte konsistent und nachvollziehbar halten.
• Tagging bei bidirektional: Rückkopplungen verhindern, Richtung kontrollieren.
• Strikte Filter: Prefix-Lists/Route-Maps „allow only what you need“.
• E1 statt E2 bei mehreren Borders: OSPF-Pfadwahl wird realistischer, wenn Nähe zählt.
• Summarization planen: Aggregierbarer IP-Plan ist der größte Stabilitätshebel.
• Tests im Fehlerfall: Link down, Border down, asymmetrische Pfade, Recovery prüfen.

Für allgemeine Sicherheits- und Betriebshygiene, insbesondere für „Least Privilege“-Denken bei Routing-Policies, ist der Anchor-Text CIS Controls eine sinnvolle Ergänzung.

Praxis-Checkliste: Vor dem Go-Live

• Werden nur die gewünschten Präfixe redistributet (Inbound/Outbound Filter geprüft)?
• Ist Tagging aktiv und verhindert es Rückkopplung (Testroute beobachten)?
• Sind Seed-Metriken gesetzt und konsistent (OSPF extern, EIGRP extern)?
• Ist die Pfadwahl nachvollziehbar (AD/Metrik, E1/E2, Successor/FS)?
• Wurde Failover getestet (Link-Ausfall, Border-Ausfall, Wiederkehr)?
• Sind Änderungen dokumentiert (Prefix-Listen, Route-Maps, Tags, Metriken)?

Konfiguration speichern und Betrieb absichern

Nach erfolgreicher Verifikation sollten Sie die Konfiguration speichern, damit die Redistribution nach einem Neustart erhalten bleibt:

copy running-config startup-config

Wenn Sie Cisco-spezifische Kommandovarianten, Besonderheiten einzelner Plattformen oder weiterführende Policy-Optionen nachschlagen möchten, sind Cisco OSPF Support und Cisco EIGRP Support gute Ausgangspunkte, um Syntax und Best Practices plattformspezifisch abzugleichen.

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.