February 15, 2026

OSPF/IS-IS: Das passende IGP fürs moderne Backbone wählen

OSPF/IS-IS ist im Enterprise und im Service-Provider-nahen Umfeld die Standardfrage, sobald ein Backbone modernisiert oder neu gebaut wird: Welches Interior Gateway Protocol (IGP) passt besser zu Topologie, Betriebsmodell, Automatisierung und Wachstum? Beide Protokolle sind ausgereift, breit unterstützt und können große Netzwerke stabil betreiben – sofern Design und Betrieb sauber umgesetzt werden. Dennoch gibt es reale Unterschiede, die im Alltag zählen: OSPF ist vielen Teams vertrauter, hat klare Area-Konzepte und eine große Tooling-Landschaft. IS-IS gilt oft als „Backbone-freundlich“, skaliert in manchen Designs sehr elegant, bleibt in Layer-2-Nähe robust und integriert Erweiterungen (z. B. Traffic Engineering) historisch sehr konsistent. In modernen Backbones kommen weitere Anforderungen hinzu: schnelle Konvergenz, ECMP, klare Summarization-Grenzen, stabile Loopbacks, saubere Segmentierung (VRFs), Telemetrie, Automatisierung sowie die Rolle des IGP als Underlay für BGP-basierte Overlays oder für Segment Routing. Dieser Artikel hilft dabei, OSPF und IS-IS nicht nach „Geschmack“ zu wählen, sondern anhand belastbarer Kriterien: Architektur, Skalierung, Failure Domains, Betriebsaufwand, Migrationsrisiko und langfristige Operational Safety.

Table of Contents

IGP im modernen Backbone: Wofür wird OSPF oder IS-IS heute wirklich genutzt?

In vielen heutigen Architekturen ist das IGP nicht mehr dafür da, „alle Kunden- und Service-Routen“ zu tragen. Stattdessen hat es häufig eine klarere Aufgabe: stabile Erreichbarkeit der Infrastruktur, schnelle Konvergenz für Link- und Node-Failures und Bereitstellung eines zuverlässigen Underlays, auf dem BGP (z. B. iBGP, EVPN, WAN-Edge) aufsetzt. Typische IGP-Aufgaben im Enterprise-Backbone:

Transport der Loopbacks (Router-IDs, BGP-Endpunkte, Management-IPs) als Grundlage für stabile Sessions.
Next-Hop-Erreichbarkeit für BGP, Segment Routing oder Tunnel-Endpunkte.
ECMP im Core für Lastverteilung und Resilienz.
Schnelle Failure-Reaktion in Kombination mit BFD und optimierten Timern.
Summarization und Failure Domains durch Areas/Levels, um Routing-Noise zu begrenzen.

Wer den IGP-Scope bewusst klein hält (Infrastruktur statt „alles“), reduziert Komplexität und macht die Wahl zwischen OSPF und IS-IS stärker zu einer Frage von Betriebsmodell und Skalierung, weniger zu einer reinen Feature-Diskussion.

Gemeinsamkeiten: Was beide Protokolle sehr gut können

OSPF und IS-IS sind Link-State-Protokolle: Sie bauen eine Topologiedatenbank auf, berechnen Pfade per SPF (Dijkstra) und verteilen Änderungen als Link-State-Informationen. Gemeinsamkeiten, die in der Praxis wichtig sind:

Schnelle Konvergenz bei Link-Ausfällen, insbesondere mit BFD und optimiertem LSA/LSP-Handling.
Hierarchisches Design zur Begrenzung von Flooding und SPF-Last (OSPF Areas, IS-IS Levels).
ECMP-Unterstützung für parallele Pfade im Backbone.
Traffic Engineering Erweiterungen und gute Interoperabilität in großen Netzwerken.
IPv6-Unterstützung über OSPFv3 bzw. Multi-Topology/IPv6-Erweiterungen bei IS-IS.

Damit wird die Entscheidung selten „kann das Protokoll X Feature Y?“, sondern eher „wie sauber bekommen wir das Design skaliert und operationalisiert?“

Architekturvergleich: Areas bei OSPF vs. Levels bei IS-IS

Der größte strukturelle Unterschied ist die Hierarchie:

