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.

• Adjacency: Nachbarschaft auf Layer 2 (P2P oder Broadcast), aufgebaut über IIH (IS-IS Hello)
• Levels: Level-1 (intra-area) und Level-2 (inter-area/backbone)
• LSPs: Link State PDUs, die Topologieinformationen tragen; Flooding sorgt für Verteilung
• CSNP/PSNP: Sequenznummern-PDUs für Datenbank-Synchronisation (Complete/Partial Sequence Numbers)

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:

• Adjacency: Sehen sich die Nachbarn stabil (UP) – und auf welchem Interface-Typ (P2P/Broadcast)?
• Levels: Welche Level (L1/L2) laufen wirklich auf dem Link und passen sie zum Design?
• Flooding: Ist die LSDB stabil oder sehen Sie LSP Churn (neue Sequence Numbers, häufige Purges, Retransmits)?

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

• Layer-2 Pfad stimmt nicht: falsches VLAN, falscher Trunk, QinQ/Tagging-Fehler, Port im falschen VRF/VLAN-Kontext
• IS-IS nicht auf Interface aktiv: Klassiker nach Template-Drift oder Subinterface-Umstellungen
• MTU/Frame-Size Probleme: Hellos klein, aber später scheitert Sync; oder bereits IIH/CSNP werden gedroppt (selten, aber möglich bei strikten L2-Limits)
• Authentication Mismatch: IS-IS Auth (HMAC/Password) passt nicht; Hellos werden verworfen
• Interface Type Mismatch: einseitig P2P, andere Seite Broadcast (oder NBMA-ähnliche Konstrukte)
• L2 Filter/Storm-Control: Control-Plane Filter, CoPP oder Bridge-Policies droppen IS-IS Frames

Adjacency flappt: typische Root Causes

• Physische Instabilität: CRC/Symbol Errors, Optics/DOM Drift, Link Flaps, Autoneg/duplex issues
• Hello Timer zu aggressiv: geringer Holdtime auf instabilem Link führt zu häufigem Neighbor Down
• Congestion/Queueing auf Control Plane: L2 ok, aber Pakete kommen zu spät; Hold Timer läuft ab
• LAG/Bundle Inkonsistenz: IS-IS läuft über Port-Channel, aber ein Member hat Drops/Errors oder andere MTU
• Flooding Overload: LSP Storm erhöht CPU, dadurch werden Hellos verzögert → Feedback-Loop

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:

• Adjacency State: Up/Down und Dauer seit letztem Change
• Level pro Adjacency: L1, L2 oder L1L2 – passt das zum Design?
• Holdtime/Hello Interval: stimmen die Timer und ist die Adjacency unter Last stabil?
• Auth Status: aktiv/inaktiv und ob Mismatch gemeldet wird
• Interface Type: P2P vs Broadcast; bei Broadcast: gibt es einen Designated Intermediate System (DIS)?
• Packet Counters: IIH/CSNP/PSNP Rx/Tx, Retransmits, Drops

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.

• Indiz: häufige DIS-Changes korrelieren mit LSDB-Churn
• Fix-Richtung: DIS-Priorität bewusst setzen, Link-Stabilität verbessern, Timer nicht überaggressiv

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

• L1-only Router „sieht das Backbone nicht“: externe Präfixe fehlen, nur lokale Area-Routen vorhanden
• Default Route fehlt in L1: L1 Router hat keinen Weg nach „außen“, weil L1→L2-Leak/ATT-Bit/Default-Origination nicht wie erwartet wirkt
• Unerwartete L2-Dominanz: Router bevorzugt L2-Pfad, obwohl L1-Pfad geplant war (Metriken oder falsche Level-Aktivierung)
• Adjacency nur auf einem Level: Link ist L1L2 geplant, aber nur L1 kommt hoch (oder nur L2) – häufig Auth/Policy/Config Drift

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

• Viele LSP Updates pro Minute: besonders, wenn keine geplanten Changes laufen
• Hohe Retransmit-Zähler: PSNPs fordern wiederholt fehlende LSPs an
• Sequence Number Sprünge: LSPs werden ständig neu generiert
• LSP Purges: LSPs werden gelöscht/abgelaufen und sofort neu aufgebaut
• SPF/CSNP Peaks: häufige SPF-Runs oder DIS/CSNP-Instabilität

Die häufigsten Ursachen für LSP Storms

• Flappende Links/Adjacencies: jedes Up/Down erzeugt LSP Updates und Flooding
• Instabiles DIS-Verhalten: auf Broadcast-Segmenten führt DIS-Flapping zu zusätzlichem Flooding
• Fehlkonfigurierte Interfaces: Interfaces werden ständig in/aus IS-IS gebracht (Automation/Template-Drift)
• Überaggressive LSP Generation: zu kurze LSP Refresh/Update Policies (designabhängig)
• MTU/Fragmentation/Drop auf Flooding-PDUs: LSPs werden nicht zuverlässig transportiert, PSNP-Retransmits steigen
• Control-Plane-Policing: Flooding wird gedrosselt, LSDB kommt nie „zur Ruhe“

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.

