Site icon bintorosoft.com

IS-IS Troubleshooting: Adjacencies, Levels und LSP Flooding

IS-IS Troubleshooting ist im Betrieb großer, stark segmentierter Netzwerke eine der wertvollsten Fähigkeiten, weil Intermediate System to Intermediate System (IS-IS) als IGP häufig dort eingesetzt wird, wo Stabilität, Skalierung und schnelle Konvergenz entscheidend sind: im Provider-Core, in Data-Center-Fabrics, in Campus-Backbones oder in WAN-Underlays für SD-WAN/Overlay-Designs. Gleichzeitig sind IS-IS-Fehlerbilder für Teams, die primär OSPF gewohnt sind, ungewohnt: Adjacencies kommen „einfach nicht hoch“, Level-Designs führen zu unerwarteten Default-Routen, LSP Flooding erzeugt CPU-Last und „Route Flaps“, und ein einzelner instabiler Link kann die LSDB (Link State Database) in großen Domains in Unruhe versetzen. Wer in solchen Situationen ohne System vorgeht, verliert Zeit und riskiert riskante Changes. Der professionelle Ansatz ist evidenzbasiert: Zuerst die Adjacency (Hello/CSNP/PSNP), dann die Levels (L1/L2, Area/Domain), dann die LSP-Flutlogik (Flooding, Sequence Numbers, Purges), und erst danach Metriken und Policies. Dieser Artikel zeigt Ihnen eine praxiserprobte Methode, um IS-IS Adjacencies, Levels und LSP Flooding sauber zu diagnostizieren – mit klaren Indizien, typischen Root-Cause-Klassen und Fixes, die den Betrieb dauerhaft stabil machen.

IS-IS im Überblick: Warum es anders tickt als OSPF

IS-IS ist ein Link-State-Protokoll, das historisch aus der OSI-Welt kommt und sich im IP-Betrieb über „Integrated IS-IS“ etabliert hat. Im Alltag ist die wichtigste Denkweise: IS-IS arbeitet direkt über Layer 2 (CLNS/LLC) und nicht über IP als Transport. Das macht es in manchen Umgebungen robust gegenüber IP-Adressierungsproblemen, erzeugt aber eigene Fehlerklassen: VLAN/Trunk/MTU/L2-Filter wirken direkter, und klassische „ping den Neighbor“ Tests erklären nicht immer, warum Hellos nicht ankommen.

Als seriöse Einstiegspunkte sind die IETF-Spezifikationen hilfreich, z. B. RFC 1195 (Integrated IS-IS) sowie für moderne Erweiterungen RFC 5308 (IS-IS für IPv6). Für das Flooding- und Protokollverhalten im Detail ist auch RFC 1142 als Hintergrundquelle nützlich.

Die wichtigste Methodik: Erst Adjacency, dann Levels, dann Flooding

In der Praxis scheitert IS-IS Troubleshooting selten daran, dass „das Protokoll komisch ist“, sondern daran, dass Teams die Diagnose-Reihenfolge nicht einhalten. Die folgenden drei Fragen reduzieren die Fehlerdomäne extrem schnell:

Wenn Sie diese Reihenfolge einhalten, vermeiden Sie den Klassiker: an Metriken oder Policies zu drehen, obwohl die Adjacency gar nicht stabil ist.

Adjacency Troubleshooting: Wenn Nachbarn nicht hochkommen oder flappen

IS-IS Adjacencies entstehen über Hello-Pakete (IIH). Sobald zwei Router kompatible Parameter sehen, wird die Adjacency aufgebaut und die LSDB-Synchronisation startet. Die meisten Probleme lassen sich in „kommt gar nicht hoch“ und „kommt hoch, flappt aber“ trennen.

Adjacency kommt gar nicht hoch: typische Root Causes

Adjacency flappt: typische Root Causes

High-Signal Checks für Adjacencies: Was Sie wirklich auslesen sollten

Viele Teams prüfen nur „Neighbor up/down“. Für eine belastbare Diagnose brauchen Sie einige zusätzliche Details, die in nahezu jeder Plattform sichtbar sind:

DIS-Wahl auf Broadcast-Segmenten verstehen

Auf Broadcast-Netzen (z. B. Ethernet-VLAN) wählt IS-IS einen DIS, der CSNPs periodisch sendet und das Flooding effizienter macht. Probleme entstehen, wenn DIS häufig wechselt (DIS flapping), z. B. durch instabile Links, wechselnde Prioritäten oder inkonsistente Interface-Timer. DIS-Flaps können sich wie „LSP Flooding“ oder „Routing instabil“ anfühlen.

