OSPF-Design für Multi-Branch: Area-Planung, Summarization und Stabilität

OSPF ist im Enterprise ein typisches IGP für interne Netze und eignet sich besonders für Multi-Branch-Umgebungen, wenn Sie dynamische Konvergenz, klare Struktur (Areas) und kontrollierbare Routingtabellen benötigen. Der Schlüssel zum Erfolg liegt nicht im „OSPF einschalten“, sondern in sauberer Area-Planung, konsequenter Summarization und Stabilitätsregeln (passive-interface, kontrollierte Nachbarschaften, geringe LSA-Last). Ohne diese Governance entstehen Flapping, große LSDBs und schwer wartbare Standortnetze. Dieser Leitfaden beschreibt ein praxistaugliches OSPF-Design für viele Branches inklusive CLI-Beispielen und Verifikationschecks.

Designziele: Was OSPF im Multi-Branch leisten soll

Definieren Sie zuerst, was OSPF liefern muss: schnelle Konvergenz, geringe Komplexität im Branch, kleine Routingtabellen und einfache Abnahme. OSPF ist ein Werkzeug für Standardisierung.

• Konvergenz: Pfadwechsel in definierter Zeit (Sekunden bis wenige Dutzend Sekunden)
• Skalierung: viele Standorte ohne LSA-Flut und riesige LSDB
• Standardisierung: Branch-Template, minimale Standortvarianz
• Operability: klare Verifikation, Nachbar- und LSA-Transparenz

Topologie-Standard: Hub-and-Spoke mit Backbone in Area 0

Für Multi-Branch ist Hub-and-Spoke der Standard: zentrale Hubs im HQ/Datacenter bilden Area 0 (Backbone). Branches hängen in eigenen Areas oder in regionalen Aggregations-Areas, abhängig von Größe und Governance.

• Area 0: HQ/Core/Hub-Router, Backbone für OSPF
• Branches: Stub oder NSSA (reduziert LSAs, vereinfacht Default)
• Regional Hubs: optional als Aggregationspunkt bei großer geographischer Verteilung

Area-Planung: Stub vs. NSSA vs. Normal Area

Die Area-Wahl entscheidet über LSA-Volumen und Komplexität. In Branches ist „weniger LSAs“ oft besser, weil es Konvergenz und Betrieb vereinfacht. NSSA ist sinnvoll, wenn Branches externe Routen injecten müssen.

• Stub Area: keine externen LSAs, Default wird geliefert (typischer Branch-Standard)
• NSSA: erlaubt externe Routen im Branch (z. B. lokale Internet-Edge), kontrollierbar
• Normal Area: mehr Flexibilität, aber mehr LSAs und mehr Betriebskomplexität

Area-ID-Strategie: Berechenbarkeit für Multi-Site

Nutzen Sie eine systematische Area-ID-Strategie. Das erleichtert Betrieb und Automatisierung. Häufig ist eine direkte Abbildung von SiteID oder Region sinnvoll.

• Option A: Area-ID = SiteID (z. B. Site 012 → Area 12)
• Option B: Area-ID = Region (z. B. Region Nord → Area 100)
• Regel: Area 0 bleibt exklusiv Backbone, Branches nie in Area 0

IP-Plan als Basis für Summarization: Standortblöcke erzwingen

Summarization funktioniert nur, wenn Ihre IPs sauber geplant sind. Der Standard ist ein Standortblock pro Branch (z. B. /22), aus dem Rollen-VLANs abgeleitet werden. So kann der Hub ein einzelnes Summary pro Standort advertisen.

• Standortblock pro Branch: 10.<SITEID>.0.0/22 (Beispiel)
• Rollen-VLANs: 10.<SITEID>.10.0/24, 10.<SITEID>.20.0/24, usw.
• Summaries: pro Branch ein Präfix statt vieler /24s

Subnetting-Orientierung: /22 Standortblock

$2^{10}=1024$

Summarization-Design: Wo und wie Sie zusammenfassen

Im Multi-Branch-Design ist das Hub der typische Summarization-Punkt. Summaries reduzieren Routingtabellen, LSA-Last und die Wahrscheinlichkeit von Flapping-Auswirkungen über viele Standorte.

