IS-IS Design Guide: Level-1/2, Areas und Best Practices

Ein IS-IS Design Guide hilft dabei, ein Provider- oder Enterprise-Core-Netz stabil, skalierbar und betriebssicher aufzubauen. IS-IS (Intermediate System to Intermediate System) ist in Telco-Backbones besonders verbreitet, weil es sich gut für hierarchische Topologien eignet und in großen Netzen über Jahre hinweg zuverlässig skaliert – vorausgesetzt, das Design ist diszipliniert. Der entscheidende Punkt: IS-IS ist nicht einfach „OSPF mit anderem Namen“, sondern bringt ein eigenes Hierarchiemodell mit Level-1 und Level-2, eine andere Art der Area-Strukturierung und typische Best Practices, die im Betrieb den Unterschied zwischen ruhigem Backbone und häufigen Control-Plane-Problemen ausmachen. Wer IS-IS plant, sollte deshalb nicht nur Adjacencies „zum Laufen bringen“, sondern klare Regeln definieren: Welche Router sind L2-only, welche Regionen sind L1, wo sitzen L1/L2-Router, wie wird adressiert, wie werden Metriken gesetzt, und wie werden Fehlerdomänen begrenzt? Dieser Artikel erklärt IS-IS Level-1/2, Areas und bewährte Best Practices so, dass Einsteiger das Grundprinzip verstehen, Fortgeschrittene ein sauberes Referenzdesign ableiten können und Profis eine strukturierte Checkliste für Audit und Modernisierung erhalten.

Rolle von IS-IS im Netzwerkdesign

In modernen Provider-Netzen übernimmt IS-IS typischerweise die Aufgabe des IGP im Core: Es transportiert Infrastruktur-Erreichbarkeit – also Loopbacks, Core-Links, Router-Identitäten und ggf. zusätzliche Topologieinformationen für Traffic Engineering oder Segment Routing. Services und Kundenrouten (Internet, VPNv4/VPNv6, EVPN) gehören hingegen in der Regel zu BGP. Ein schlankes IGP ist ein Kernprinzip: Je weniger „unnötige“ Präfixe und Sonderfälle im IS-IS landen, desto stabiler bleibt die Control Plane unter Last, Failover und Wachstum.

• IGP für Infrastruktur: Loopbacks, Transit-Links, stabile Erreichbarkeit für iBGP, RR und MPLS/SR.
• BGP für Services: Internet-Routen, VPNs, Policies, Mandantenlogik und Interconnect-Steuerung.
• Ziel: schnelle, stabile Konvergenz und planbare Pfade mit ECMP.

IS-IS Grundbegriffe: Levels, Areas und Router-Rollen

IS-IS ist hierarchisch aufgebaut. Statt OSPF-Areas gibt es in IS-IS Levels: Level-1 (L1) für intra-area Routing und Level-2 (L2) für Backbone-Routing zwischen Areas. Eine IS-IS „Area“ ist dabei ein logischer Bereich, der über einen gemeinsamen Area-Identifier definiert wird. Router können als L1, L2 oder L1/L2 arbeiten. L1/L2-Router verbinden L1-Areas mit dem L2-Backbone – sie sind konzeptionell vergleichbar mit Area Border Routern, aber im IS-IS-eigenen Modell.

• Level-1: Routing innerhalb einer Area (regional/clusterartig).
• Level-2: Backbone-Routing zwischen Areas (überregional/national/international).
• L1/L2-Router: Übergang zwischen L1 und L2, zentrale Knoten für Hierarchie und Stabilität.
• Area: Logischer Verbund, in dem L1-Routing stattfindet; L2 verbindet mehrere Areas.

Hierarchie-Design: Wann L2-only, wann L1/L2, wann L1?

Die wichtigste Designentscheidung ist die Hierarchie. In Provider-Backbones ist ein häufiges Muster: Der Core ist Level-2-only, Regionen oder Metro-Cluster sind Level-1, und an definierten PoPs sitzen L1/L2-Router, die Regionen an den Backbone anbinden. Dieses Modell begrenzt die Auswirkung regionaler Instabilität, hält L2 sauber und macht Wachstum planbar.

