IS-IS auf Cisco: Level-Design, Metrics und Scaling

IS-IS auf Cisco ist in vielen großen Enterprise- und Service-Provider-Netzen die erste Wahl, wenn es um robuste Skalierung, saubere Hierarchien und vorhersehbares Flooding geht. Während OSPF in Campusumgebungen oft „Standard“ ist, punktet IS-IS vor allem dort, wo die Control Plane sehr groß wird: viele Router, viele Links, häufige Topologieänderungen, anspruchsvolle Konvergenzanforderungen und ein Betrieb, der Fehlerdomänen klar kapseln möchte. Der entscheidende Unterschied ist nicht „besser oder schlechter“, sondern das Designmodell: IS-IS arbeitet mit Levels (Level-1, Level-2) statt OSPF-Areas, nutzt TLVs (Type-Length-Value) als erweiterbares Format und ist historisch für große, stabile Routingdomänen optimiert. Auf Cisco IOS/IOS XE und NX-OS lässt sich IS-IS sehr sauber standardisieren, wenn Sie Level-Design, Metric-Strategie und Scaling-Mechanismen bewusst planen: Welche Router sind L1-only, welche L2-only, welche L1/L2? Wo werden Routen geleakt? Wie halten Sie LSP-Fluten klein? Wie bauen Sie ein metrisches Modell, das nicht bei jedem Link-Upgrade „neu erfunden“ werden muss? Dieser Artikel zeigt die wichtigsten Best Practices für IS-IS: ein praxistaugliches Level-Design, sinnvolle Metrics (inklusive Wide Metrics), Skalierungsmechanismen wie Summarization, LSP-Management, Overload-Strategien und schnelle Konvergenz – inklusive typischer Fallstricke und Betriebshinweise, damit IS-IS nicht „mystisch“, sondern planbar wird.

IS-IS in einem Satz: Hierarchie über Levels statt Areas

IS-IS (Intermediate System to Intermediate System) ist ein Link-State-Protokoll wie OSPF: Router tauschen Link-State-Informationen aus, bauen eine Datenbank auf und rechnen per SPF die besten Pfade. Die Hierarchie wird jedoch nicht über viele Areas modelliert, sondern über zwei Levels:

• Level-1 (L1): Innerhalb einer IS-IS-Area (lokale Domäne). Vergleichbar mit „intra-area“ Denken.
• Level-2 (L2): Zwischen Areas, bildet das Backbone. Vergleichbar mit „inter-area/backbone“ Denken.
• Level-1/2 (L1/L2): Router, die beide Welten verbinden und damit die zentrale Aggregationsrolle übernehmen.

Diese einfache Hierarchie ist ein Grund, warum IS-IS in großen Netzen beliebt ist: Sie erhalten eine klare Topologietrennung, ohne eine Vielzahl verschachtelter Area-Designs. Statt „Area 0 muss überall erreichbar sein“ denken Sie in „L2 ist das Backbone, L1 ist lokal“.

TLVs: Warum IS-IS so gut erweiterbar ist

IS-IS nutzt TLVs (Type-Length-Value), um Informationen zu transportieren. Das ist ein großer praktischer Vorteil: Neue Features (IPv6, Traffic Engineering, Segment Routing) lassen sich oft über zusätzliche TLVs integrieren, ohne das Grundprotokoll zu „verbiegen“. Für Betrieb und Troubleshooting bedeutet das: Sie denken häufig in „welche TLVs sind vorhanden und korrekt“, statt in „welche LSA-Typen fehlen“.

• IPv4/IPv6: Werden über entsprechende Reachability-TLVs transportiert (Cisco-Implementierung je nach Feature-Set).
• Traffic Engineering: TE-Informationen laufen über Erweiterungen (z. B. TE-TLVs).
• Scaling: Viele Optimierungen und Erweiterungen sind TLV-basiert und daher vergleichsweise „sauber“ integrierbar.

