IS-IS vs. OSPF fürs ISP-Backbone: Operativer Vergleich und Konvergenz

Der operative Vergleich „IS-IS vs. OSPF fürs ISP-Backbone“ ist weniger eine Religionsfrage als eine Entscheidung über Fehlerszenarien, Skalierung und Konvergenzverhalten im Alltag. Beide Protokolle sind Link-State-IGPs, beide bauen eine Topologie-Datenbank auf und berechnen Pfade mit SPF (Dijkstra). Trotzdem unterscheiden sie sich spürbar in Bedienbarkeit, Default-Verhalten, Erweiterbarkeit und in den typischen Failure Modes, die ein NOC im Backbone wirklich sieht: Link-Flaps, LAG/ECMP-Änderungen, Maintenance-Fenster, MTU-Probleme, Control-Plane-Spikes und die Frage, wie schnell und wie stabil das Netz nach einem Ereignis wieder „ruhig“ wird. In ISP-Backbones sind Anforderungen häufig strenger als in Enterprise-Netzen: sehr viele Interfaces, klare Hierarchien, viele P2P-Links, konsequente Automatisierung und ein starker Fokus auf deterministische Konvergenz (inklusive Fast Reroute). Genau hier lohnt sich ein nüchterner Blick: IS-IS wird in vielen Provider-Netzen als robust und „Backbone-natürlich“ betrachtet, während OSPF in vielen Umgebungen wegen verbreiteter Kenntnisse und klarer Adressierung beliebt ist. Dieses Dokument liefert einen praxisnahen Vergleich, der nicht bei Features stehen bleibt, sondern operative Auswirkungen (Fehlersuche, Stabilität, Konvergenz) in den Mittelpunkt stellt und konkrete Entscheidungskriterien für Provider-Teams bietet.

Gemeinsame Basis: Was OSPF und IS-IS im Backbone identisch macht

Beide Protokolle sind Link-State-IGPs. Operativ bedeutet das: Jeder Router bildet Adjazenzen zu Nachbarn, tauscht Link-State-Informationen aus (LSAs bei OSPF, LSPs bei IS-IS), erstellt daraus eine Link-State-Datenbank und berechnet mit SPF den besten Pfad zu allen Zielen. Typische Backbone-Mechaniken wie ECMP (Equal-Cost Multipath) basieren dann auf der SPF-Ergebnisliste. Auch die wichtigsten Stabilitätsrisiken sind ähnlich: zu aggressive Timer, häufige Flaps, zu große LSDBs, unkontrollierte Topologieänderungen und Control-Plane-Überlast.

• Konvergenzprinzip: Ereignis erkennen → LSA/LSP fluten → SPF laufen lassen → FIB programmieren.
• Skalierungshebel: Hierarchie (Areas/Levels), Aggregation, gezielte Flooding-Domänen.
• Fast Reroute: beide unterstützen Mechanismen für schnelle Umleitung (z. B. Loop-Free Alternates).

Architektur im ISP-Backbone: Areas bei OSPF vs. Levels bei IS-IS

Der wichtigste strukturelle Unterschied ist die Hierarchie. OSPF arbeitet mit Areas (Backbone Area 0 plus weitere Areas). IS-IS arbeitet mit Levels (Level-1 für intra-area, Level-2 für backbone-ähnliche Topologie, und L1/L2-Router als Übergang). Operativ führt das zu unterschiedlichen „Fehlermustern“:

• OSPF: Area 0 ist kritisch; Designfehler oder Fragmentierung der Backbone-Area führen schnell zu komplexen Symptomen (z. B. fehlende LSAs, Suboptimal Routing, unerwartete Rekonvergenz).
• IS-IS: Level-2 bildet meist den Backbone; Level-1 bleibt lokal. Das Design wird oft als geradlinig empfunden, insbesondere bei „alles ist P2P“ in Provider-Topologien.

Für OSPF-Grundlagen ist RFC 2328 (OSPFv2) und für IPv6 RFC 5340 (OSPFv3) relevant. Für IS-IS ist RFC 1195 (Integrated IS-IS) eine wichtige Referenz; die ursprüngliche Spezifikation basiert zudem auf ISO/IEC 10589 (häufig als „IS-IS“ referenziert).

Adressierung und Transport: IP-Protokoll vs. CLNS-Herkunft

OSPF ist „IP-nativ“: es nutzt IP, IP-Multicast und kennt IP-Adressierung als primären Kontext. IS-IS stammt aus dem OSI/CLNS-Kontext, wird im IP-Netz als „Integrated IS-IS“ betrieben und trägt IP-Präfixe in TLVs innerhalb der IS-IS-LSPs. Operativ ergeben sich daraus zwei typische Unterschiede:

• OSPF: Interface-IP und OSPF-Adjazenz sind eng gekoppelt; Fehlkonfigurationen in IP/MTU/Multicast wirken direkt auf OSPF.
• IS-IS: Adjazenzen laufen oft „IP-unabhängiger“ über Layer 2 (auf P2P), was in Provider-Designs als robust empfunden wird; IP-Präfixe sind „Payload“ in TLVs.