Pattern: L2-only Core (Backbone) als Standard

• Einsatz: Nationaler/überregionaler Backbone mit hoher Kapazität und hoher Stabilitätsanforderung.
• Vorteil: Schlankes L2, klarer Transportfokus, gute Skalierbarkeit.
• Best Practice: Keine unnötigen Präfixe, konsistente Metriken, klare Failure Domains.

Pattern: L1 Regionen (Metro/Regional) mit L1/L2-Übergang

• Einsatz: Metro-Ringe, regionale Aggregationsnetze, viele Access-Uplinks.
• Vorteil: Regionale LSA/Update-Last bleibt lokal, Backbone bleibt ruhig.
• Best Practice: L1-Topologie modular halten, große Ringe vermeiden, klare PoP-Grenzen.

Pattern: L1/L2-Router als kontrollierte Gateways

• Einsatz: PoPs, an denen regionale Netze an den Backbone gekoppelt werden.
• Vorteil: Klare Übergabe, gezielte Kontrolle über Route-Leaking und Default-Routen.
• Risiko: Werden L1/L2-Router überlastet oder falsch platziert, werden sie zu Engpässen oder Failure Concentrators.

Area-Design in IS-IS: Struktur, Größe und praktische Leitplanken

Auch wenn IS-IS „Areas“ anders behandelt als OSPF, gilt das gleiche Ziel: Fehlerdomänen begrenzen und Wachstum planbar machen. Eine IS-IS-Area (für L1) sollte so geschnitten sein, dass Instabilität, Flaps und Topologieänderungen nicht das ganze Landnetz betreffen. In der Praxis sind Areas häufig entlang geografischer Regionen, Metro-Bereiche oder organisatorischer Zuständigkeiten aufgebaut.

• Regionale Areas: L1-Area pro Metro-Region oder pro Cluster von PoPs.
• Begrenzte Größe: Lieber mehrere kleinere L1-Areas als eine riesige Area, die alle Flaps schluckt.
• Klare Übergänge: L1/L2-Router nur an definierten PoPs, nicht „überall ein bisschen“.
• Failure Domains: Areas so schneiden, dass typische Ausfälle (Trasse, Stadt, PoP) lokal bleiben.

Adressierung und Identitäten: Systematische Planung für Operabilität

IS-IS ist im Betrieb dann angenehm, wenn Identitäten und Adressierung sauber strukturiert sind. Auch wenn die konkrete Identifier-Form je nach Plattform variiert, ist das Ziel immer gleich: Router-Identitäten müssen eindeutig, konsistent und in der Dokumentation leicht auffindbar sein. Loopbacks sollten als stabile Identität dienen, und Link-Subnetze sollten so geplant sein, dass sie Fehleranalyse und Automatisierung unterstützen.

• Loopback-First: Pro Router stabile Loopbacks als primäre Identität für iBGP, RR und Management.
• Hierarchische IP-Pläne: Region/PoP/Rolle in der Adressierung erkennbar machen.
• Transit-Subnets standardisieren: Konsistente Subnetzgrößen, klare Interface-Beschreibungen, saubere Dokumentation.
• IPv6-Readiness: Dual-Stack nicht „nebenbei“, sondern mit konsistenten Standards betreiben.

Metrik-Design: ECMP planen statt „Zufallspfade“ akzeptieren

In Provider-Backbones ist ECMP ein zentraler Hebel für Kapazitätsnutzung und Resilienz. Damit ECMP erwartbar funktioniert, müssen Metriken konsistent gesetzt werden. Ein typischer Fehler ist historisch gewachsenes Metrik-Chaos: Links werden über die Zeit verändert, ohne das Gesamtbild zu prüfen. Ergebnis sind überraschende Pfade und Hotspots. Best Practice ist ein Metrik-Modell, das die physische Kapazität, gewünschte Pfade und Failure Domains widerspiegelt.

