Site icon BintoroSoft PDF Tools

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

Red Snapper

Engineer looking to work in the electrical control room. Neural network AI generated art

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.

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?“

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

Stärken von OSPF im Provider-Kontext

Typische Herausforderungen von OSPF im großen Core

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

Stärken von IS-IS im Provider-Kontext

Typische Herausforderungen von IS-IS

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.

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.

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.

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.

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.

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.

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.

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.

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

Sie erhalten

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.

Exit mobile version