OSPF/IS-IS im Core: Welches IGP passt besser für Provider?

OSPF/IS-IS im Core ist eine der klassischen Grundsatzentscheidungen im Provider-Backbone, weil das Interior Gateway Protocol (IGP) die Stabilität, Konvergenz und Skalierbarkeit der gesamten Transportebene beeinflusst. Wer ein Provider-Netz plant, setzt das IGP im Core typischerweise nicht für „Kundenrouten“, sondern für Infrastruktur-Erreichbarkeit ein: Loopbacks, Core-Links, Router-Identitäten und grundlegende Topologieinformationen. Genau deshalb muss das IGP robust, vorhersehbar und betrieblich beherrschbar sein – auch unter Wachstum, Failover-Szenarien und hoher Change-Frequenz. OSPF und IS-IS sind beide Link-State-Protokolle mit ähnlichen Grundprinzipien, unterscheiden sich aber in Details, die in Telco-Umgebungen stark wirken können: Area-/Level-Modelle, Skalierungsverhalten, Adressierungs- und Erweiterungsmechanismen, Multi-Topology-Fähigkeit sowie typische Betriebs- und Toolinggewohnheiten. Dieser Artikel erklärt verständlich, wie OSPF und IS-IS im Core funktionieren, welche Designmuster für Provider üblich sind und wie Sie entscheiden, welches IGP besser zu Ihren Anforderungen, Ihrer Topologie und Ihrer Betriebsreife passt.

Rolle des IGP im Provider-Core: Infrastruktur, nicht Service

Im Telco-Core ist das IGP das „Betriebssystem“ der Transportebene. Es soll eine stabile, schnelle Erreichbarkeit für Infrastrukturadressen liefern, damit darüberliegende Protokolle und Services (typischerweise BGP für Internet, VPNs, EVPN oder Segment Routing) zuverlässig funktionieren. Best Practice ist, das IGP schlank zu halten: wenige Präfixe, klare Metriken, saubere Topologie, und keine kunden- oder servicebezogenen Routen im IGP. Das reduziert die Komplexität und schützt die Control Plane vor unnötigen Updates.

• IGP transportiert: Loopbacks, Core-Links, Router-IDs, ggf. Segment-Routing-Informationen.
• BGP liefert Services: Internet-Routen, VPNv4/VPNv6, EVPN, Policies und Mandantenlogik.
• Ziel: Schnelle Konvergenz bei Ausfällen, stabile Pfade, effiziente ECMP-Nutzung.

Gemeinsamkeiten: Warum beide Protokolle grundsätzlich geeignet sind

OSPF und IS-IS sind Link-State-IGPs. Beide bauen eine Topologie-Datenbank auf, berechnen Pfade mit SPF (Dijkstra) und können ECMP nutzen. Beide unterstützen Hierarchien, um Skalierung zu ermöglichen, und beide sind in großen Netzen produktiv erprobt. In der Praxis ist daher selten die Frage „kann es das?“, sondern „welches passt besser zu unserem Betrieb, unserer Topologie und unseren Skalierungszielen?“

• Link-State-Logik: Topologie verstehen, Pfade berechnen, bei Änderungen rekonvergieren.
• Hierarchien: OSPF Areas und IS-IS Levels, um die Datenbankgröße zu begrenzen.
• ECMP: Lastverteilung über parallele Pfade, wichtig im Provider-Backbone.
• IPv4/IPv6: Beide können Dual-Stack und moderne Erweiterungen abbilden.

OSPF im Core: Area-Modell, Stärken und typische Designmuster

OSPF (häufig OSPFv2 für IPv4 und OSPFv3 für IPv6) ist in vielen Umgebungen verbreitet und gut verstanden. OSPF segmentiert Topologien über Areas, wobei Area 0 als Backbone-Area fungiert und andere Areas über ABRs angebunden werden. In Provider-Cores wird OSPF meist als einfaches, konsistentes Area-Design genutzt – häufig mit wenigen Areas, klarer Zuordnung und konsequenten Metriken.