• Kapazitätsbewusstsein: Höhere Kapazität erhält niedrigere Kosten, wenn das Modell das abbilden soll.
• ECMP-Planung: Parallele Pfade bewusst gleichwertig machen, statt zufällige Ungleichgewichte zu erzeugen.
• Hotspot-Vermeidung: Metriken so setzen, dass kritische Korridore nicht ungewollt überlastet werden.
• Änderungsdisziplin: Metrik-Änderungen wie Backbone-Changes behandeln: testen, messen, dokumentieren.

Konvergenz und Stabilität: Failover schnell, aber nicht nervös

IS-IS kann sehr schnell rekonvergieren, wenn das Underlay stabil ist. In der Praxis ist die größte Gefahr nicht „zu langsam“, sondern „zu nervös“: Link-Flaps, Paketverlust oder instabile Optiken führen zu häufigen Topologieänderungen und SPF-Läufen. Daher sollten Sie Konvergenz als Zusammenspiel aus Fehlererkennung, Rekonvergenz und Flap-Management betrachten. Ein robustes Design definiert Failure Models, misst Umschaltzeiten und setzt Prozesse für Wartung und Entstörung auf.

• Failure Models definieren: Link-, Node-, PoP- und Trassenereignisse getrennt betrachten.
• Flap-Management: Wiederholte Kurzstörungen dämpfen, Root Cause priorisieren (Physik zuerst).
• Wartungsvorgehen: Traffic bewusst umleiten, bevor Links oder Knoten aus dem Verkehr genommen werden.
• Messung: Konvergenzzeiten und Service-Impact regelmäßig testen und dokumentieren.

Route Leaking zwischen Level-1 und Level-2: bewusst, minimal, standardisiert

Ein kritisches Thema im IS-IS-Design ist die Frage, wie L1 und L2 miteinander verbunden werden. In vielen Designs erhalten L1-Router eine Default-Route Richtung L2, statt alle L2-Routen in L1 zu leaken. Das hält L1 schlank und reduziert die Update-Last. Wenn Route-Leaking notwendig ist (z. B. für spezielle Erreichbarkeiten), sollte es strikt standardisiert sein: wenige, klar definierte Präfixe, dokumentierte Policies und Schutzmechanismen.

• Default statt Vollrouting: In L1 häufig Default nach L2, um Skalierung zu verbessern.
• Gezieltes Leaking: Nur notwendige Routen leaken (z. B. bestimmte Service-/PoP-Präfixe), nicht „alles“.
• Dokumentation: Leaking-Regeln müssen nachvollziehbar sein, sonst entstehen unerwartete Pfade.
• Testing: Leaking-Änderungen immer mit Failover- und Pfadtests validieren.

IS-IS und Segment Routing: Underlay als Basis für moderne Telco-Architekturen

Viele Provider nutzen IS-IS als Underlay-Basis für moderne Transportmechanismen wie Segment Routing. Unabhängig davon, ob Sie heute SR nutzen oder nicht, lohnt es sich, das IS-IS-Design „SR-ready“ zu gestalten: konsistente Metriken, saubere Loopbacks, klare Hierarchie und starke Observability. So bleibt die Architektur erweiterbar, ohne dass später ein komplettes Underlay-Redesign nötig wird.

• Stabile Topologie: SR profitiert von vorhersehbaren Pfaden und konsistenten Metriken.
• Klare Identitäten: Loopbacks und Router-IDs müssen sauber geplant sein.
• Failure Domains: SR-Policies wirken nur gut, wenn die darunterliegende Domain-Trennung sauber ist.

Security und Control Plane Protection: Underlay schützen

Ein Provider-Core ist ein Hochwertziel. IS-IS selbst sollte daher nicht „offen“ über unsichere Bereiche laufen. Praktisch bedeutet das: IS-IS nur auf dedizierten Core-Links, klare Interface-Härtung, Schutz gegen unerwünschte Nachbarn, sowie strikte Trennung von Management und Nutztraffic. Ein weiterer wichtiger Punkt ist Change-Governance: Control-Plane-Änderungen wirken schnell großflächig, daher müssen Reviews und automatisierte Checks Standard sein.

