Site icon bintorosoft.com

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

Red Snapper

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.

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

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:

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:

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_conv = T_detect + T_flood + T_spf + T_fib

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:

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.

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.

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

IS-IS-typische Diagnoseanker

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:

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

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

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.

Outbound-Ressourcen

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:

Lieferumfang:

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.

 

Exit mobile version