OSPF: Areas mit einem Backbone (Area 0). Nicht-Backbone-Areas hängen logisch am Backbone; ABRs (Area Border Router) verbinden Areas. Summarization erfolgt typischerweise an ABRs/ASBRs.
IS-IS: Level-1 (intra-area) und Level-2 (backbone). Ein Router kann L1, L2 oder L1/L2 sein. Level-2 bildet das Backbone, Level-1 die „Areas“ (oft als Bereiche/Regionen).

Praktische Auswirkungen auf Design und Betrieb

Backbone-Zwang: OSPF verlangt ein zusammenhängendes Area-0-Design. Das ist planbar, kann aber bei komplexen Topologien oder Übergangsphasen operationalen Druck erzeugen.
„Natürliches Backbone“: IS-IS Level-2 lässt sich in vielen Backbones sehr direkt modellieren; Level-1 wirkt wie „Edge-Area“ mit klaren Leaks nach L2.
Grenzrouter-Rolle: OSPF-ABRs sind klar definiert; IS-IS L1/L2-Router übernehmen diese Rolle flexibler, was Designfreiheit gibt, aber Governance erfordert.

Skalierung und Performance: Topologiedatenbank, Flooding und SPF-Last

Link-State-Protokolle skalieren dann gut, wenn Sie Flooding-Domänen und SPF-Berechnungen kontrollieren. Entscheidend ist, wie groß die jeweilige Link-State-Datenbank pro Domäne wird und wie oft sie churnt. Ein vereinfachtes Modell für Rechenaufwand hilft, die Richtung zu verstehen:

$SPF \approx O (E + V \cdot \log (V))$

V steht für die Anzahl Knoten (Router), E für Links. Das Modell ist bewusst grob: In der Praxis beeinflussen Implementierung, Incremental SPF, LSA/LSP-Throttling und Hardware erheblich. Der Grundgedanke bleibt: Je größer die Flooding-Domäne, desto stärker müssen Sie Design und Timer disziplinieren.

OSPF-Skalierung: Areas begrenzen Flooding. Innerhalb einer Area kann die LSA-Anzahl bei sehr vielen Links/Interfaces steigen, besonders mit vielen LAN-Segmenten.
IS-IS-Skalierung: Level-2 als Backbone und Level-1 als „Edge“ sind oft sehr stabil. IS-IS nutzt TLVs und hat historisch sehr konsistente Erweiterungen, was in großen Netzen Vorteile bringen kann.

Adressierung und Router-IDs: IPv4/IPv6 sauber einbinden

IPv6 ist im Backbone häufig „mit dabei“, selbst wenn Anwendungen noch IPv4-lastig sind. Hier unterscheiden sich OSPF und IS-IS im operativen Gefühl:

OSPFv2 und OSPFv3: IPv4 über OSPFv2, IPv6 über OSPFv3. Das kann zwei Prozesse oder zumindest zwei Konfigurationskontexte bedeuten (plattformabhängig).
IS-IS für IPv4/IPv6: IS-IS trägt IPv4 und IPv6 über TLVs im selben Protokollframework (typisch als Multi-Topology oder integrierte IPv6-Erweiterungen), was im Betrieb oft „einheitlicher“ wirkt.

Für OSPFv3 ist OSPF for IPv6 (RFC 5340) eine zentrale Referenz. Für IS-IS und IPv6 sind Routing IPv6 with IS-IS (RFC 5308) und die IS-IS-Grundlagen in IS-IS for IP (RFC 1195) hilfreich.

Operational Safety: Authentifizierung, Filtering und Fehlerisolierung

IGP-Sicherheit ist im Enterprise-Backbone nicht optional. Falsche Neighbor-Adjacencies, unautorisierte Router oder Konfigurationsdrift können Routing-Instabilität auslösen. Best Practices für beide Protokolle:

Authentifizierung: konsequent auf allen Links (z. B. HMAC-basierte Verfahren, je nach Plattform).
Passive Interfaces: überall dort aktivieren, wo keine Nachbarschaft entstehen soll.
Adjacency-Grenzen: Backbone-Links klar definieren, „zufällige“ Nachbarschaften durch falsches VLAN/Trunking verhindern.
Route-Leaks vermeiden: IGP-Scope auf Infrastruktur begrenzen; Service-Routen lieber über BGP/Policy steuern.