Wichtig: Beide Protokolle haben MTU- und Paketgrößen-Themen (z. B. Fragmentierung von OSPF-LSAs bzw. IS-IS LSPs, oder Drops bei zu großen Control-Paketen). Im Backbone wird das meist durch saubere MTU-Standards und konsequente P2P-Designs entschärft.

Operativer Alltag: Typische NOC-Fragen und wie sich OSPF/IS-IS unterscheiden

Im ISP-Backbone zählt nicht nur „kann das Protokoll X“, sondern „wie schnell verstehe ich, was passiert, wenn es brennt“. Die häufigsten operativen Fragen sind:

• Warum flapped die Adjazenz? (Timer, MTU, CPU, Paketverlust, LAG-Mitglieder, Optical Errors)
• Warum ist die Route nicht im RIB/FIB? (Policy/Redistribution, Level/Area-Grenze, fehlende TLVs/LSAs, Summarization)
• Warum konvergiert das Netz langsam? (Flooding, SPF-Throttling, LSA/LSP-Stürme, Overload, BFD-Interaktion)
• Warum ist der Pfad suboptimal? (Kostenmodell, ECMP, TE-Extensions, SR-Metriken)

Hier ist der operative Trend: IS-IS wird häufig als „einfacher zu standardisieren“ erlebt (insbesondere in homogenen Provider-Topologien mit Level-2-Backbone und Level-1 am Rand). OSPF ist oft leichter zugänglich, weil viele Teams OSPF aus Enterprise-Kontexten kennen, aber im großen Backbone können Area-Design und LSA-Typen eine höhere Komplexität im Incident erzeugen.

Konvergenz: Was wirklich Zeit kostet

Konvergenz ist nicht „ein Timer“, sondern eine Kette. In ISP-Backbones lohnt es sich, diese Kette messbar zu machen, damit RCAs nicht im Vagen bleiben.

Vereinfachtes Konvergenzmodell (MathML)

$T\_\mathrm{conv}=T\_\mathrm{detect}+T\_\mathrm{flood}+T\_\mathrm{spf}+T\_\mathrm{fib}$

• T_detect: Link-Down/Signal-Loss, BFD, LACP, IGP-Hellos/Dead.
• T_flood: wie schnell LSA/LSPs im relevanten Flooding-Bereich ankommen.
• T_spf: SPF-Laufzeit plus SPF-Throttling (um CPU-Spikes zu vermeiden).
• T_fib: Programmierung der Forwarding-Tabellen im ASIC/Linecard.

IS-IS und OSPF unterscheiden sich hier weniger in der Mathematik als in praktischen Defaults, Telemetrie und dem „typischen Tuning-Profil“. In großen Netzen entscheidet häufig das Zusammenspiel aus Flooding-Stürmen und SPF-Throttling über die wahrgenommene Stabilität.

Fast Reroute und Loop-Free Alternates: Betriebssicht

Für Provider ist schnelle Wiederherstellung oft Pflicht. Beide Protokolle unterstützen LFA-Mechanismen; ein verbreiteter Standard dafür ist RFC 5286. Operativ ist wichtig:

• LFA ist nicht automatisch überall möglich: Topologie und Metrikdesign bestimmen, ob ein loopfreier Alternativpfad existiert.
• Validation ist Pflicht: nach Changes sollten Sie prüfen, ob LFA-Abdeckung (Coverage) stabil bleibt, sonst droht ein „Second Outage“ beim nächsten Link-Fail.
• SR/TE-Interaktion: Wenn Segment Routing oder TE genutzt wird, verändern sich Metrik- und Pfadentscheidungen; das muss in die Konvergenztests einfließen.

Skalierung und Stabilität: LSA/LSP-Stürme, SPF-Throttling und Flooding-Domänen

In ISP-Backbones ist „Stabilität“ oft wichtiger als „maximal schnell“. Zu aggressive Timer oder unkontrolliertes Flooding können die Control Plane in einen selbstverstärkenden Zustand bringen: Flaps erzeugen Flooding, Flooding erzeugt CPU-Spikes, CPU-Spikes erzeugen weitere Flaps.

• OSPF: LSA-Fluten kann in großen Areas spürbar werden; sauberes Area-Design und Summarization helfen, aber erhöhen die Design-Disziplin.
• IS-IS: TLV-basierte Erweiterbarkeit ist in Provider-Ökosystemen stark; viele Erweiterungen (z. B. TE) sind in IS-IS sehr verbreitet, was die Tooling-Landschaft im NOC oft begünstigt.

Für TE-Extensions im IS-IS-Kontext ist RFC 5305 und für IPv6-TE RFC 6119 eine nützliche Referenz. Für IS-IS IPv6-Erweiterungen ist RFC 5308 relevant.

Sicherheits- und Abuse-Aspekte: Control Plane als Angriffsfläche

