OSPF skaliert sehr gut, solange du zwei Dinge im Griff hast: LSA-Volumen (wie viele Updates werden geflutet) und Rechenlast (wie oft wird SPF neu berechnet). In wachsenden Enterprise-Netzen entstehen Performance-Probleme typischerweise nicht durch „zu viele Routen“, sondern durch Instabilität: Interface-Flaps, viele Topologieänderungen, falsche Area-Designs oder ungefilterte Redistribution. OSPF Scalability Tuning bedeutet deshalb: Flooding reduzieren, Berechnungen dämpfen (throttling) und Timer so setzen, dass Konvergenz schnell bleibt, aber Flaps nicht die CPU zerstören.
Erst Diagnose, dann Tuning: Wann du überhaupt drehen solltest
Timer-Tuning ist kein Ersatz für gutes Design. Wenn du Symptome wie hohe CPU, viele LSAs oder häufige SPF-Runs siehst, musst du zuerst herausfinden, was die Änderungen triggert. Häufig ist die Ursache ein einzelner flappender Link oder eine „laute“ Redistribution.
- Symptom: hohe CPU auf Routing-Prozess, sporadische Latenzspikes
- Symptom: häufige Neighbor Resets, LSDB wächst schnell
- Symptom: viele SPF/LSA-Events in kurzer Zeit
Basis-Checks
show ip ospf neighbor
show ip ospf interface brief
show ip ospf database summary
show ip ospf statistics
show processes cpu sortedLSA Flooding verstehen: Warum „zu viele Änderungen“ gefährlich sind
OSPF flutet LSAs, sobald sich Topologie oder Prefix-Informationen ändern. Jede Änderung erzeugt Flooding im Area-Kontext und kann SPF-Events auslösen. In großen Netzen ist das Hauptziel: Änderungen lokal halten (Area-Design) und die Anzahl relevanter LSAs reduzieren.
- Flooding ist normal, aber häufiges Flooding ist ein Stabilitätsproblem
- Viele Access-Links flappen → viele Router-LSAs/Network-LSAs
- Redistribution ohne Filter → viele External-LSAs (Typ 5/7)
Design-Hebel 1: Area-Design sauber machen (Area 0, Stub/NSSA)
Das stärkste Scalability-Tuning ist Design: Areas begrenzen Flooding-Domänen. Stub-/NSSA-Areas reduzieren externe LSAs und halten die LSDB schlanker. Das ist meist wirksamer als jede Timer-Optimierung.
- Area 0 stabil und redundant (Backbone ist „Herz“)
- Access/Branches als Stub oder NSSA, wenn externes Routing dort nicht nötig ist
- ABRs nutzen Summarization, um Routen zu aggregieren
Stub Area (Beispiel auf ABR und Area-Routern)
router ospf 10
area 10 stubNSSA (Beispiel)
router ospf 10
area 10 nssaDesign-Hebel 2: Summarization am ABR (LSA-Anzahl reduzieren)
Summarization reduziert die Anzahl der internen Prefix-LSAs, die zwischen Areas ausgetauscht werden. Das wirkt direkt gegen LSDB-Wachstum und SPF-Last in entfernten Teilen des Netzes.
ABR Summary (Beispiel)
router ospf 10
area 10 range 10.10.0.0 255.255.240.0Redistribution: Hauptquelle für „LSA-Lärm“
Ungefilterte Redistribution ist eine der häufigsten Ursachen für LSA Flooding und Instabilität. Externe Routen erzeugen Type-5 (oder Type-7 in NSSA) LSAs, die sich großflächig ausbreiten. Daher gilt: nur benötigte Prefixes, immer mit Prefix-Lists/Route-Maps, und stabile Tags/Policies.
- Nur definierte Prefixes redistributen (Whitelist)
- Route-Maps für Filtering und Tagging
- Externe LSAs in Stub/NSSA begrenzen
Beispiel: Redistribution mit Route-Map (Prinzip)
ip prefix-list PL_REDIST permit 192.168.0.0/16 le 24
route-map RM_REDIST permit 10
match ip address prefix-list PL_REDIST
set tag 100
router ospf 10
redistribute static subnets route-map RM_REDIST
LSA Throttling: Flooding dämpfen, ohne Konvergenz zu zerstören
Throttling bedeutet: OSPF fasst schnell aufeinanderfolgende Änderungen zusammen, statt bei jedem Flap sofort neue LSAs zu fluten. Das reduziert „Flood-Stürme“ in instabilen Netzen. Wichtig ist ein vernünftiger Kompromiss: zu aggressiv = langsame Konvergenz, zu locker = CPU-Fights.
LSA Generation/Arrival Throttling (Konzept)
IOS XE unterstützt je nach Plattform/Release Mechanismen zur Dämpfung. In der Praxis arbeitest du mit „Start/Min/Max“-Werten: schnell starten, dann exponentiell backoffen, wenn Events weiterkommen.
Verifikation: Ob LSA/Spf-Stürme auftreten
show ip ospf statistics
show ip ospf database | count
show logging | include OSPF|SPFSPF Timers: Der zentrale Hebel gegen CPU-Spikes
SPF wird bei Topologieänderungen neu berechnet. Wenn ein Link flapt, kann SPF in kurzen Abständen laufen und CPU binden. SPF-Throttling setzt daher eine Startverzögerung und einen Backoff, um Flap-Stürme abzufangen.
SPF Throttling (Beispielwerte als Startpunkt)
router ospf 10
timers throttle spf 50 200 5000Interpretation der drei Werte
- Start: erste SPF-Delay in ms (schnell reagieren)
- Hold: Mindestabstand bei weiteren Events
- Max: Obergrenze des Backoff bei anhaltenden Änderungen
LSA Throttle vs. SPF Throttle: Wer macht was?
LSA-Throttling beeinflusst, wie schnell LSAs erzeugt/akzeptiert werden. SPF-Throttling beeinflusst, wie schnell die Route-Berechnung nach Änderungen läuft. In großen Netzen brauchst du meist beides: weniger Flooding und weniger Rechenstürme.
- LSA Throttle: reduziert Update-Lärm
- SPF Throttle: reduziert CPU-Last durch häufige Berechnungen
- Ziel: Konvergenz bleibt schnell bei echten Ausfällen, stabil bei Flaps
LSDB-Größe im Griff: Was du regelmäßig prüfst
Skalierung ist messbar. Du brauchst Monitoring auf LSDB-Größe, Neighbor-Stabilität und OSPF-Events. Wenn LSDB wächst oder SPF-Häufigkeit steigt, ist das ein Frühwarnsignal.
- LSA-Anzahl pro Area (Trend, nicht nur Moment)
- Neighbor Flaps (pro Interface/Segment)
- SPF Runs pro Zeitraum
- CPU-Last des Routing-Prozesses
Messkommandos
show ip ospf database | count
show ip ospf neighbor
show ip ospf interface
show ip ospf statistics
show processes cpu sortedTypische Pitfalls beim OSPF Tuning
Falsches Tuning macht das Netz nicht stabiler, sondern nur langsamer. Besonders gefährlich ist „Timer drehen“, ohne die eigentliche Instabilitätsquelle (Flaps, Redistribution, L2-Probleme) zu beheben.
- SPF-Delays zu hoch: echte Ausfälle konvergieren langsam
- Keine Summarization: LSDB wächst unnötig, Flooding bleibt groß
- Redistribution ohne Filter: External-LSA-Sturm
- Area 0 instabil: Backbone-Probleme wirken überall
Praxis-Runbook: OSPF Scalability Tuning Schritt für Schritt
Dieses Runbook ist für den Betrieb gedacht: erst Ursachen finden, dann gezielt dämpfen und danach verifizieren.
! 1) Baseline
show ip ospf neighbor
show ip ospf database | count
show ip ospf statistics
show processes cpu sorted
show logging | include OSPF|SPF
! 2) Design checks
show running-config | section router ospf
show running-config | include redistribute|area|range
! 3) Tuning (Beispiel)
configure terminal
router ospf 10
timers throttle spf 50 200 5000
end
! 4) Post-Checks
show ip ospf neighbor
show ip ospf statistics
show processes cpu sorted
Konfiguration speichern
Router# copy running-config startup-configKonfiguriere 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.