Ein praktischer Unterschied: OSPF hat ein sehr etabliertes Area-Konzept, um Fault Domains zu begrenzen. IS-IS erreicht dasselbe über Levels, wobei L1- und L2-Domänen oft sehr klar getrennt werden können. In beiden Fällen gilt: Die Hierarchie ist Ihr Sicherheits- und Stabilitätswerkzeug.

Konvergenz im Alltag: Timer, BFD und “fast reroute”-Denke

Moderne Backbones erwarten, dass ein Link- oder Node-Failure schnell „sauber“ verarbeitet wird. Dabei ist es entscheidend, Control Plane und Data Plane gemeinsam zu betrachten. Typische Bausteine:

BFD: erkennt Forwarding-Failures schnell und triggert IGP-Reaktionen. Referenz: BFD (RFC 5880).
IGP-Throttling: LSA/LSP-Pacing und SPF-Throttling verhindern, dass ein Flap-Sturm die Control Plane überlastet.
ECMP-Failures: Member-Links in Bundles (LACP) sauber behandeln; Hashing kann sporadische Effekte maskieren.
Underlay-Health: Interface-Counter, Optik-Telemetrie und Queue-Drops müssen in die Diagnose einfließen.

Timer-Tuning mit Maß

Zu aggressive Timer sind ein klassischer Fehler: Sie können „schneller“ wirken, erhöhen aber CPU-Last und machen das Netz anfälliger für Microbursts an Events. Im Enterprise-Backbone ist ein robustes Ziel häufig: stabile Default- oder moderat optimierte Timer plus BFD, statt extrem niedriger Hello/Dead-Intervale überall.

Traffic Engineering und moderne Erweiterungen: Was Sie wirklich brauchen

Viele Teams verbinden IS-IS stärker mit Traffic Engineering, weil TE-Erweiterungen dort historisch früh und konsistent verbreitet waren. In der Praxis unterstützen beide Protokolle TE-Mechanismen, entscheidend ist eher Ihre Architektur:

IGP als Underlay für Segment Routing: SR-Metadaten werden über das IGP verteilt; sowohl OSPF als auch IS-IS können dafür genutzt werden (plattform- und vendorabhängig).
TE-Daten für Pfadberechnung: Bandbreite, Admin Groups, Link-Metriken – hilfreich, wenn Sie gezielte Pfade planen oder automatisieren.
IGP-Metrikmodell: konsistente Kostenvergabe ist wichtiger als das Protokoll selbst.

Wenn Ihr Backbone im Wesentlichen ECMP-getrieben ist und BGP die Service-Lenkung übernimmt, bleibt IGP-TE oft sekundär. Wenn Sie hingegen explizite Pfadsteuerung (z. B. für latenzkritische Dienste) betreiben, sollten Sie TE-Fähigkeiten, Tooling und Telemetrie-Integration sehr früh evaluieren.

Design-Kriterien, die die Wahl in der Praxis entscheiden

In Enterprise-Entscheidungen sind technische Details wichtig, aber am Ende gewinnt das Protokoll, das sich langfristig besser betreiben lässt. Die folgenden Kriterien sind häufig entscheidender als „Feature-Listen“:

Team-Kompetenz und Debuggability: Welches Protokoll kann das On-Call-Team unter Stress schneller interpretieren?
Vendor- und Plattformmix: Wie konsistent sind Implementierungen, Telemetrie und Automationsschnittstellen über Ihre Geräte hinweg?
Hierarchie-Fit: Passt ein Area-0-zentriertes Modell (OSPF) oder ein L2/L1-Backbone-Modell (IS-IS) besser zu Ihren Regionen und Failure Domains?
IPv6-Betriebsmodell: Wollen Sie OSPFv2/v3 getrennt managen oder ein „einheitlicheres“ IS-IS-Framework?
Change-Risiko: Wie hoch ist die Wahrscheinlichkeit, dass eine falsche Area/Level-Zuordnung oder ein falscher Interface-Typ große Teile betrifft?
Summarization und Aggregation: Können Sie an sinnvollen Grenzen zusammenfassen, ohne Blackholes zu riskieren?

OSPF: Typische Stärken im Enterprise-Backbone