Als Standardreferenzen sind die klassischen Spezifikationen hilfreich, z. B. RFC 1195 (Integrated IS-IS) sowie für IPv6 RFC 5308 (Routing IPv6 with IS-IS).

Level-Design in der Praxis: Drei robuste Muster

Ein gutes Level-Design reduziert Flooding, kapselt Instabilität und ermöglicht Aggregation. In Cisco-Netzen haben sich drei Muster bewährt, je nach Topologie und Betriebsmodell.

Campus/Enterprise: L1 im Access/Standort, L2 im Core

• Access/Etage: L1-only oder L1 dominiert (geringe LSDB, lokale Instabilität bleibt lokal).
• Distribution: L1/L2 als „Grenzrouter“ (Aggregation, Route Leaking, Policy-Point).
• Core: L2-only oder L2 dominiert (Backbone stabil, wenige Änderungen).

Vorteil: Link-Flaps im Access lösen keinen globalen L2-Flood aus. Nachteil: Sie müssen Route-Leaking und Summarization bewusst planen.

Service-Provider-Style: L2 als Backbone, L1 als Customer/Metro-Domäne

• L2 Backbone: Sehr stabil, strikt kontrolliert, wenige Redistributes.
• L1 Domänen: Viele Edge-Router/PoPs, klare Area-Grenzen, Aggregation am L1/L2-Rand.

Dieses Muster skaliert hervorragend, wenn Sie viele Knoten in „regionalen Inseln“ haben, die nur über das Backbone miteinander sprechen müssen.

Single-Level (nur L2): Einfach, aber weniger kapselnd

In kleineren bis mittleren Netzen kann ein reines L2-Design (alle Router L2) funktionieren. Es ist betrieblich simpel, aber jede Instabilität wirkt globaler. Sobald die LSDB oder Änderungsrate steigt, wird ein zweistufiges Level-Design meist überlegen.

L1/L2-Router richtig einsetzen: Route Leaking, Default und „Backbone-Logik“

Der L1/L2-Router ist das Herz jeder zweistufigen IS-IS-Architektur. Er verbindet L1 und L2 und entscheidet, wie Routen zwischen den Levels sichtbar werden. Hier entstehen die meisten Designfehler, weil man „einfach alles leakt“. Besser ist ein klares Regelwerk:

• L1 bekommt typischerweise eine Default-Route Richtung L2: Damit bleibt L1 schlank und muss nicht das gesamte Backbone kennen.
• L2 sieht aggregierte L1-Präfixe: Statt hunderter spezifischer Netze pro Standort werden Summaries ins L2 propagiert.
• Selective Leaking: Nur notwendige Services (z. B. Shared Services, zentrale DC-Netze) werden granular geleakt, alles andere per Summary oder Default.

Die wichtigste Betriebsregel lautet: L1 soll stabil und klein bleiben. Wenn L1 die komplette Welt kennt, haben Sie das Skalierungsziel des Level-Designs verfehlt.

Metrics: Warum Wide Metrics fast immer Pflicht sind

IS-IS-Metriken steuern Pfadwahl. Historisch gab es „narrow metrics“ (begrenzter Wertebereich), in modernen Designs sind wide metrics Standard, weil sie genügend Auflösung bieten und besser zu heutigen Bandbreiten (1G/10G/100G) passen. Mit zu groben Metriken entstehen Pfadentscheidungen, die nicht zu Ihrer Kapazitätsrealität passen, oder Sie müssen bei jedem Link-Upgrade „umcodieren“.

• Wide Metrics: Größerer Wertebereich, geeignet für differenzierte Pfade und langfristige Skalierung.
• Konstantes Modell: Definieren Sie eine Metrik-Skala, die 1G/10G/100G sinnvoll abbildet, ohne ständig zu ändern.
• Policy statt „Bandbreite raten“: Metriken sollten Ihr gewünschtes Pfadverhalten modellieren, nicht nur Link-Speed spiegeln.

