OSPF NSSA/Stub korrekt einsetzen: Design-Entscheidungen mit Praxisbeispielen

Stub- und NSSA-Areas sind OSPF-Designwerkzeuge, um Flooding zu reduzieren, die LSDB klein zu halten und Routing im Access vorhersehbar zu machen. Richtig eingesetzt verhindern sie, dass externe LSAs (Typ 5) überall „durchsickern“, und sie ermöglichen ein klares Default-Route-Verhalten für Branches. Falsch eingesetzt erzeugen sie dagegen Blackholes, unerwartete Pfade oder Routing-Loops – meist durch fehlende Abstimmung zwischen ABR und Area-Routern. Dieses Tutorial zeigt, wann Stub vs. NSSA die bessere Wahl ist und wie du beides sauber konfigurierst.

Stub vs. NSSA: Die Entscheidung in einem Satz

Stub ist ideal, wenn eine Area keine externen Routen kennen muss und mit einer Default Route auskommt. NSSA ist ideal, wenn die Area selbst externe Routen ins OSPF einspeisen muss (z. B. lokales Internet, statische Netze) – aber trotzdem keine externen LSAs von außen „reinfluten“ sollen.

• Stub: keine Type-5 LSAs in der Area, Default Route vom ABR
• NSSA: erlaubt Type-7 LSAs aus der Area, ABR kann Type-7 → Type-5 übersetzen
• Merke: NSSA ist „Stub mit kontrollierter External-Injection“

Merker

$\text{Stub} \to \text{Default statt Externals}, \text{NSSA} \to \text{Externals nur von innen}$

Welche LSAs verschwinden wo? (Praxisrelevante LSA-Sicht)

Du musst nicht alle LSA-Typen auswendig können, aber die Wirkung ist entscheidend: Stub/NSSA reduzieren vor allem externe LSAs. Dadurch sinkt LSDB-Größe und CPU-Last bei Änderungen.

• Stub: blockt externe Type-5 LSAs in der Area
• NSSA: blockt Type-5 LSAs in der Area, nutzt Type-7 für lokale Externals
• ABR: kann NSSA Type-7 in Backbone als Type-5 bekannt machen

Design-Entscheidungen: Wann Stub richtig ist

Stub ist das klassische Branch-Pattern: In der Filiale brauchst du meist keine vollständige Routing-Information, sondern nur eine Default Route Richtung Hub/Core. Das reduziert Komplexität und verhindert Route-Leaks.

• Branch/Access ohne lokale Externals
• Viele kleine Sites: LSDB klein halten, Konvergenz stabil
• Klare Exit-Policy: alles Richtung Hub

Pitfall bei Stub

Wenn in der Area ein zweiter Exit existiert (z. B. lokales Internet), kann Stub ohne saubere Policy zu unerwartetem Routing führen. Dann ist NSSA oder ein anderes Design oft besser.

Design-Entscheidungen: Wann NSSA richtig ist

NSSA nutzt du, wenn ein Router in der Area externe Routen in OSPF einspeisen muss, du aber trotzdem keine externen LSAs von außen in diese Area fluten willst. Typisch: Branch mit lokalem Internet, lokaler DMZ oder statischen Netzen, die im Core sichtbar sein sollen.

• Branch mit lokalem Internet/Breakout (kontrolliert)
• Area mit lokaler Redistribution (static/connected) notwendig
• Externals sollen im Backbone sichtbar sein, aber nicht in die Area zurückfluten

Praxisbeispiel 1: Branch als Stub Area (einfach und robust)

Topologie: Core/Hub in Area 0, Branch in Area 10. Der ABR am Hub ist die Grenze zwischen Area 0 und Area 10. Branch-Router nutzen Default Richtung Hub.

ABR (Hub) – Area 10 als Stub

router ospf 10
 router-id 10.0.0.1
 network 10.0.0.0 0.0.0.255 area 0
 network 10.10.0.0 0.0.255.255 area 10
 area 10 stub

Branch-Router – Area 10 als Stub

router ospf 10
 router-id 10.10.0.1
 network 10.10.0.0 0.0.255.255 area 10
 area 10 stub