Verbreitete Expertise: Viele Netzwerkteams kennen OSPF sehr gut, inklusive Area-Design und Troubleshooting.
Klares Area-Modell: Areas und ABRs sind für Dokumentation und Governance oft sehr greifbar.
Tooling und Monitoring: Umfangreiche Unterstützung in NMS, Tracing und Schulungsmaterialien.
Gut für Campus-ähnliche Hierarchien: wenn Area 0 sauber als Core/Backbone modelliert werden kann.

Als Referenz für OSPFv2 eignet sich OSPF Version 2 (RFC 2328).

IS-IS: Typische Stärken im modernen Backbone

Backbone-orientiertes Modell: Level-2 als natürliches Core-Backbone, Level-1 als Edge-Domäne.
Konsistentes Erweiterungsmodell: TLV-basierte Erweiterungen wirken in großen Netzen oft „sauber“ integrierbar.
Operative Robustheit: Nachbarschaften laufen auf Layer 2 und sind dadurch in manchen Designs weniger anfällig für IP-Adressierungsfehler auf Transitlinks.
Einheitlicher Umgang mit IPv4/IPv6: häufig als operativer Vorteil wahrgenommen.

Als Einstieg sind IS-IS for IP (RFC 1195) und für TE- und Erweiterungskonzepte IS-IS Extensions for Traffic Engineering (RFC 5305) nützlich.

Migrationsrealität: Von OSPF zu IS-IS (oder umgekehrt) ohne Risikoexplosion

Die Wahl des „passenden“ IGP ist oft auch eine Migrationsfrage: Viele Enterprises haben historisch OSPF, wollen aber für ein neues Backbone (z. B. Data Center Fabric) IS-IS nutzen – oder umgekehrt vereinheitlichen. Eine sichere Migration folgt typischerweise diesen Prinzipien:

IGP-Scope reduzieren: zuerst klären, welche Präfixe wirklich ins IGP gehören (meist Loopbacks/Transit, nicht alle VLANs).
Paralleler Betrieb mit klaren Grenzen: Redist nur kontrolliert, preferiert über Policies, mit Tagging und strengen Filtern.
Staged Rollout: zuerst Lab/PoC, dann Pilotregion, dann schrittweise Ausdehnung.
Konvergenz-Tests: definierte Failure-Szenarien (Link down, Node reload, ECMP member loss) messen und dokumentieren.
Rollback-Plan: technisch und organisatorisch vorbereitet, nicht „im Incident“ improvisiert.

Troubleshooting- und Observability-Aspekte: Was im On-Call zählt

Im Incident entscheiden wenige Signale darüber, wie schnell Sie root cause und Blast Radius finden. Für beide Protokolle sollten Sie standardisierte Dashboards und Runbooks etablieren:

Neighbor-Flaps: Zeitachsen, Interface-Events, BFD-Status, CPU/Memory-Korrelation.
LSA/LSP-Churn: ungewöhnlich viele Updates, Topology Changes, Flooding Hotspots.
SPF-Auslastung: SPF Runs pro Minute, Incremental SPF, Throttling-Events.
Data-Plane-Korrelation: Drops/Errors/Queues auf den betroffenen Links, nicht nur „Protokoll ist up“.

Ein solides IGP-Design macht diese Beobachtungen einfacher: klare Hierarchien, begrenzte Flooding-Domänen und ein kleiner IGP-Scope führen zu besserer Signalqualität und schnellerer MTTR.

Entscheidungsmatrix: Schnell prüfen, was besser passt

Sie haben ein klar zusammenhängendes Core-Backbone und ein OSPF-starkes Team: OSPF kann sehr gut passen, wenn Area-0-Disziplin und Summarization sauber umgesetzt werden.
Sie bauen ein neues Backbone oder eine Fabric mit Fokus auf Skalierung, Underlay-Stabilität und konsistente Erweiterungen: IS-IS ist häufig eine sehr gute Wahl, besonders in Spine-Leaf-ähnlichen Designs.
IPv6 soll operativ „einfach“ mitlaufen: IS-IS wird oft als einheitlicher empfunden, während OSPFv2/v3 Trennung mehr Governance erfordert.
Ihr Netz ist heterogen (viele Plattformen, viele Teams): wählen Sie das Protokoll, für das Sie die besten Standards, Templates, Telemetrie und Automations-Guardrails etablieren können.

Outbound-Links für Standards und vertiefende Informationen

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.