OSPF in Multi-Area Netzen: ABR-Design, Summarization & Leakage kontrollieren

Multi-Area OSPF ist ein Skalierungswerkzeug: Flooding-Domänen werden kleiner, die LSDB bleibt beherrschbar und Änderungen im Access schlagen nicht mehr im gesamten Netz durch. Der kritische Baustein ist das ABR-Design (Area Border Router): ABRs entscheiden, welche Informationen zwischen Areas weitergegeben werden, wie summarisiert wird und ob „Leakage“ (unerwünschte Routen/LSAs) entsteht. Dieses Tutorial zeigt praxistaugliche ABR-Patterns, Summarization-Strategien und Kontrollmechanismen, damit Multi-Area OSPF stabil und vorhersehbar bleibt.

Multi-Area Grundlagen: Was ABRs wirklich tun

Ein ABR verbindet mindestens zwei Areas, eine davon ist idealerweise Area 0 (Backbone). ABRs halten separate LSDBs pro Area und erzeugen/übersetzen LSAs zwischen diesen Datenbanken. Das ist der Kern der Skalierung – und die Quelle vieler Designfehler.

  • ABR hält pro Area eine eigene LSDB
  • ABR erzeugt Inter-Area Routes (Type 3 Summary LSAs)
  • ABR kann Summaries bilden und Flooding reduzieren
  • Pitfall: instabile ABRs machen das ganze Area-Design nutzlos

Backbone-Design: Area 0 ist nicht optional

In sauberem OSPF-Design ist Area 0 das Backbone, über das Inter-Area Traffic und Route-Informationen laufen. Wenn Areas „hängen“ oder Area 0 instabil ist, entstehen merkwürdige Routing-Effekte, langsame Konvergenz und schweres Troubleshooting.

  • Alle Nicht-Backbone-Areas sollten direkt oder logisch (virtuell) an Area 0 hängen
  • Area 0 braucht Redundanz (mindestens zwei Pfade/ABRs)
  • Backbone stabil halten: keine „lauten“ Access-Links im Area 0

ABR-Patterns: Hub-and-Spoke, Hierarchie und Redundanz

In der Praxis funktionieren zwei Patterns besonders gut: (1) Hierarchisches Design mit Core/Backbone und klaren ABR-Standorten, (2) Hub-and-Spoke für Branches, bei dem Branch-Areas stub/nssa sind und am Hub summarisiert werden.

  • Campus: Core als Area 0, Distribution als ABR zu Access-Areas
  • WAN/Branches: Hub als ABR, Branch-Area als Stub/NSSA
  • Redundanz: zwei ABRs pro Area (wo Kritikalität es verlangt)

ABR-Check

show ip ospf border-routers
show ip ospf database summary
show ip ospf neighbor

Summarization am ABR: Der wichtigste Skalierungshebel

Summarization reduziert die Anzahl der Inter-Area Prefixes (Type 3 LSAs). Ziel ist: viele kleine Netze im Access werden als ein zusammenhängender Summary-Prefix ins Backbone propagiert. Das reduziert LSDB-Größe und SPF-Last in anderen Areas.

Prinzip: viele /24 als ein /20

16 × /24  →  1 × /20

ABR Summarization (area range)

router ospf 10
 area 10 range 10.10.0.0 255.255.240.0

Wichtige Nebenwirkung

Summaries können „Blackholes“ verursachen, wenn einzelne Subnetze ausfallen, aber der Summary weiter announced wird. In kritischen Designs brauchst du daher saubere Redundanz und eine Topologie, die Summaries korrekt repräsentiert.

Stub und NSSA: Leakage kontrollieren und LSDB schlank halten

Stub-Areas verhindern, dass externe LSAs (Type 5) in die Area gelangen. Stattdessen gibt es eine Default Route vom ABR. NSSA ist Stub-ähnlich, erlaubt aber kontrollierte externe Routen als Type 7 (die am ABR zu Type 5 übersetzt werden können).

  • Stub: keine externen LSAs in der Area, Default Route vom ABR
  • NSSA: externe Routen innerhalb der Area möglich (Type 7)
  • Pattern: Branch-Areas häufig Stub/NSSA

Stub konfigurieren (ABR und Area-Router)