Typische OSPF-Designmuster für Provider

• Single-Area Core: Einfache Topologie, schnelle Fehlersuche, geeignet für kleinere bis mittlere Cores.
• Backbone + regionale Areas: Regionale Metro-/Access-Aggregation in eigenen Areas, Core in Area 0.
• Stub-/NSSA-Patterns: In Provider-Cores eher selten, eher im Randbereich sinnvoll, um LSA-Flut zu begrenzen.

Stärken von OSPF im Provider-Kontext

• Weit verbreitet: Viele Teams kennen OSPF, Tooling und Know-how sind oft vorhanden.
• Klare Area-Semantik: Areas sind konzeptionell gut erklärbar und sauber dokumentierbar.
• Deterministische Betriebsmodelle: Mit diszipliniertem Area-Design sehr gut beherrschbar.

Typische Herausforderungen von OSPF im großen Core

• Area-Komplexität: Viele Areas und ABRs erhöhen Betriebsaufwand und Risiko bei Migrationen.
• OSPFv2/v3-Dualität: In Dual-Stack-Designs kann es mehr „Parallelwelten“ geben, wenn nicht konsistent geplant.
• LSA-Management: In sehr großen Topologien kann LSA-Flut bei Instabilitäten problematisch werden, wenn Design und Timers nicht sauber abgestimmt sind.

IS-IS im Core: Level-Modell, Stärken und typische Designmuster

IS-IS wird im Provider-Backbone oft als „klassisches Telco-IGP“ betrachtet, weil es historisch stark in großen Netzbetreibern verbreitet ist und sich gut für hierarchische Core-Designs eignet. IS-IS nutzt Levels: Level-1 für intra-area (intra-region) und Level-2 als Backbone. Router können Level-1, Level-2 oder L1/L2 sein. In vielen Provider-Designs wird Level-2 im Core genutzt, während Metro/Regionen als Level-1 angebunden werden.

Typische IS-IS-Designmuster für Provider

• Level-2-only Core: Schlanke Core-Domäne, einfache Skalierung, sehr verbreitet in Backbones.
• Level-1 Regionen + Level-2 Backbone: Regionale Domänen begrenzen Datenbank und Konvergenzlast.
• Route Leaking bewusst: Falls L1/L2-Leaking genutzt wird, muss es strikt standardisiert sein, um unerwartete Pfade zu vermeiden.

Stärken von IS-IS im Provider-Kontext

• Starkes Hierarchiemodell: L1/L2 passt gut zu regionalen Strukturen und Backbone-Designs.
• IPv6-Integration: IPv6 lässt sich oft sehr konsistent im selben Protokollmodell führen.
• Erweiterbarkeit: In modernen Designs wird IS-IS häufig als Basis für zusätzliche Informationen genutzt (z. B. Traffic-Engineering-/SR-Informationen), wenn das Netz in diese Richtung entwickelt wird.

Typische Herausforderungen von IS-IS

• Team-Familiarität: In manchen Organisationen ist IS-IS weniger verbreitet, Schulung und Routine fehlen.
• Adress-/Identifier-Disziplin: Konsistente Router-Identitäten und Struktur sind wichtig, sonst leidet Operabilität.
• Fehlerbilder: Ohne gute Observability können spezifische IS-IS-Events für unerfahrene Teams schwerer zu interpretieren sein.

Skalierung im Core: Welche Faktoren wirklich zählen

Ob OSPF oder IS-IS besser skaliert, hängt in der Praxis weniger von „Protokoll-Magie“ ab als von Designdisziplin. Die größten Skalierungshebel sind: Begrenzung der IGP-Präfixe, saubere Hierarchie (Areas/Levels), stabile Links, konsistente Metriken, Flap-Management und eine gute Observability. Ein „schlankes IGP“ ist fast immer wichtiger als die Wahl des Protokolls.

