OSPF Metric Strategy: Konsistente Path Selection sicherstellen

Die OSPF-Metrik (Cost) ist der zentrale Faktor für die Pfadauswahl innerhalb eines OSPF-Netzwerks. Eine konsistente und gut durchdachte Metric-Strategie verhindert Routing-Flaps, asymmetrische Pfade und unerwartete Traffic-Patterns. Besonders in komplexen Enterprise- oder Multi-Area-Topologien ist es entscheidend, Metriken planvoll zu vergeben, um Stabilität und Vorhersagbarkeit der Path Selection zu gewährleisten.

Grundlagen der OSPF-Metrik

OSPF verwendet eine Kostenmetrik, die standardmäßig auf der Bandbreite des Links basiert:

• Cost = 100 Mbit / Interface-Bandbreite (in Mbit/s)
• Niedrigere Kosten bevorzugen einen Pfad gegenüber höheren Kosten.
• OSPF summiert die Kosten aller Hops zu einem Ziel, um den besten Pfad zu bestimmen.

Die Berechnung erfolgt für intra-area, inter-area und externe Routen, wobei bei externen Routen zwischen E1 und E2 unterschieden wird.

Metric Strategy für konsistente Path Selection

Eine klare Metric-Strategie verhindert, dass Traffic unvorhersehbar auf mehrere Pfade verteilt wird:

1. Standardisierung von Link-Costs

• Setze Bandbreiten-basierte Kosten für alle Links in einer Area ein, um konsistente Entscheidungen zu garantieren.
• Vermeide manuelles Übersteuern von Cost-Werten, außer bei gezieltem Traffic Engineering.
• CLI-Beispiel:

interface GigabitEthernet0/1
 ip ospf cost 10

2. Inter-Area Pfade optimieren

• Für Pfade über ABRs (Area Border Routers) sollten Kosten so gewählt werden, dass der bevorzugte Pfad immer eindeutig ist.
• Symmetrische Cost-Zuweisung für parallele Pfade minimiert asymmetrische Routing-Probleme.
• Beispiel: Zwei Pfade mit cost 20 und cost 30 – der Pfad mit 20 wird bevorzugt.

3. External Routes (E1/E2) berücksichtigen

• E1-Routen: Gesamtkosten = interne OSPF-Kosten + externe Metrik → geeignet für Multi-ASBR-Setups.
• E2-Routen: externe Metrik dominiert → einfach, stabil, aber interne Pfade werden nicht bewertet.
• Wichtig: Consistency zwischen Area- und ASBR-Metrik vermeidet unerwartete Pfadänderungen.

4. Path Preference vs. Redundanz

• Bei mehreren Links mit gleicher Cost kann OSPF ECMP nutzen.
• Für deterministische Failover-Szenarien sollten Kosten bewusst leicht unterschiedlich gesetzt werden.
• Beispiel: Primärer Pfad cost 10, sekundärer Pfad cost 12.

Best Practices für Enterprise

• Dokumentiere alle Cost-Werte in der Topologie-Übersicht.
• Vermeide willkürliche Änderungen einzelner Link-Costs ohne Impact-Analyse.
• Setze standardisierte Cost-Formeln für neue Links ein (z. B. $Cost\; =\; 100 Mbit\; /\; Bandwidth(Mbit/s)$).
• Bei Multi-Area-Designs konsistente Cost-Zuweisung zwischen Areas sicherstellen, um Path Flaps zu verhindern.
• Regelmäßiges Monitoring von OSPF-Routing-Tabellen, LSDB und Convergence-Zeiten zur Validierung der Metric-Strategie.

Verifikation der Metric-Strategie

Nach Implementierung sollten die Pfade überprüft werden:

1. Routing-Tabelle prüfen

show ip route ospf

• Überprüft, dass der erwartete Pfad mit der niedrigsten Cost gewählt wird.

2. LSDB Analyse

show ip ospf database

• Verifiziert, dass LSA-Kosten konsistent propagiert werden.

3. Traceroute / Traffic-Tests

traceroute 10.0.0.1

• Stellt sicher, dass der Datenpfad den erwarteten Hop-Pfad nutzt.

Typische Pitfalls

• Manuelle Cost-Anpassungen ohne Dokumentation → unerwartete Path Selection.
• Asymmetrische ECMP-Pfade ohne definierte Präferenz → ungleichmäßige Lastverteilung.
• Unterschiedliche Cost-Formeln in Multi-Area-Designs → Routing-Flaps und Convergence-Probleme.
• Fehlerhafte Cost bei externen Routen (E1/E2) → inkonsistente Traffic-Steuerung.

CLI-Beispiele für konsistente Cost-Strategie

! Interface Costs
interface Gi0/1
 ip ospf cost 10
interface Gi0/2
 ip ospf cost 20
! Redistribution mit Metric Type

router ospf 1

redistribute bgp 65001 metric-type 1 subnets

redistribute static metric-type 2 subnets

Fazit zur Praxis

Eine konsistente OSPF Metric-Strategie ist entscheidend für stabile Pfadauswahl, deterministisches Routing und planbare Convergence. Standardisierte Cost-Zuweisungen, dokumentierte ECMP-Pfade und überprüfte External Route-Typen verhindern unvorhersehbare Traffic-Pfade und reduzieren Troubleshooting-Aufwand. In Multi-Area- und Enterprise-Topologien minimiert dies das Risiko von Routing-Flaps und inkonsistentem Traffic-Engineering.

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.