IGP Design: OSPF vs. IS-IS in Telco Backbones ist eine der zentralen Architekturentscheidungen im Carrier-Umfeld, weil das Interior Gateway Protocol (IGP) die Stabilität, Konvergenz und Skalierbarkeit des gesamten Transportnetzes mitbestimmt. Im Backbone gilt: Der Core soll „langweilig“ sein – vorhersehbare Pfade, klare Failure Domains, robuste Wiederherstellung und möglichst wenig Kontrollplan-Überraschungen. Genau dafür ist das IGP da: Es verteilt Topologieinformationen, berechnet Kürzestpfade und liefert die Basis für MPLS/SR, Traffic Engineering, Fast Reroute und zuverlässige Multi-Region-Konnektivität. OSPF und IS-IS können beide Carrier-Grade Netze tragen, unterscheiden sich aber in Domänenmodell, Adressierungs- und Erweiterungslogik, Betriebsgewohnheiten und in typischen Skalierungs-Patterns. In der Praxis ist die „richtige“ Wahl selten eine reine Featurefrage – sie hängt von Topologie, Organisationsstruktur, Migrationspfaden, Telemetry-Ansprüchen und der Frage ab, wie stark Sie Hierarchien und Summarization nutzen wollen. Dieser Expertenvergleich erklärt verständlich, worin OSPF und IS-IS sich in Telco-Backbones unterscheiden, welche Designhebel wirklich zählen und wie Sie ein IGP so bauen, dass es Wachstum, Segment Routing und Betriebskosten gleichermaßen unterstützt.
Was ein IGP im Telco-Backbone leisten muss
Bevor man OSPF und IS-IS vergleicht, lohnt sich ein Blick auf die Anforderungen. In Carrier-Backbones ist ein IGP nicht „einfach Routing“, sondern die Grundlage für deterministische Pfade, schnelle Wiederherstellung, stabile ECMP-Lastverteilung und – in vielen Netzen – das Underlay für MPLS oder Segment Routing. Ein gutes IGP Design minimiert Kontrollplan-Last und begrenzt die Ausbreitung von Änderungen.
- Stabile Topologieverteilung: Änderungen müssen schnell, aber ohne Flapping und Kontrollplan-Stürme verteilt werden.
- Vorhersehbare Pfadwahl: Konsistente Metriken und klare TE-/Policy-Leitplanken.
- Skalierung: Viele Knoten und Links, ohne dass LSDB/State explodiert.
- Fast Convergence: Wiederherstellung in definierten Grenzen (Zeit, Loss, Latenzsprung).
- Unterstützung für MPLS/SR: IGP als zuverlässige Basis für Label-/SID-Verteilung und TE-Use-Cases.
- Operationalisierung: Messbarkeit, Alarmkorrelation und klare Failure Domains.
Das wichtigste Ziel: Kontrollplan-Komplexität begrenzen
In großen Telco-Netzen sind „Kontrollplan-Überraschungen“ teuer. Ein IGP-Design ist dann gut, wenn es sich auch im Fehlerfall erklären lässt: Warum ist der Pfad gewechselt? Warum ist ECMP so verteilt? Warum gibt es eine Konvergenzwelle? Diese Fragen müssen ohne Spezialwissen beantwortbar sein.
OSPF und IS-IS: Gemeinsamkeiten und fundamentale Unterschiede
OSPF und IS-IS sind beide Link-State-Protokolle. Beide bauen eine Datenbank der Topologie auf und berechnen darauf basierend kürzeste Pfade. Beide unterstützen Hierarchie, ECMP und Erweiterungen. Die Unterschiede liegen weniger im „Können“, sondern im Modell: wie Hierarchie abgebildet wird, wie Erweiterungen integriert werden, welche Betriebsgewohnheiten sich etabliert haben und wie sich das Ganze in großen Domains anfühlt.
- Link-State Prinzip: Beide verteilen Zustandsinformationen über Links/Knoten und rechnen SPF.
- Hierarchiefähigkeit: OSPF mit Areas (Backbone-Area), IS-IS mit Levels (L1/L2).
- ECMP: Beide unterstützen mehrere gleichwertige Pfade.
- TE/SR-Erweiterungen: Beide können als Basis für Traffic Engineering und Segment Routing dienen.
Die wichtigste Differenz im Telco-Alltag: Domänenmodell und „Operational Feel“
OSPF wird häufig in Enterprise-Umgebungen eingesetzt und bringt ein sehr klares Area-Konzept mit. IS-IS ist historisch stark im Service-Provider-Backbone verankert und wird oft als besonders „backbone-freundlich“ wahrgenommen, weil das Level-Konzept sehr gut zur Core/Region-Struktur passt und Erweiterungen über TLVs flexibel integriert werden. Beide Wahrnehmungen sind nicht absolut, aber sie prägen Praxisentscheidungen.
Hierarchie: OSPF Areas vs. IS-IS Levels im Backbone
Hierarchie ist im Telco-Backbone entscheidend, um Skalierung und Stabilität zu erreichen. Sie bestimmt, wie viel Detail ein Knoten sehen muss und wie weit sich Änderungen ausbreiten. OSPF strukturiert über Areas, IS-IS über Level-1 und Level-2 (häufig: L2 im Core, L1 in regionalen Bereichen). Beide Modelle können ähnliche Zielbilder umsetzen, aber die Designentscheidungen fühlen sich unterschiedlich an.
- OSPF: Area-Backbone-Konzept mit Area 0 als Kern. Nicht-Backbone-Areas hängen logisch am Backbone.
- IS-IS: L2 bildet oft den Backbone, L1 die Regionen; L1/L2-Router verbinden Ebenen.
- Gemeinsames Ziel: Detailänderungen regional halten, Core stabil halten, klare Übergänge schaffen.
Praktische Telco-Pattern
- OSPF Pattern: Core als Area 0, Metro-Regionen als separate Areas; Summarization an ABRs, klare Area-Policies.
- IS-IS Pattern: Backbone als Level-2 Domain, Regionen als L1; L1/L2-Gateways an Metro-Edges.
Summarization und Topologie: Warum IGP-Design und IP-Plan zusammengehören
Hierarchisches Routing funktioniert nur, wenn Adressierung aggregierbar ist. Summarization reduziert Routing-State und begrenzt Flaps, kann aber Blackholes verursachen, wenn sie nicht zur Topologie passt. In Telco-Netzen wird Summarization typischerweise an klaren Aggregationspunkten umgesetzt: Metro-Edges, Cluster-Gateways, PoP-Kanten. Das gilt unabhängig davon, ob OSPF oder IS-IS verwendet wird – aber die praktische Umsetzung und die „Gefühlssicherheit“ unterscheiden sich je nach Modell und Teamgewohnheit.
- Adress-Hierarchie: Region → Cluster → Standort → Rolle erzeugt natürliche Summary-Blöcke.
- Summary-Punkte: Übergänge zwischen Ebenen (Access/Metro/Core) sind natürliche Orte für Aggregation.
- Blackhole-Vermeidung: Summaries nur dort, wo Detailreachability vollständig gegeben ist.
- Störfalltests: Summaries müssen auch im Failover korrekt funktionieren.
Die Blueprints-Logik: Wenige Domänentypen, viele Wiederholungen
Ein IGP skaliert am besten, wenn es nur wenige Domain/Area/Level-Muster gibt, die überall gleich funktionieren. Jede Sonderarea, jede Sondermetric, jede Ausnahme erhöht den Zustandsraum und macht Konvergenz schwerer vorhersagbar.
Konvergenz und Stabilität: Timer, Erkennung und Flap-Kontrolle
Telco-Backbones brauchen schnelle Wiederherstellung, aber ohne Instabilität. Konvergenz besteht aus Erkennung (wie schnell wird ein Fehler erkannt), Verteilung (wie schnell wird die Änderung propagiert), SPF-Berechnung (wie schnell wird neu gerechnet) und Forwarding-Umschaltung (wie schnell wird tatsächlich umgeschaltet). OSPF und IS-IS können beide schnell konvergieren, aber das Design entscheidet, ob das in der Praxis stabil bleibt.
- Fehlererkennung: Link-Down, optische Fehler, Health-Mechanismen; robuste Erkennung ist wichtiger als „aggressive Timer“.
- SPF-Steuerung: SPF-Throttling/Hysterese verhindert Konvergenzstürme bei Flapping.
- LSA/LSP-Flutkontrolle: Update-Stürme müssen beherrschbar bleiben, besonders in großen Domains.
- Wartungsfähigkeit: Planned Maintenance soll planbare Pfadänderungen erzeugen, nicht chaotische Flaps.
Konvergenz messen statt raten
Carrier-Grade IGP-Design ist messbar: Zeit bis Pfadwechsel, Paketverlust während Umschaltung, Latenzsprung, Queue-Drops im Störfall. Ohne Telemetry bleibt Konvergenz eine Annahme, was in SLA- und Audit-Kontexten problematisch ist.
IGP als Basis für MPLS und Segment Routing: Was im Design zählt
In Telco-Backbones ist das IGP oft das Underlay für MPLS, SR-MPLS oder SRv6. Damit wird IGP-Design zu einem Topologie-Tool: Es bestimmt, wie Node-IDs/Loopbacks verteilt werden, wie ECMP-Pfade entstehen und wie zuverlässig Transportpfade bleiben. SR-Design braucht eine stabile IGP-Basis: konsistente Metriken, klare Domänengrenzen, stabile Flooding-Mechanik und eine saubere Adress-/ID-Strategie.
- Loopbacks/Node-IDs: Konsistente, hierarchische Planung hilft bei SRGB/SID-Schemata und Troubleshooting.
- ECMP-Planbarkeit: Gleichwertige Pfade sind im Core normal; Hashing und Pfadkosten müssen stabil sein.
- TE-Informationen: Wenn TE genutzt wird, müssen Linkattribute konsistent gepflegt werden.
- Domänenintegration: Multi-Domain-Designs brauchen klare Border-Patterns, egal ob OSPF oder IS-IS.
Ein häufiges Missverständnis: „IGP ist nur Underlay“
IGP ist die Grundlage für Pfadwahl, und damit indirekt für Servicequalität. Wenn Metrikmodelle schlecht sind oder Domänengrenzen unklar, wird TE/SR kompliziert, und Betrieb wird teuer. Ein gutes IGP-Design ist daher ein Service-Enabler.
Operationalisierung: Troubleshooting, Telemetry und Teamkompetenz
Ein „Expertenvergleich“ ist ohne Betriebsperspektive unvollständig. Die beste Protokollwahl ist die, die Ihr Team sicher betreiben kann – mit klaren Runbooks, konsistenten Konfigurations-Templates, guter Observability und einem Ausnahmeprozess, der Varianten begrenzt. In der Praxis sind Skillsets, Tooling und bestehende Betriebsmodelle häufig entscheidender als einzelne Featureunterschiede.
- Standard-Templates: Einheitliche Rollenmodelle (Core-P, Core-Edge, Metro-Edge) reduzieren Varianten.
- Telemetry: Adjacency-Status, SPF-Events, Update-Raten, CPU/Memory und Path-Change-Events.
- Alarmkorrelation: Failure Domains abbilden (Trasse/PoP/Link) statt Alarmflut pro Router.
- Change-Governance: Versionierung, Reviews, Wellen-Rollouts, Rollback.
Evidence-by-Design: IGP als auditierbarer Baustein
Wenn Sie Changes, Konvergenzzeiten und Pfadwechsel systematisch erfassen, wird IGP-Betrieb auditierbar. Das ist zunehmend wichtig: Kunden, interne Security-Teams und Regulierung erwarten nachvollziehbare Nachweise – nicht nur „es hat funktioniert“.
OSPF im Telco-Backbone: Stärken und typische Einsatzmuster
OSPF ist weit verbreitet, gut dokumentiert und in vielen Toolchains hervorragend unterstützt. In Telco-Backbones wird OSPF häufig dann gewählt, wenn bereits viel OSPF-Kompetenz existiert, wenn Area-Modelle sauber in die Topologie passen oder wenn Migration aus Enterprise-/Regionalnetzen vereinfacht werden soll.
- Stärken: Breite Verfügbarkeit, bekannte Betriebsmodelle, klares Area-Konzept.
- Typische Pattern: Core als Area 0, Regionen als Areas; Summarization an ABRs; klare Policy-Regeln pro Area.
- Wichtige Disziplin: Area-Design konsistent halten, Sonderareas vermeiden, Summaries topologisch korrekt setzen.
OSPF-Falle: Area-Wildwuchs
Wenn OSPF-Areas ohne klare Topologie-Logik entstehen, steigt Komplexität: Sonderfälle bei Inter-Area-Routing, schwer erklärbare Pfade und höhere Change-Risiken. Ein sauberer Blueprint begrenzt die Zahl der Area-Typen und standardisiert Übergänge.
IS-IS im Telco-Backbone: Stärken und typische Einsatzmuster
IS-IS ist im Service-Provider-Bereich traditionell stark und wird häufig für große Backbones gewählt. In vielen Telco-Designs passt das Level-Modell gut zur Hierarchie: L2 als Backbone, L1 als regionale Domänen. Erweiterungen über TLVs gelten in der Praxis als flexibel und „backbone-freundlich“, insbesondere wenn SR/TE-Use-Cases ausgebaut werden.
- Stärken: Sehr gutes Hierarchiemodell für Core/Region, häufig als skalierungsfreundlich wahrgenommen.
- Typische Pattern: L2 im Backbone, Regionen als L1, L1/L2-Gateways an Metro-Edges.
- Wichtige Disziplin: Level-Grenzen sauber halten, konsistente Metriken und klare Summaries.
IS-IS-Falle: „Alles L2“ ohne Struktur
IS-IS kann als flache L2-Domäne betrieben werden, aber in großen Netzen verliert man dann Hierarchie-Vorteile. Carrier-Grade IS-IS-Design nutzt Levels, um Änderungen zu lokalisieren und Kontrollplan-Last zu begrenzen.
Entscheidungskriterien: Wie Sie zwischen OSPF und IS-IS wählen
Für Telco-Backbones ist die Wahl am besten, wenn sie aus Anforderungen und Betriebsfähigkeit abgeleitet wird. Beide Protokolle können funktionieren – entscheidend ist, wie gut das Domänenmodell zu Ihrer Topologie und Governance passt.
- Topologie-Fit: Passt das Area-/Level-Modell natürlich zu Ihrer Core/Metro/Region-Struktur?
- Skalierungsplan: Wie viele Regionen, wie viele Knoten, wie viel Wachstum in 3–5 Jahren?
- SR/TE-Roadmap: Welche SR- und TE-Use-Cases sind geplant, und wie reif ist Observability?
- Teamkompetenz: Welche Skills, Runbooks und Toolchains sind vorhanden?
- Migration: Wie groß ist der Migrationsaufwand, und wie lange muss Koexistenz funktionieren?
- Governance: Können Sie Varianten und Ausnahmen konsequent begrenzen?
Ein pragmatisches Ergebnis: Das Protokoll ist selten der Engpass
In der Praxis scheitern IGP-Projekte häufiger an inkonsistenter Topologie, schlechtem IP-Plan, fehlender Telemetry und zu vielen Ausnahmen als am Protokoll selbst. Wenn Sie Rollenmodelle, Summarization-Blueprints, Konvergenztests und Governance sauber etablieren, können sowohl OSPF als auch IS-IS ein sehr stabiles Telco-Backbone tragen.
Praktische Leitlinien für ein carrier-grade IGP Design
- Hierarchie erzwingen: Areas/Levels als Spiegel der Topologie, nicht als historischer Zufall.
- Metriken standardisieren: Konsistentes Metrikmodell, keine „kreativen“ Ausnahmen ohne Testplan.
- Summarization topologisch korrekt: Summaries an natürlichen Aggregationskanten, Blackholes aktiv verhindern.
- Konvergenz messen: Pfadwechsel, Loss und Latenzsprünge als Standard-KPIs.
- Failure Domains sichtbar machen: Alarmkorrelation nach Trasse/PoP/Region statt Alarmflut pro Router.
- Templates und Policy-as-Code: Versionierung, Reviews, Wellen-Rollouts, Rollback.
- SR/TE nur auf stabilem Underlay: Erst IGP stabilisieren, dann SR/TE skalieren.
