Metric Translation bei Redistribution: Path Selection konsistent halten

Die konsistente Pfadauswahl bei der Route Redistribution zwischen unterschiedlichen Routing-Protokollen ist ein entscheidender Faktor für stabile und vorhersehbare Netzwerke. Besonders beim Übersetzen von Metriken (Metric Translation) zwischen OSPF, EIGRP und BGP entstehen häufig inkonsistente Pfade, die zu Suboptimal Routing oder sogar Routing-Loops führen können. In diesem Artikel werden praxisnahe Design-Muster, technische Hintergründe und konkrete Implementierungsbeispiele vorgestellt, um Path Selection konsistent zu halten.

Grundlagen der Metric Translation

Warum Metrikübersetzung notwendig ist

Verschiedene Routing-Protokolle verwenden unterschiedliche Metriken:

• OSPF: Kosten basierend auf Bandbreite
• EIGRP: Composite Metric aus Bandbreite, Verzögerung, Last und Zuverlässigkeit
• BGP: Nur AS-Path, Local Preference und Multi-Exit-Discriminator (MED)

Beim Redistribuieren von Routen muss eine Metrik in eine andere übersetzt werden, um konsistente Entscheidungen über den besten Pfad zu ermöglichen.

Risiken bei falscher Metric Translation

• Suboptimale Pfade im internen oder externen Routing
• Routing-Loops, wenn Metriken inkompatibel übersetzt werden
• Instabilität bei Failover-Szenarien

Design Patterns für konsistente Pfadauswahl

One-Way Translation vs. Two-Way Translation

Bei der Redistribution gibt es zwei Ansätze:

• One-Way Translation: Metriken werden nur beim Export in das andere Protokoll gesetzt. Rückimporte müssen durch Tagging oder Filter verhindert werden.
• Two-Way Translation: Metriken werden bei beiden Richtungen übersetzt, um konsistente Pfade in beiden Domains zu erhalten. Dies erfordert sorgfältige Koordination von Tags und Route-Maps.

Standardisierung der Metrikwerte

Einheitliche Metrikübersetzungen verhindern, dass dieselbe Route unterschiedliche Präferenzen in verschiedenen Routing-Protokollen erhält:

• OSPF-Kosten auf EIGRP-Metrik konvertieren (z. B. bandwidth-to-delay Formeln)
• BGP-MED auf OSPF-Kosten abbilden, wenn mehrere egress-Pfade existieren
• Definierte Standardwerte für unklassifizierte Routen setzen

Praktische Implementierung auf Cisco-Routern

OSPF → BGP

Beim Export von OSPF in BGP wird die OSPF-Kosten-Metrik häufig auf den BGP-MED-Wert abgebildet:

router bgp 65001
  redistribute ospf 1 metric 50 route-map OSPF_TO_BGP
route-map OSPF_TO_BGP permit 10

match tag 100

set metric 50

BGP → OSPF

Beim Import von BGP-Routen in OSPF kann die MED oder Local Preference als Kosten genutzt werden:

router ospf 1
  redistribute bgp 65001 subnets route-map BGP_TO_OSPF
route-map BGP_TO_OSPF permit 10

set metric 100

EIGRP → OSPF

EIGRP-Metriken bestehen aus Bandbreite und Verzögerung. Beim Übersetzen in OSPF-Kosten empfiehlt sich eine Formel wie:

ospf-cost = (10000 / minimum-bandwidth) + (delay / 10)

Dies sorgt für konsistente Präferenzen innerhalb der OSPF-Domäne.

Loop-Prevention mit Tags und Route-Maps

Um unerwünschte Rückimporte zu verhindern, ist Tagging essenziell:

• Jede redistribuierte Route erhält einen eindeutigen Tag
• Route-Maps prüfen beim Import die Tags und verhindern Rückflüsse
• Kombination aus Tag + Filterliste erhöht die Sicherheit

Beispiel CLI

route-map BLOCK_RETURN deny 10
  match tag 100
route-map BLOCK_RETURN permit 20
router ospf 1

redistribute bgp 65001 subnets route-map BLOCK_RETURN

Operationalisierung und Monitoring

Konsistenz prüfen

• Vergleich von Routing-Tabellen nach Redistribution
• Überwachung der Pfadauswahl über Traceroute und NetFlow
• Monitoring von Metrikänderungen und Flapping-Routen

Lab-Tests vor Produktion

Die Übersetzung von Metriken sollte stets in einer kontrollierten Umgebung validiert werden:

• Simulieren von Failover und Pfadwechseln
• Überprüfung von Pfadpräferenzen nach jeder Änderung
• Rollback-Mechanismen für fehlerhafte Metric-Mappings

Best Practices

• Definierte Standardwerte für alle Metric Translation-Pfade
• Tagging und Filterung strikt implementieren
• Regelmäßiges Monitoring von Pfadauswahl und Routing-Stabilität
• Lab-Test vor produktiven Änderungen
• Dokumentation der Metrik-Formeln und Übersetzungsregeln

Die konsistente Pfadauswahl durch korrekte Metric Translation ist essenziell, um Routing-Loops zu vermeiden und Suboptimal Paths zu verhindern. Mit standardisierten Übersetzungen, Tags, Route-Maps und kontinuierlichem Monitoring lässt sich eine stabile Routing-Domäne über mehrere Protokolle hinweg sicherstellen.

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.