• IGP nur auf Core-Interfaces: Keine unnötige IGP-Adjacency auf kundennahen Ports.
• Interface-Härtung: Unnötige Protokolle deaktivieren, klare Baselines, restriktive Zugangsregeln.
• Management-Segmentierung: Separates Managementnetz, RBAC/MFA, Audit-Logging.
• Change-Prozesse: Gestaffelte Rollouts, Peer-Reviews, Rollback-Pläne.

Observability: Was Sie im IS-IS-Betrieb konsequent überwachen sollten

IS-IS ist im Betrieb dann angenehm, wenn Sie die richtigen Signale sehen: Adjacency-Stabilität, Topologieänderungen, SPF-Läufe, Link-Flaps, Paketverlust und Latenz auf kritischen Strecken. Besonders wichtig ist Event-Korrelation: Wenn ein Link flappt, sollten Sie zeitgleich sehen, welche IS-IS-Events daraus folgen und wie sich das auf iBGP/BGP-Services auswirkt. So wird aus „Routing ist komisch“ eine schnelle, faktengestützte Ursachenanalyse.

• Adjacencies: Up/Down-Events, Flap-Häufigkeit, Nachbarschaftszeiten, Paketverlustindikatoren.
• SPF-Events: Häufigkeit, Dauer, Trigger – ungewöhnliche Häufungen sind Warnsignale.
• Link-Telemetrie: Errors/Drops, Optikwerte, MTU-Probleme, Mikro-Flaps.
• End-to-End: Korrelation zu BGP-Instabilität, Traffic-Anomalien und Kundenbeschwerden.

Typische Stolperfallen im IS-IS Design und wie Sie sie vermeiden

Die meisten IS-IS-Probleme entstehen durch fehlende Leitplanken: zu große L1-Domänen, unkontrolliertes Leaking, inkonsistente Metriken, instabile Links oder fehlende Observability. Ein sauberes Design hält das Underlay „langweilig“: wenige Präfixe, klare Hierarchie, stabile Physik, konsistente Templates. Das führt zu weniger Rekonvergenz und zu deutlich einfacherem Betrieb.

• Zu große L1-Areas: Regionale Instabilität wirkt zu weit, SPF-Last steigt.
• Unkontrolliertes Leaking: L1 wird „vollgeroutet“, Control Plane wird unnötig belastet.
• Metrik-Wildwuchs: Pfade werden unvorhersehbar, Hotspots entstehen.
• Physische Instabilität ignoriert: Flaps und Optikprobleme treiben IS-IS-Events unabhängig von Protokoll-Tuning.
• Keine Standards: Unterschiedliche Baselines pro Router führen zu schwer reproduzierbaren Fehlerbildern.

Operative Checkliste: IS-IS Level-1/2 und Best Practices umsetzen

Diese Checkliste hilft, ein IS-IS-Design aufzubauen oder ein bestehendes Netz zu auditieren. Sie fokussiert die Punkte, die in großen Provider-Netzen am häufigsten über Stabilität und Skalierung entscheiden.

• Ist IS-IS auf Infrastruktur begrenzt (Loopbacks, Core-Links) und sind Kunden-/Service-Routen außerhalb des IGP?
• Ist die Hierarchie sauber definiert (L2-only Core, L1 Regionen, L1/L2-Gateways) und sind Grenzen dokumentiert?
• Sind L1-Domänen bewusst klein und modular, um Fehlerdomänen und Topologieänderungen lokal zu halten?
• Ist Route-Leaking zwischen L1/L2 minimal, standardisiert und getestet (Default statt Vollrouting, wenn möglich)?
• Sind Metriken konsistent und unterstützt das Design ECMP sowie planbare Pfadwahl und Hotspot-Vermeidung?
• Sind Failure Models definiert, N-1-Headroom eingeplant und Konvergenztests regelmäßig durchgeführt?
• Ist Security umgesetzt (IGP nur auf Core-Links, Management-Segmentierung, Control-Plane-Schutz, Change-Governance)?
• Ist Observability vollständig (Adjacency-Flaps, SPF-Events, Link-Telemetrie, Event-Korrelation) und sind Runbooks vorhanden?
• Gibt es Standards und Automatisierung (Golden Configs, Templates, Drift-Erkennung, Pre-/Post-Checks)?

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.