Das Hauptkeyword „OSPF vs. IS-IS fürs Backbone“ taucht in ISP- und Telco-Teams immer dann auf, wenn es um mehr geht als Protokoll-Religion: Betriebssicherheit, Konvergenzverhalten und das Risiko großer Routing-Incidents hängen im Backbone stark davon ab, wie sauber das IGP designt und operationalisiert ist. OSPF und IS-IS sind beide Link-State-Protokolle, beide können in großen Netzen stabil laufen, beide können bei schlechter Hygiene spektakulär scheitern. Der Unterschied liegt weniger in „welches ist schneller“, sondern in den typischen Failure Modes, dem Betriebsmodell (Adressierung, Segmentierung, Tooling), der Interaktion mit BFD und Hardware-FIB sowie in der Frage, wie gut ein Team Konfigurationen standardisieren und Veränderungen kontrollieren kann. Während OSPF historisch stärker IP-zentriert ist und vielen Engineers vertraut vorkommt, gilt IS-IS in vielen Provider-Backbones als robustes Underlay-IGP, das sich gut in klaren Levels und mit „schlanker“ Link-State-Domain betreiben lässt. Dieser Artikel ordnet OSPF und IS-IS für Backbone-Designs praxisnah ein: Welche Betriebsaspekte zählen, wie Konvergenz im Alltag tatsächlich entsteht, welche Risiken Operatoren typischerweise sehen und wie Sie unabhängig vom Protokoll die Routing-Hygiene verbessern.
Backbone-Anforderungen: Was ein IGP im Provider-Kern leisten muss
Im Backbone sind die Prioritäten anders als im Enterprise-Campus. Ein IGP ist hier nicht „für alles“, sondern idealerweise das stabile Underlay, auf dem Services (BGP, MPLS/SR, EVPN, Internet-Routing) zuverlässig laufen. Typische Anforderungen sind:
- Vorhersagbare Konvergenz: schnell genug für SLA-Realität, aber ohne Control-Plane-Stürme.
- Skalierbare Segmentierung: klare Grenzen für Flooding, Berechnung und Fehlerausbreitung.
- Operative Einfachheit: wenige Profile, wenige Sonderfälle, klare Runbooks.
- Interaktion mit Transport-Features: MPLS/TE, Segment Routing, FRR-Mechanismen (je nach Netz).
- Robuste Failure-Isolation: ein flappender Link darf nicht das gesamte Netz in SPF-Last versetzen.
Gemeinsamkeiten: Warum der Vergleich oft falsch geführt wird
OSPF und IS-IS sind beides Link-State-Protokolle. In beiden Fällen gilt: Das Protokoll selbst ist selten der Engpass, sondern Design- und Betriebsentscheidungen. Gemeinsam sind unter anderem:
- Link-State-Datenbank: Topologieinformationen werden verteilt, SPF berechnet Pfade.
- Konvergenz-Kette: Fehlererkennung → Flooding/Propagation → SPF → FIB-Programmierung.
- Skalierung über Hierarchien: OSPF über Areas, IS-IS über Levels.
- Abhängigkeit von Hygiene: Interface-Stabilität, MTU, Timer-Profile, CoPP/BFD sind entscheidend.
Wer „OSPF ist schneller“ oder „IS-IS ist stabiler“ pauschal behauptet, übersieht meist, dass Konvergenz in der Praxis vom Erkennungsmechanismus und von FIB-Programmierung genauso beeinflusst wird wie vom IGP.
Konvergenz im Backbone: Die relevanten Zeitanteile
Damit „Konvergenz“ im Betrieb messbar wird, lohnt ein einfaches Modell. Es zeigt auch, warum ein IGP-Wechsel alleine selten Wunder bewirkt:
- T_detect: Erkennung (physisches Event, BFD, Dead Timer).
- T_flood: Verteilung der Topologieänderung (LSAs/LSPs).
- T_spf: SPF-Berechnung inkl. Throttling/Queuing.
- T_fib: Programmierung von Forwarding (Linecards, TCAM, Hardware-Queues).
In vielen Backbones ist T_detect durch BFD klein, während T_fib oder SPF-Queuing bei großen Updates dominieren kann. Deshalb gehören Konvergenztests immer in Change- und Incident-Playbooks – unabhängig davon, ob OSPF oder IS-IS im Einsatz ist.
OSPF fürs Backbone: Betriebsmodell, Vorteile und typische Risiken
OSPF ist in vielen Teams verbreitet, gut dokumentiert und in vielen Tools direkt abbildbar. Für Backbone-Designs wird OSPF meist als „Underlay-IGP“ genutzt, während Service-Routen in BGP liegen. Wichtige Vorteile im Betrieb:
- Vertrautheit: viele Engineers kennen OSPF-Basics, Onboarding ist oft schneller.
- Klare Area-Logik: Backbone-Area (Area 0) plus weitere Areas lassen sich sauber dokumentieren.
- Breite Implementierungsbasis: OSPF ist in nahezu allen Plattformen ausgereift.
Typische Risiken im Backbone-Kontext entstehen weniger durch OSPF „an sich“, sondern durch konkrete Designmuster:
- Zu große Flooding-Domäne: „alles in Area 0“ führt zu hoher LSA-Last bei Flaps.
- Area-Design ohne Summaries: keine klare Adressplanung, keine Aggregation, unnötig große RIB/FIB.
- Netzwerktypen-Mismatch: falsche OSPF-Network-Types auf Links, besonders in Mixed-Media-Umgebungen.
- Redistribution-Fallen: unkontrolliertes Einspeisen von Prefixes in OSPF erzeugt Instabilität.
Als Referenz für OSPFv2 eignet sich RFC 2328, für OSPFv3 (IPv6) RFC 5340.
IS-IS fürs Backbone: Betriebsmodell, Vorteile und typische Risiken
IS-IS wird in vielen Provider-Backbones gern als Underlay genutzt, weil es in der Praxis gut mit „schlanken“ IGP-Domänen und klarer Segmentierung über Level-Designs harmoniert. Operative Vorteile, die Betreiber häufig nennen:
- Level-basierte Hierarchie: L1/L2-Modelle erlauben eine klare Trennung zwischen „regionale Domäne“ und „Backbone“.
- Stabiles Underlay-Denken: IS-IS wird oft konsequent nur für Infrastructure-Prefixes genutzt, wodurch es ruhig bleibt.
- Gute Passform für SR/MPLS: in vielen Netzen wird IS-IS als natürlicher Träger für TE/SR-Informationen gesehen (abhängig vom Design).
Auch bei IS-IS entstehen Risiken primär durch Hygiene-Probleme und unklare Konventionen:
- Uneinheitliche Level-Grenzen: wenn „L2 überall“ oder „L1/L2 gemischt“ ohne sauberes Modell betrieben wird, wird Troubleshooting schwer.
- Adressierungs-/System-ID-Konventionen fehlen: ohne klare Identität pro Router entstehen Operativ-Fehler und Tooling-Probleme.
- Übersehene MTU-/CLNS-Details: seltene Edge-Cases können zu schwer erklärbaren Nachbarschaftsproblemen führen.
Als Referenz für IS-IS in IP-Umgebungen dient RFC 1195.
Hierarchie und Skalierung: Areas (OSPF) vs. Levels (IS-IS)
Beide Protokolle skalieren über Hierarchien, aber die Betriebsrealität unterscheidet sich. Die wichtigste Frage lautet: Wie begrenzen Sie die Ausbreitung von Instabilität?
- OSPF Areas: sinnvoll, wenn Sie klare Grenze zwischen Backbone und Edge/Regionen ziehen und Summaries konsequent nutzen. Risiko: Area-Design wird oft „organisch“, wodurch Sonderfälle entstehen.
- IS-IS Levels: L1 für regionale Bereiche, L2 als Backbone; sehr klar, wenn das Modell konsequent umgesetzt wird. Risiko: wenn Teams Level-Design nicht strikt standardisieren, entstehen Mischformen.
In beiden Fällen ist Summarization kein kosmetisches Feature, sondern Stabilitätsmechanik: Weniger Prefixes im Kern bedeutet weniger FIB-Druck und weniger Komplexität im Incident.
Konvergenz- und Stabilitätsfaktoren: Was im Betrieb mehr zählt als das Protokoll
Operatoren erreichen stabile IGPs nicht durch „das bessere Protokoll“, sondern durch konsistente Betriebsregeln. Die wichtigsten Faktoren sind:
- Link-Qualität und L1/L2-Hygiene: CRC/Errors, Optik-Degradation, LAG-Member-Flaps erzeugen IGP-Flaps.
- BFD-Design: wenige Profile, überall konsistent, Control-Plane zuverlässig geschützt.
- SPF-Throttling und Flooding-Rate: Glättung ja, aber Root Cause von Flaps beheben.
- FIB-Programmierung: Hardware kann zum Engpass werden; FIB-Telemetrie ist Pflicht.
- Change-Disziplin: staged rollouts, Pre-/Post-Checks, Rollback-Readiness.
Für BFD als Standard lohnt RFC 5880. Wichtig ist, dass BFD nicht „nur schneller“ macht, sondern auch neue Failure Modes erzeugen kann, wenn CoPP/Policer oder CPU-Queues nicht passend gestaltet sind.
Troubleshooting und RCA: Unterschiede in der täglichen Arbeit
Im Incident zählt, wie schnell ein Team von Symptomen zu Root Cause kommt. Hier spielen Tooling, Konventionen und die Lesbarkeit der Zustände eine große Rolle.
- OSPF RCA-Muster: häufige Analyse über LSA-Typen, Area-Grenzen, ABR-Verhalten, Netzwerktypen und Timer. Vorteil: viele Standardrunbooks existieren. Risiko: große Area-0-Domänen erzeugen viel Rauschen.
- IS-IS RCA-Muster: Fokus auf LSP-Rate, Level-Grenzen, System-ID-Identität, adjacency state und event-Korrelation. Vorteil: klare L1/L2-Grenzen können Fault Domains gut abbilden. Risiko: Teams ohne IS-IS-Erfahrung interpretieren Signale anfangs langsamer.
In beiden Fällen ist die wichtigste operative Fähigkeit: Topologieänderungen quantifizieren (Rate, Scope, Ursache) und sie mit L1/L2-Indikatoren zu korrelieren, um „IGP ist kaputt“ nicht mit „Link ist dreckig“ zu verwechseln.
Typische Failure Modes im Backbone und wie sie sich unterscheiden
Viele Failure Modes sind protokollunabhängig, aber ihre Diagnose fühlt sich unterschiedlich an.
Flapping-Links und Control-Plane-Last
- OSPF: hohe LSA-Rate, häufige SPF-Läufe, potenziell stärkere Wahrnehmung „das ganze Netz flackert“, wenn die Area groß ist.
- IS-IS: erhöhte LSP-Rate, eventuell deutlicher sichtbar pro Level; wirkt oft „geordneter“, wenn Level-Grenzen sauber sind.
Adressierungs- und Summarization-Probleme
- OSPF: ohne Summaries wachsen LSDB und RIB im Kern; ABR-Konzept kann helfen, wird aber häufig inkonsequent umgesetzt.
- IS-IS: Level-Design plus Summaries kann Kern schlank halten; erfordert aber stringente Adressierungsdisziplin.
Redistribution und Route-Leaks
- OSPF: External Routes und Policyfehler können schnell groß werden, wenn „mal eben“ Services in OSPF landen.
- IS-IS: ähnliche Gefahr bei Leak in das Underlay; viele Betreiber vermeiden dies, indem IS-IS strikt nur Infrastructure trägt.
Migration und Koexistenz: Wie Operatoren den Wechsel risikoarm angehen
Ein Wechsel von OSPF zu IS-IS oder umgekehrt ist möglich, aber im Backbone ein Hochrisiko-Change, wenn er nicht als Programm mit klaren Phasen geplant wird. Typische Prinzipien für eine risikoarme Migration:
- IGP strikt als Underlay definieren: zuerst Scope reduzieren (keine Kundenrouten), dann migrieren.
- Dual-Stack/IPv6 bewusst planen: OSPFv3 vs. IS-IS Multi-Topology/IPv6-Ansatz (je nach Plattform/Design).
- Parallelbetrieb mit klaren Grenzen: Übergänge an definierten Knoten, Redistribution streng gefiltert und getaggt.
- Messbare Konvergenztests: vor, während und nach der Migration – inklusive FIB-Programmierung und Traffic-Stabilisierung.
- Rollback-Strategie: technisch und organisatorisch vorbereitet, nicht „im Kopf“.
Wichtig: Migration ist nicht nur Protokollwechsel, sondern auch ein Wechsel der Betriebsgewohnheiten (IDs, Naming, Monitoring, Runbooks). Diese Arbeit sollte eingeplant sein.
Entscheidungskriterien: Wann OSPF, wann IS-IS?
Für eine Backbone-Entscheidung sind meist folgende Kriterien aussagekräftiger als reine Featurelisten:
- Team-Kompetenz und Runbooks: was kann das Team zuverlässig 24/7 betreiben und debuggen?
- Netzsegmentierung: welche Hierarchie passt besser zu Ihrer Topologie und Organisationsstruktur?
- Tooling/Automatisierung: welches Protokoll lässt sich besser in Ihre Provisioning- und Observability-Tools integrieren?
- Underlay-Philosophie: gelingt es, das IGP „ruhig“ zu halten und Services in BGP zu verlagern?
- Plattform- und Featurebedarf: insbesondere bei TE/SR/FRR-Designs (je nach Herstellerlandschaft).
In vielen Provider-Umgebungen ist die Entscheidung am Ende pragmatisch: Das „beste“ IGP ist das, das als standardisiertes Produkt betrieben wird – mit klaren Profilen, klaren Grenzen und konsequentem Change-Management.
Routing-Hygiene als Protokoll-unabhängige Checkliste
- IGP-Scope begrenzen: nur Infrastructure-Prefixes, keine Kundenrouten.
- Flooding-Domänen klein halten: Areas/Levels so designen, dass Instabilität am Rand bleibt.
- Adressierung planbar machen: Summarization ermöglichen, keine „freien“ Prefixes ohne Schema.
- BFD konsistent einsetzen: wenige Profile, CoPP/Policer passend, Telemetrie vorhanden.
- SPF/FIB beobachten: nicht nur Neighbor up/down, sondern LSA/LSP-Rate, SPF-Dauer, FIB-Update-Zeiten.
- Change-Validierung standardisieren: Pre-/Post-Checks, staged rollout, Rollback-ready.
Outbound-Referenzen für Standards und vertiefende Dokumentation
- RFC 2328: OSPF Version 2 (OSPFv2)
- RFC 5340: OSPF for IPv6 (OSPFv3)
- RFC 1195: IS-IS for Routing in TCP/IP and Dual Environments
- RFC 5880: Bidirectional Forwarding Detection (BFD)
- IETF RFC Index: zentrale Sammlung aktueller Protokollspezifikationen
Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte
Cisco Networking • CCNA • Packet Tracer • Network Configuration
Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.
Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.
Leistungsumfang:
-
Netzwerkdesign & Topologie-Planung
-
Router- & Switch-Konfiguration (Cisco IOS)
-
VLAN, Inter-VLAN Routing
-
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
-
NAT, ACL, DHCP, DNS-Konfiguration
-
Troubleshooting & Netzwerkoptimierung
-
Packet Tracer Projektentwicklung & Dokumentation
-
CCNA Lern- & Praxisunterstützung
Lieferumfang:
-
Konfigurationsdateien
-
Packet-Tracer-Dateien (.pkt)
-
Netzwerkdokumentation
-
Schritt-für-Schritt-Erklärungen (auf Wunsch)
Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert
CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.