Verifikation: Externals fehlen, Default ist da

show ip ospf database external
show ip route ospf
show ip route | include 0.0.0.0

Praxisbeispiel 2: Branch als NSSA mit lokaler Redistribution

Topologie: Branch hat lokale statische Netze (z. B. DMZ 172.16.10.0/24), die im Core sichtbar sein sollen. Gleichzeitig soll die Branch-Area keine externen Routen von außen bekommen.

ABR (Hub) – Area 10 als NSSA

router ospf 10
 router-id 10.0.0.1
 network 10.0.0.0 0.0.0.255 area 0
 network 10.10.0.0 0.0.255.255 area 10
 area 10 nssa

Branch-Router – NSSA + Redistribution (kontrolliert)

ip prefix-list PL_REDIST_DMZ permit 172.16.10.0/24
route-map RM_REDIST_DMZ permit 10

match ip address prefix-list PL_REDIST_DMZ

set tag 110
router ospf 10

router-id 10.10.0.1

network 10.10.0.0 0.0.255.255 area 10

area 10 nssa

redistribute static subnets route-map RM_REDIST_DMZ

Verifikation: Type-7 in der Area, Type-5 im Backbone

show ip ospf database nssa-external
show ip ospf database external
show ip route ospf | include 172.16.10.0

Default Route in Stub/NSSA: bewusst steuern

In Stub-Areas ist die Default Route vom ABR Standardverhalten. In NSSA ist es sinnvoll, die Default Route bewusst zu steuern – insbesondere wenn es mehrere Exits (Hub und lokal) gibt. Sonst bekommst du schwer erklärbare Exit-Pfade.

NSSA Default Route vom ABR (wenn gewünscht)

router ospf 10
 area 10 nssa default-information-originate

Pitfall: Default + lokales Internet ohne Policy

Wenn der Branch sowohl eine Default vom Hub als auch ein lokales Internet hat, musst du klar definieren, welcher Traffic wohin geht (PBR/Policy/BGP) – sonst entstehen Asymmetrie und Security-Probleme.

Leakage kontrollieren: Damit Externals nicht „durchsickern“

Die häufigste Fehlerquelle ist ungefilterte Redistribution. NSSA macht es leicht, Externals einzuspeisen – aber ohne Filter flutest du das Backbone mit unnötigen Routen. Deshalb: immer Prefix-Lists/Route-Maps, Tagging und klare Ownership.

• Whitelist-Prefix-Lists statt „redistribute static all“
• Tags setzen, um Loops/Feedback zu vermeiden
• Summarization nutzen, wenn viele lokale Netze existieren

Summarization für NSSA Externals (ASBR-seitig, wenn passend)

router ospf 10
 summary-address 172.16.0.0 255.255.0.0

Typische Fehler (Pitfalls) und schnelle Checks

Stub/NSSA-Probleme zeigen sich oft als Neighbor-Down oder fehlende Routen. Die Ursachen sind meist Konsistenzfehler: Area-Typ stimmt nicht auf allen Routern, Auth/MTU-Mismatch oder falsche ABR-Rolle.

• Area-Typ mismatch (Stub vs. NSSA) → Neighborship kommt nicht hoch
• Keine Default Route in Stub/NSSA → Branch verliert Exit
• Redistribution ohne Filter → External-Flood ins Backbone
• Summaries falsch gewählt → Blackholes bei Teil-Ausfällen

Checks

show ip ospf neighbor
show ip ospf interface
show ip ospf database summary
show ip ospf database external
show ip ospf database nssa-external
show ip route ospf

Best Practices: Wiederholbares Branch-Pattern

In Enterprise-Umgebungen gewinnt, wer Stub/NSSA als Standard-Pattern definiert und konsequent ausrollt: gleiche Area-IDs, klare ABR-Rollen, kontrollierte Default-Strategie und strikte Redistribution-Regeln.

• Branches ohne Externals: Stub + Default Richtung Hub
• Branches mit lokalen Externals: NSSA + Whitelist-Redistribution
• Default Route bewusst (NSSA default-information-originate nur wenn nötig)
• Summarization nach IP-Plan, nicht „nach Bauchgefühl“

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.