• IGP-Präfix-Minimalismus: Nur Infrastruktur; keine Kundenrouten, keine unnötigen Redistributes.
• Hierarchie: Area/Level-Struktur so wählen, dass Datenbanken klein bleiben und Updates lokal wirken.
• Stabilität: Link-Flaps und physische Fehler sind die größten „Konvergenz-Booster“ – hier lohnt Engineering am meisten.
• ECMP-Design: Parallele Pfade bewusst planen, damit Lastverteilung nicht zufällig entsteht.

Konvergenz und Failover: Design statt Timer-Tuning

Im Provider-Core wird Konvergenz oft als entscheidendes Kriterium genannt. Beide Protokolle können schnell rekonvergieren, wenn das Design stimmt. Aggressive Timer helfen nur begrenzt, wenn physische Instabilität oder falsche Failure Domains vorliegen. Best Practice ist, Failover messbar zu machen: Link-Ausfall, Node-Ausfall, PoP-Ausfall – und zu testen, wie sich das Netz verhält. Nur so wird klar, ob Konvergenz nicht nur schnell, sondern auch stabil ist.

• Failure Models definieren: Welche Ausfälle müssen abgefangen werden, und in welcher Zeit?
• Flap-Management: Wiederholte Kurzstörungen dämpfen, bevor sie die gesamte Control Plane belasten.
• Wartungsstrategie: Traffic bewusst umleiten, bevor Links oder Knoten angefasst werden.
• Messung: Konvergenzzeiten und Service-Impact regelmäßig prüfen und dokumentieren.

IPv6 und Dual-Stack: Konsistenz ist wichtiger als „nur IPv6 aktivieren“

In vielen Provider-Netzen ist IPv6 nicht mehr optional. Die IGP-Wahl sollte daher zur IPv6-Roadmap passen. Entscheidend ist, dass IPv6 nicht als „Nebenprodukt“ läuft: Adressierung, Security, Monitoring und Troubleshooting müssen IPv6-nativ funktionieren. In Dual-Stack-Umgebungen ist besonders wichtig, dass Topologie und Metriken konsistent bleiben – sonst entstehen unterschiedliche Pfade für IPv4 und IPv6, was Betrieb und Fehlersuche erschwert.

• Pfad-Konsistenz: IPv4 und IPv6 sollen möglichst ähnliche Pfade nutzen, wenn das Betriebsmodell es verlangt.
• Adressierungsstandard: Hierarchische Planung für Loopbacks und Links erleichtert Betrieb und Automatisierung.
• Monitoring: Latenz, Loss und Konvergenz für IPv6 genauso messen wie für IPv4.

Interaktion mit BGP und modernen Telco-Mechanismen

Im Telco-Core ist das IGP selten allein. Es bildet die Basis für iBGP-Transport, Route Reflection, MPLS-/SR-Mechanismen und Traffic Engineering. Daher sollte die IGP-Wahl auch danach bewertet werden, wie gut sie in das Gesamtbild passt: RR-Platzierung, Loopback-Erreichbarkeit, ECMP-Design, und die Fähigkeit, zusätzliche Topologieinformationen zu transportieren, falls das Netz in diese Richtung entwickelt wird.

• RR-Design: Route Reflectors brauchen stabile IGP-Erreichbarkeit und saubere Failure Domains.
• Core schlank halten: Komplexe Policies in BGP/Edge, IGP als stabile Infrastruktur-Schicht.
• Traffic Engineering: Pfadsteuerung basiert auf Topologie und Metriken; Konsistenz ist entscheidend.

Operations: Was im Alltag den Unterschied macht

Die „beste“ Protokollwahl nützt wenig, wenn Betrieb und Standards fehlen. Provider sollten die Entscheidung deshalb auch organisatorisch bewerten: Welche Skills sind im Team vorhanden? Welche Tools werden genutzt? Wie sehen Runbooks aus? Wie wird Konfigurationsdrift verhindert? Ein Protokoll, das perfekt zur Theorie passt, aber im Betrieb nicht verstanden wird, erhöht das Risiko für lange Ausfallzeiten.