router ospf 10
 area 10 stub

NSSA konfigurieren

router ospf 10
 area 10 nssa

Leakage: Was damit gemeint ist und warum es gefährlich ist

Leakage ist das unbeabsichtigte „Durchsickern“ von Routen/Informationen zwischen Areas oder aus externen Quellen, das du eigentlich begrenzen wolltest. Typische Folgen sind Routing-Tabellenwachstum, unerwartete Pfade und schwer nachvollziehbares Verhalten in Stub/NSSA-Designs.

  • Externals in falscher Area (Redistribution ohne Kontrolle)
  • Zu viele Inter-Area Prefixes (keine Summarization)
  • Default Route in Bereichen, wo sie nicht sein soll
  • Route-Leaks durch falsche ABR-/Area-Definitionen

Leakage kontrollieren: Die drei wirksamsten Mechanismen

In OSPF steuerst du Leakage primär über Area-Typen (Stub/NSSA), Summarization und kontrollierte Redistribution. Diese drei Hebel sollten als Standard in Multi-Area Designs eingeplant werden.

  • Area-Typen: Stub/NSSA begrenzen externe LSAs
  • Summarization: reduziert Inter-Area LSA-Volumen
  • Redistribution: nur whitelisted Prefixes, mit Tags und Route-Maps

Redistribution kontrollieren (Prinzip mit Prefix-List)

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

Default Route bewusst steuern: Wo sie hin gehört (und wo nicht)

In Stub/NSSA-Areas ist eine Default Route üblich. In anderen Areas kann eine Default Route jedoch zu unerwarteten Exit-Pfaden führen, besonders bei mehreren Internet-Edges. Deshalb sollte Default-Injection kontrolliert, dokumentiert und in HA-Szenarien getrackt sein.

Default Route in OSPF injizieren (Edge/ABR, wenn gewollt)

router ospf 10
 default-information originate

Mit Tracking (wenn Default nur bei Internet-Uplink gelten soll)

ip sla 1
 icmp-echo 1.1.1.1 source-interface gigabitEthernet0/1
 frequency 5
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability

ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1

router ospf 10
default-information originate

ABR-Stabilität: Timers und LSA-Volumen im Blick behalten

ABRs sind der „Flaschenhals“ in Multi-Area OSPF: sie halten mehrere LSDBs, generieren Summaries und sind zentral für Flooding-Kontrolle. Wenn ABRs CPU- oder Memory-Probleme haben, wirkt das schnell netzweit.

  • SPF/LSA-Events auf ABRs monitoren
  • Flappende Access-Links nicht im Backbone terminieren
  • Summaries so wählen, dass sie Topologie korrekt repräsentieren

ABR Health Checks

show ip ospf statistics
show ip ospf database | count
show processes cpu sorted

Troubleshooting: Multi-Area Probleme schnell eingrenzen

Wenn Inter-Area Routen fehlen oder Pfade „komisch“ sind, prüfst du zuerst Area-0-Konnektivität, dann ABR-Rollen, dann LSAs (Type 3/5/7). Damit findest du meist schnell den Leak oder das Designproblem.

Checkliste

  • Ist Area 0 erreichbar und stabil?
  • Sehe ich die ABRs als Border Router?
  • Welche Summary-LSAs (Type 3) werden erzeugt?
  • Gibt es externe LSAs (Type 5/7) in Areas, wo sie nicht sein sollen?

Commands

show ip ospf neighbor
show ip ospf border-routers
show ip ospf database summary
show ip ospf database external
show ip ospf database nssa-external
show ip route ospf

Best Practices: Multi-Area OSPF als wiederholbares Pattern

Multi-Area wird dann wartbar, wenn du es standardisierst: gleiches Area-Pattern pro Standort, klare ABR-Rollen, Summaries nach IP-Plan und strikte Redistribution-Regeln.

  • Area 0 stabil, redundant, „leise“
  • Access/Branches als Stub oder NSSA
  • Summarization konsequent nach IP-Plan
  • Redistribution nur am Rand, streng gefiltert und getaggt
  • Default Route kontrolliert und getrackt injizieren

Konfiguration speichern

Router# copy running-config startup-config

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.

Related Articles