Provider-Backbones sind nicht nur technisch, sondern auch operativ exponiert. Beide Protokolle sollten geschützt werden: Authentifizierung, klare Interface-Scopes, Control Plane Policing und Monitoring von Adjazenzflaps. OSPF und IS-IS bieten Authentifizierungsoptionen; wichtig ist hier weniger das Feature, sondern die konsequente Standardisierung im Netz.

• Adjazenz-Scopes: IGP nur auf Backbone-Interfaces aktiv, nie „versehentlich“ im Access.
• Filtering/Protection: Control-Plane-Traffic priorisieren und limitieren, um CPU-Spikes bei Stürmen zu verhindern.
• Drift-Detection: Abweichungen von Standard-Timern und Auth-Settings früh erkennen.

Operations: Troubleshooting-Playbooks im Vergleich

In der Praxis sind die Playbooks wichtiger als das Protokoll. Trotzdem gibt es Unterschiede in typischen Diagnosewegen.

OSPF-typische Diagnoseanker

• Area-Check: stimmt Area-Zuordnung, ist Backbone-Konnektivität konsistent?
• LSA-Typen: sind die erwarteten LSAs vorhanden (Router/Network/Summary/External)?
• DR/BDR-Effekte: auf Broadcast-Segmenten kann DR-Wahl Fehlerbilder beeinflussen; im Backbone wird oft P2P bevorzugt, um das zu minimieren.

IS-IS-typische Diagnoseanker

• Level-Scope: ist das Interface L1/L2 korrekt, sind L2-Domänen sauber definiert?
• Overload/Att bits: wird ein Knoten „überlastet“ signalisiert und dadurch aus Pfaden genommen?
• TLV-Payload: sind die relevanten Präfix-TLVs vorhanden (IPv4/IPv6), passen TE-TLVs zu Erwartungen?

Konvergenz in der Praxis messen: Welche Metriken im NOC wirklich helfen

Ein operativer Vergleich ist unvollständig ohne Messbarkeit. Unabhängig von OSPF oder IS-IS sollten Sie Konvergenz und Stabilität über wenige, robuste Signale monitoren:

• Adjacency Flaps: Anzahl und Häufigkeit pro Interface/Router.
• IGP Flooding Events: Rate von LSA/LSP-Updates; Spikes sind Frühindikatoren.
• SPF Runs: Häufigkeit und Dauer; ungewöhnliche Peaks deuten auf Instabilität.
• Traffic Impact: Loss/Latency auf kritischen Pfaden während Ereignissen (synthetische Probes).
• Fast Reroute: Coverage und tatsächliche Umschaltzeiten bei Link-Fails.

Wann IS-IS im ISP-Backbone häufig die bessere Wahl ist

• Homogene Provider-Topologie: viele P2P-Links, klare Backbone-Hierarchie, konsequente Standardisierung.
• Skalierungsfokus: große Netze mit vielen Präfixen/Interfaces, in denen TLV-basierte Erweiterbarkeit und Provider-Tooling besonders gut passen.
• Konvergenz-Engineering: starke Nutzung von TE/SR/FRR-Mechanismen, die im IS-IS-Ökosystem sehr verbreitet sind.

Wann OSPF im ISP-Backbone häufig die bessere Wahl ist

• Team- und Prozessrealität: hohe OSPF-Expertise vorhanden, klare Area-Standards sind etabliert.
• Abgrenzbare Domänen: wenn Area-Design sauber und stabil gehalten werden kann (z. B. regional, klar hierarchisch).
• Interoperabilität/Know-how: in Mischumgebungen, in denen OSPF-Skills breiter vorhanden sind und standardisierte Templates existieren.

Minimaltests nach IGP-Changes: „All Clear“ im Backbone

Unabhängig vom Protokoll sollten Provider nach IGP-Changes ein kurzes, festes Validierungsset fahren. Das reduziert Second-Outage-Risiko erheblich.

• Adjazenzen stabil: keine Flaps im Beobachtungsfenster, alle erwarteten Nachbarn up.
• SPF-/Update-Raten normal: keine anhaltenden Flooding-Spikes.
• Pfadkonsistenz: kritische Präfixe nehmen erwartete ECMP-Pfade, keine unerwarteten Umwege.
• Konvergenztest: kontrollierter Link-Fail (wenn möglich im Lab oder Maintenance-Slot) und Messung von Loss/Latency.
• FRR/LFA Coverage: bleibt im erwarteten Band, keine plötzlichen Lücken.

Outbound-Ressourcen

• RFC 2328 (OSPFv2)
• RFC 5340 (OSPFv3)
• RFC 1195 (Integrated IS-IS)
• RFC 5308 (IS-IS für IPv6)
• RFC 5305 (IS-IS Traffic Engineering Extensions)
• RFC 5286 (Basic Specification for Loop-Free Alternates)
• IEEE 802.1Q (Bridging/VLAN-Kontext, relevant für Backbone-Edge und L2-Interaktionen)

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.