• Teamkompetenz: Routine und Fehlerbilder müssen im Team sicher beherrscht werden.
• Standardisierung: Golden Configs, Templates, konsistente Metriken, klare Naming- und Adressierungsregeln.
• Observability: IGP-Adjacencies, SPF-Events, Link-Flaps, Paketverlust und Latenz müssen sichtbar sein.
• Change-Prozesse: Gestaffelte Rollouts, Reviews, Rollback-Pläne, regelmäßige Failover-Übungen.

Entscheidungshilfe: Wann OSPF, wann IS-IS?

In Provider-Netzen ist IS-IS häufig erste Wahl, wenn ein stark hierarchisches Core-Design, große Skalierung und ein Telco-typischer Betriebsansatz im Vordergrund stehen. OSPF ist häufig sinnvoll, wenn das Team starkes OSPF-Know-how hat, die Topologie überschaubar bleibt oder ein konsistentes Area-Design bereits etabliert ist. In beiden Fällen gilt: Ein diszipliniertes Design mit schlankem IGP und klaren Failure Domains ist wichtiger als die Protokollmarke.

• OSPF passt oft besser, wenn: OSPF-Expertise vorhanden ist, der Core eher klein bis mittel ist, und ein klares Area-Konzept bereits existiert.
• IS-IS passt oft besser, wenn: das Netz stark regionalisiert ist, ein L1/L2-Backbone-Modell gewünscht ist, und Skalierung/Erweiterbarkeit priorisiert werden.
• Beide passen gut, wenn: das IGP schlank gehalten wird und Standards/Observability konsequent umgesetzt sind.

Typische Stolperfallen bei beiden IGPs im Provider-Core

Viele Probleme werden fälschlich dem Protokoll zugeschrieben, obwohl sie Design- oder Betriebsprobleme sind. Besonders häufig: zu viele Routen im IGP, inkonsistente Metriken, instabile Links, unklare Hierarchiegrenzen und fehlende Tests. Ein gutes Design erkennt diese Risiken früh und baut Leitplanken ein.

• IGP als Routenmüllhalde: Kundenrouten oder zahlreiche Redistributes im IGP erhöhen Instabilität.
• Inkonsequente Metriken: Unvorhersehbare Pfade, ECMP wirkt nicht wie geplant.
• Zu große Domänen: Eine riesige Single-Domain ohne Hierarchie vergrößert Fehlerdomänen und Update-Last.
• Flaps ignorieren: Physische Instabilität führt zu Konvergenzstürmen, unabhängig vom Protokoll.
• Keine Observability: Ohne Sichtbarkeit werden SPF-Events und Ursachen nicht sauber verstanden.

Operative Checkliste: OSPF/IS-IS im Core sauber planen

Diese Checkliste hilft, die IGP-Wahl und das Core-Design praxisnah abzusichern – unabhängig davon, ob Sie OSPF oder IS-IS einsetzen.

• Ist das IGP bewusst auf Infrastruktur begrenzt (Loopbacks, Core-Links) und sind Service-/Kundenrouten außerhalb?
• Gibt es ein klares Hierarchiekonzept (OSPF Areas oder IS-IS Levels) mit dokumentierten Grenzen und Ownership?
• Sind Metriken konsistent und unterstützt das Design ECMP sowie eine planbare Lastverteilung?
• Sind Failure Models definiert, N-1-Headroom eingeplant und Konvergenztests regelmäßig durchgeführt?
• Sind Links und physische Abhängigkeiten stabil (Trassenvielfalt, Flap-Analyse, saubere Wartungsprozesse)?
• Ist IPv6 konsequent eingeplant (Adressierung, Pfadkonsistenz, Monitoring, Security)?
• Ist Observability vollständig (Adjacencies, SPF-Events, Link-Flaps, Loss/Latenz) und sind Runbooks vorhanden?
• Passt die Protokollwahl zur Betriebsreife (Skills, Tooling, Templates, Automatisierung, Drift-Erkennung)?

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.