• Summarization am ABR (Hub): pro Branch ein Standortblock
• Summarization an Area-Grenzen: reduziert LSDB und SPF-Aufwand
• Regel: keine Summaries ohne IP-Plan-Disziplin (Overlaps vermeiden)

Stabilität 1: passive-interface als Pflichtstandard

Die häufigste Ursache für instabile OSPF-Netze sind unbeabsichtigte Nachbarschaften. Setzen Sie passive-interface default und erlauben Sie OSPF nur auf exakt definierten Links.

OSPF-Baseline (Branch/HQ Muster)

router ospf 10
 router-id 10.255.<SITEID>.1
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface GigabitEthernet0/0

Verifikation Nachbarschaften

show ip ospf neighbor
show ip ospf interface brief

Stabilität 2: Nachbarschaften auf stabilen Interfaces (Tunnel/Point-to-Point)

In Branch-Designs laufen OSPF-Adjacencies häufig über Tunnel (z. B. IPsec VTI/DMVPN) oder über dedizierte P2P-Links. Das ist stabiler als „irgendwo im LAN“ zu peeren.

• Bevorzugt: OSPF über Tunnel/Transit-Links
• Vermeiden: OSPF auf Client-VLANs oder großen Broadcast-Domänen
• Dokumentieren: welche Interfaces dürfen Neighbor werden

Stabilität 3: Default-Strategie für Branches (klar und konsistent)

Branches brauchen in der Regel nur einen Default Richtung HQ/Hub. Das reduziert Routingkomplexität und verhindert, dass Branches unnötige Core-Routen halten müssen.

• Hub liefert Default in Stub/NSSA (Designentscheidung)
• Branches announcen Standortsummary Richtung Hub
• Keine „halbglobalen“ Routen in Branches ohne Notwendigkeit

OSPF-Template: Minimaler Branch-Konfigurationsblock (konzeptionell)

Dieser Block zeigt die Struktur. In der Praxis werden Interface-Namen, Area-ID und Network-Statements standardisiert und über Variablen parametrisiert.

router ospf 10
 router-id 10.255.<SITEID>.1
 passive-interface default
 no passive-interface Tunnel0
 network 10.<SITEID>.0.0 0.0.3.255 area <AREAID>

Design-Risiken: LSA-Flut, LSDB-Größe und SPF-Last

In großen OSPF-Domänen sind LSAs und SPF-Berechnungen der Skalierungsfaktor. Summarization und Area-Design sind daher keine „nice-to-have“, sondern zentrale Stabilitätsmechanismen.

• Zu viele /32-/24 Routen ohne Summaries → LSDB wächst
• Flapping Links → LSA-Updates → SPF-Stürme
• Unkontrollierte Neighbor → unnötige LSAs und Instabilität

Operability: Monitoring, Logs und Standard-Runbooks für OSPF

Ein OSPF-Netz ist nur dann enterprise-tauglich, wenn Neighbor-Events und Routingänderungen sichtbar sind. Definieren Sie Alarmkatalog und Runbooks als Teil des Designs.

• Monitoring: Neighbor up/down, Route-Count, CPU-Spikes bei SPF
• Logs: OSPF Events zentral (Syslog), Zeit korrekt (NTP)
• KPIs: Neighbor-Flap-Rate, Convergence-Zeit, MTTR

CLI: OSPF-Operability-Snapshot

show ip ospf neighbor
show ip ospf database | include LSA
show ip route ospf
show ip route summary
show logging | include OSPF
show processes cpu sorted

Abnahme (UAT): Was vor Implementierung „grün“ sein muss

OSPF gilt erst als abgenommen, wenn Nachbarschaften stabil sind, Summaries korrekt wirken und Failover-Szenarien getestet wurden. Dokumentieren Sie Evidence pro Standort/Welle.

• Nachbarschaften: erwartete Neighbor-Liste, keine zusätzlichen Adjacencies
• Summarization: Standortblock als Summary sichtbar, keine Overlaps
• Default: Branch hat genau den erwarteten Default-Pfad
• Failover: Tunnel/Link-Down, Konvergenzzeit gemessen

Evidence-Set (Copy/Paste)

show ip ospf neighbor
show ip ospf interface brief
show ip route 0.0.0.0
show ip route ospf
show ip route summary
show logging | last 100
show processes cpu sorted

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.