Ein praxistauglicher Ansatz ist eine feste Metriktabelle pro Linkklasse (Access-Uplink, Core-Link, WAN-Link), die im ganzen Netz gilt. Das erhöht Vorhersehbarkeit und reduziert Change-Risiko.

Multi-Topology und IPv6: Dual-Stack ohne Doppelchaos

IS-IS kann IPv4 und IPv6 integrieren. In Dual-Stack-Umgebungen ist das Ziel, dass IPv6 nicht „nebenher“ läuft, sondern gleichwertig und beobachtbar. Die IPv6-Erweiterung ist in RFC 5308 beschrieben. Für die Praxis bedeutet das:

• Konsistente Aktivierung: IPv4/IPv6 gleichermaßen auf den richtigen Interfaces aktivieren, keine „halb fertigen“ Links.
• Gleiche Level-Logik: IPv6 folgt dem gleichen Level-Design, sonst entstehen asymmetrische Pfade.
• Monitoring pro AF: Neighbors, LSDB-Größe und SPF-Events getrennt für IPv4 und IPv6 beobachten.

Scaling-Faktoren: LSDB-Größe, LSP-Flooding und SPF-Kosten

IS-IS skaliert sehr gut, aber nicht automatisch. Sie müssen die drei Haupttreiber kontrollieren: wie groß die Datenbank wird, wie häufig geflutet wird und wie oft SPF rechnen muss. In großen Netzen sind das Betriebskennzahlen, keine Theorie.

• LSDB-Größe: Anzahl LSPs, Anzahl TLVs, Anzahl Reachability-Einträge.
• Flooding-Rate: Wie viele Änderungen pro Zeit; Link-Flaps und unstable Links treiben Flooding.
• SPF-Häufigkeit: Jede relevante Änderung kann SPF triggern; zu häufige SPF-Rechnungen belasten CPU.

Das wichtigste Skalierungsprinzip lautet: Instabilität isolieren. Ein sauberer L1-Rand kapselt Link-Flaps und Access-Ereignisse, während L2 als ruhiges Backbone arbeitet.

DIS und Broadcast-Segmente: Stabilität durch klare Rollen

Auf Broadcast-Netzen (z. B. Ethernet-VLANs) wählt IS-IS einen DIS (Designated Intermediate System). Der DIS erleichtert das Flooding und reduziert Komplexität, kann aber bei instabiler Wahl zu unnötigen Veränderungen führen. Best Practices:

• Broadcast-Transits minimieren: Wo möglich, L3 Punkt-zu-Punkt Links statt großer Transit-VLANs.
• DIS bewusst steuern: Prioritäten so setzen, dass ein stabiler Router DIS wird.
• Instabilität erkennen: Häufige DIS-Wechsel sind ein Warnsignal für Layer-2-Probleme oder fehlerhafte Designannahmen.

Fast Convergence: BFD, SPF-Throttling und LSP-Optimierung

In modernen Netzen ist schnelle Konvergenz wichtig, aber Stabilität ist wichtiger als aggressive Timer. Profis kombinieren schnelle Failure Detection mit kontrollierter Control Plane. Statt „Hello-Timer extrem klein“ ist BFD häufig die robustere Lösung.

• BFD: Schnelle Erkennung von Forwarding-Ausfällen, ohne IS-IS-Timer übermäßig zu aggressiv zu machen.
• SPF-Throttling: Dämpfung bei Event-Stürmen, um CPU-Spikes zu vermeiden und Konvergenz kontrolliert zu halten.
• LSP-Gen/Refresh-Strategie: Auf großen Domänen ist es wichtig, LSP-Änderungen nicht unnötig zu erzeugen.

Für BFD-Grundlagen ist RFC 5880 eine gute Referenz. Für Cisco-spezifische Implementierung und Plattformgrenzen sind die Konfigurationsleitfäden entscheidend, z. B. die Cisco IOS XE Configuration Guides.

Overload Bit: Wartung und Schutz vor Blackholing