• Indiz: Adjacency stabil, aber LSDB nicht konsistent oder Flooding Retransmits hoch
• Nachweis: Captures zeigen Fragmentation oder fehlende LSPs; Counters zeigen PSNP-Retries
• Fix: L2/L3 MTU konsistent, Overhead berücksichtigen; Drops/ACLs auf Fragmente vermeiden

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.

• Indiz: Adjacency up, aber LSPs werden verworfen oder nicht akzeptiert
• Nachweis: Logs zu Auth-Failures, erhöhte PSNP-Retries, fehlende LSPs
• Fix: Auth-Typ und Keys konsistent, Rollovers geplant (overlapping keys), Level-spezifische Auth prüfen

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.

• IIH: zeigen Level (L1/L2), Holdtime, System ID, Area Addresses
• CSNP: zeigt komplette LSP-Übersicht (DIS-Mechanik auf Broadcast)
• PSNP: fordert fehlende LSPs an (hohe Rate = Flooding-Problem oder Drops)
• LSP: Sequence Numbers, Remaining Lifetime, TLVs (Prefix, Neighbors, etc.)

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

• Welche Präfixe fehlen oder flappen? Nur ein Standort/Pod oder viele?
• Ist es ein einzelnes Interface/Neighbor oder mehrere?
• Gibt es zeitliche Korrelation zu Changes (Maintenance, Automation, Provider Events)?

Schritt 2: Adjacency Health prüfen

• Neighbor up/down, Uptime, Flap-Frequenz
• Level pro Adjacency (L1/L2/L1L2) gegen Design
• Timer (Hello/Hold) und Link-Qualität (Errors, Flaps)

Schritt 3: Level-Design verifizieren

• Welche Router sind L1-only, L2-only, L1L2?
• Erwartete Defaults/Leaking (ATT/Default Origination) vorhanden?
• Gibt es unerwartete L2-Dominanz oder fehlende Inter-Area Reachability?

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

• LSP Update Rate, Retransmits, Purges, Sequence Number churn
• CSNP/PSNP Verhalten (DIS stabil?)
• SPF Frequency und CPU/Control-Plane-Last

Schritt 5: Root Cause isolieren und Low-Risk Mitigation

• Wenn Adjacencies flappen: physische Qualität/Errors/Optics, Timer entschärfen, fehlerhaften LAG-Member drainen
• Wenn Levels falsch sind: Level-Aktivierung und Area Address korrigieren, Design-Policies prüfen
• Wenn Flooding stürmt: Topology Flap Quelle finden, DIS stabilisieren, CoPP/Rate-Limits prüfen, MTU/Drops ausschließen

Typische Fixes, die dauerhaft helfen

• Templates und Drift-Kontrolle: Level-Konzept, Timer, Auth, Interface Types standardisieren
• DIS-Design bewusst setzen: Prioritäten definieren, instabile Edge-Links nicht DIS werden lassen
• MTU konsistent planen: L2/L3 MTU inklusive VLAN/QinQ/Overlay-Overhead
• Control-Plane schützen: CoPP so konfigurieren, dass IS-IS stabil läuft, ohne Flooding unnötig zu drosseln
• Observability: LSP churn, PSNP/CSNP Rates, Adjacency Flaps als Standard-Dashboards

Runbook-Baustein: IS-IS Troubleshooting in 15 Minuten

• Minute 0–3: Scope definieren: Welche Router/Links, welche Levels, welche Präfixe betroffen? Timeline und letzte Changes notieren.
• Minute 3–6: Adjacencies prüfen: up/down, Flaps, Level pro Neighbor, Timer/Holdtime, Interface Errors.
• Minute 6–9: Level-Design verifizieren: L1/L2 Rollen, erwartete Defaults/Inter-Area Reachability, DIS-Verhalten auf Broadcast-Segmenten.
• Minute 9–12: Flooding prüfen: LSP Update Rate, PSNP/CSNP Retransmits, Purges, SPF Frequency, CPU/Control-Plane.
• Minute 12–15: Low-Risk Fix: instabilen Link/Member isolieren, Timer entschärfen, Auth/MTU/Level konsistent machen; danach Verifikation (Adjacency stabil, LSP churn sinkt, Routen stabil).

Weiterführende Quellen für Standards und Praxis

• RFC 1195 für Integrated IS-IS (Grundlagen, TLVs, IP-Routing)
• RFC 5308 für IPv6 in IS-IS (häufig in modernen Dual-Stack-Designs)
• RFC 1142 als Hintergrund zu IS-IS-Mechaniken und Flooding-Konzepten
• RFC 1191 für PMTUD unter IPv4 (relevant bei MTU-Blackholes, die Flooding stören)
• RFC 8201 für PMTUD unter IPv6
• Wireshark Dokumentation für IS-IS PDU-Analyse (IIH, LSP, CSNP, PSNP) und Timing-Korrelation
• tcpdump Manpage für effiziente Captures und Filterpraxis in produktiven Umgebungen

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.