Levels richtig interpretieren: L1, L2 und das häufigste Design-Missverständnis

Levels sind der Kern von IS-IS Design. Level-1 ist „Area-intern“, Level-2 ist „zwischen Areas“ (Backbone). Router können L1-only, L2-only oder L1L2 sein. Der häufigste Fehler im Incident ist, Levels als „OSPF Areas“ zu behandeln, ohne die Konsequenzen für Leak/Default/Reachability zu prüfen.

Typische Level-Fehlerbilder

ATT-Bit und Default-Verhalten praktisch einordnen

In vielen Designs signalisiert ein L1L2-Router über das ATT-Bit, dass er Zugang zu Level-2 hat. L1-Router können daraus ein Default ableiten (design- und vendorabhängig). Wenn dieses Verhalten falsch verstanden oder inkonsistent implementiert ist, entstehen „nur manche Ziele gehen“-Incidents. Praxisregel: Verlassen Sie sich nicht nur auf implizite Defaults, sondern prüfen Sie, ob Ihr Design explizite Default-Origination oder klare Policies nutzt.

LSP Flooding verstehen: Wenn die LSDB „unruhig“ wird

LSP Flooding ist der Mechanismus, mit dem IS-IS Topologieänderungen verteilt. Im Normalbetrieb ist Flooding ruhig: LSPs haben stabile Sequence Numbers und werden nur bei Changes aktualisiert. In Störungen sehen Sie hingegen „LSP Churn“: häufige Updates, Retransmits, Purges oder sich ständig ändernde Sequence Numbers. Das erzeugt CPU-Last, längere SPF-Läufe und im schlimmsten Fall Routing-Instabilität.

Woran Sie ein Flooding-Problem erkennen

Die häufigsten Ursachen für LSP Storms

MTU und IS-IS: Nicht nur für Adjacencies relevant

MTU-Probleme sind bei IS-IS doppelt tückisch: Adjacencies können hochkommen, aber LSPs oder CSNP/PSNP können bei bestimmten Größen droppen. Das führt zu Retransmits, inkonsistenter LSDB und scheinbar „random“ fehlenden Routen. Besonders häufig in Netzen mit VLAN-Tagging, QinQ, Tunneln oder Mischbetrieb alter und neuer Plattformen.

Für PMTUD- und MTU-Kontext sind RFC 1191 (IPv4) und RFC 8201 (IPv6) hilfreiche Referenzen.

Authentication: Wenn Nachbarn „einander sehen“, aber nichts austauschen

IS-IS Authentication kann auf verschiedenen PDU-Typen wirken (Hellos, LSPs). Ein Mismatch kann sich daher unterschiedlich äußern: von „Adjacency kommt gar nicht hoch“ bis zu „Adjacency ist up, aber LSDB bleibt inkonsistent“, wenn z. B. LSP-Auth inkonsistent ist. Genau deshalb gehört Auth immer in die ersten Checks, sobald Flooding unplausibel wirkt.

Forensik mit PCAP: IS-IS sichtbar machen, ohne „Raten“

Wenn Sie den Beweis brauchen, ist ein gezielter Mitschnitt Gold wert. IS-IS läuft nicht über UDP/TCP, sondern als eigenes L2-Protokoll (über LLC), daher müssen Capture-Punkte richtig gewählt werden (Switch SPAN, Router Interface Capture, TAP). In Captures sehen Sie IIH (Hellos), LSPs, CSNPs und PSNPs inklusive Level-Informationen und Sequenznummern. Das ist die schnellste Art, Adjacency- und Flooding-Probleme zu beweisen.

Für Capture- und Analysepraxis sind die Wireshark-Dokumentation und die tcpdump-Manpage hilfreiche Ausgangspunkte (auch wenn tcpdump-Filter für IS-IS je nach Plattform variieren).

Systematisches Troubleshooting: Schritt-für-Schritt ohne Blindflug

Der folgende Ablauf ist bewusst so gestaltet, dass er in On-Call-Situationen funktioniert: Sie bekommen schnell eine Entscheidung, ob es ein Link-/Adjacency-Problem, ein Level-Design-Problem oder ein Flooding/LSDB-Problem ist.

Schritt 1: Scope und Impact klären

Schritt 2: Adjacency Health prüfen

Schritt 3: Level-Design verifizieren

Schritt 4: Flooding/LSDB Stabilität prüfen

Schritt 5: Root Cause isolieren und Low-Risk Mitigation

Typische Fixes, die dauerhaft helfen

Runbook-Baustein: IS-IS Troubleshooting in 15 Minuten

Weiterführende Quellen für Standards und Praxis

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