Ein häufig unterschätztes Profi-Feature ist das Overload Bit. Es signalisiert: „Dieser Router sollte nicht als Transit genutzt werden.“ Das ist ideal für Wartungsfenster oder Hochfahrphasen, weil Sie so verhindern, dass ein Router Verkehr übernimmt, bevor er bereit ist (z. B. bevor BGP, VRF-Leaks oder Policies stabil sind).

• Maintenance: Overload setzen, Traffic fließt um, dann Änderungen durchführen.
• Bootstrapping: Overload während Startphase, bis Services stabil sind.
• Risiko reduzieren: Verhindert ungewolltes Transitverhalten bei Teilkonvergenz.

Route Redistribution: Der schnellste Weg in die Unwartbarkeit

Wie bei OSPF ist Redistribution auch in IS-IS ein Risikofaktor, insbesondere wenn externe Routen ungefiltert in die IGP-Domäne gelangen. In großen Netzen sollte die IGP primär Infrastruktur- und Standortpräfixe transportieren, nicht „das ganze Internet“ oder riesige BGP-Tabellen.

• Minimieren: Nur notwendige Externals in IS-IS aufnehmen; häufig reicht eine Default-Route.
• Filtern: Prefix-Listen/Route-Maps, damit keine Route-Flut entsteht.
• Tagging/Policy: Externals kennzeichnen, um Loops und ungewollte Rückredistribution zu verhindern.

Operationalisierung: Was Sie im Day-2-Betrieb regelmäßig prüfen sollten

IS-IS ist dann „langweilig“, wenn Sie es beobachten und Drift vermeiden. Ein praxistauglicher Betriebsstandard umfasst wiederkehrende Checks, die Skalierung und Stabilität sichern.

• Adjacencies: Stabilität, Flap-Häufigkeit, DIS-Rollen, BFD-Status.
• LSDB-Größe: Wachstum über Zeit, auffällige Peaks, ungewöhnlich viele TLVs/Reachability-Einträge.
• SPF-Events: Häufigkeit und Ursachen (Link-Flaps, DIS-Wechsel, LSP-Flooding).
• Metrikkonsistenz: Keine „Sondermetriken“ ohne Designgrund; Metrikmodell als Policy behandeln.
• Level-Grenzen: Route-Leaking und Summaries wie geplant; keine unkontrollierte L1-„Weltkenntnis“.

Typische Fallstricke und wie Sie sie vermeiden

• Kein klares Level-Design: Alles L2, alles überall – funktioniert, skaliert aber schlechter. Besser: L1 lokal, L2 Backbone.
• Keine Wide Metrics: Metriken sind zu grob, Pfade wirken „zufällig“. Besser: Wide Metrics als Standard.
• Broadcast-Transits ohne DIS-Plan: DIS flapt, LSDB-Änderungen häufen sich. Besser: p2p oder DIS priorisieren.
• Unkontrolliertes Leaking: L1 wird groß und instabil. Besser: Default + Summaries, selektiv leaken.
• Redistribution ohne Filter: IGP wird zur Route-Müllhalde. Besser: Minimalprinzip, Filter, Tagging.
• Aggressive Timer statt BFD: Flapping bei kleinen Störungen. Besser: BFD + kontrolliertes SPF-Throttling.

Outbound-Referenzen

• RFC 1195 (Integrated IS-IS) als Grundlage für IS-IS mit IP-Unterstützung.
• RFC 5308 (IS-IS for IPv6) für Dual-Stack- und IPv6-Reachability in IS-IS.
• RFC 5305 (IS-IS Traffic Engineering Extensions) für TE-Erweiterungen und TLV-basierte Erweiterbarkeit.
• RFC 5880 (BFD) als Referenz für schnelle Failure Detection ohne aggressive IGP-Timer.
• Cisco IOS XE Configuration Guides für plattformspezifische IS-IS-Konfiguration, Features und Skalierungsoptionen.

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.