Zusammenfassung

  • Die Ausgangsfrage beschrieb eine flache IS-IS-L2-Domäne mit rund 300 Routern und Aggregationsgeräten mit ungefähr 100 nachgelagerten Adjazenzen.
  • Saku Ytti berichtete von einigen Tausend IS-IS-Knoten auf wesentlich älteren Control Planes; Mark Tinka nannte ein Netz mit etwa 300 Knoten bereits im Jahr 2009.
  • Tom Beecher hielt die Größenordnung grundsätzlich für machbar, verwies aber auf Geografie, LSDB-Größe und SPF-Verzögerung. Dan Snyder ergänzte Hardware, Fehlerdomäne und Konvergenzziel.
  • Matthew Petach trennte in der neuen Antwort Protokollkapazität von Resilienz: Ein Netz muss festlegen, wie weit ein Automatisierungsfehler, Hardwareausfall oder Faserschnitt wirken darf.
  • IETF-Dokumente zeigen, dass IS-IS-Hierarchie Flooding und SPF-Berechnung begrenzt, zugleich aber Detailinformation und damit mögliche Pfadoptimalität kostet.
  • Vor der Freigabe braucht die Architektur deshalb Fehlerbudgets und Tests mit degradiertem Verkehr, nicht nur einen Nachweis, dass alle Router die Topologie speichern können.

Der Fragesteller suchte Betriebserfahrung statt Herstellerempfehlungen. Sein Szenario umfasste etwa 300 Router in einer einzigen flachen IS-IS-Level-2-Domäne. Einzelne Aggregationsrouter sollten rund 100 Adjazenzen zu nachgelagerten Geräten halten.

Die ersten Antworten machten aus dieser Größenordnung keine Warnmarke. Saku Ytti beschrieb ein IS-IS-Netz mit einigen Tausend Knoten zu einer Zeit, als Control Planes deutlich langsamer waren. Mark Tinka verwies auf ungefähr 300 Knoten, die sein Netz 2009 auf Cisco CRS-1 und ME3600X sowie Juniper M320, T320 und MX480 betrieb. Auch Tom Beecher sah bei 300 Knoten grundsätzlich kein Problem.

Diese Aussagen sind keine Tests der vorgeschlagenen Umgebung. Topologie, Hardwaremix, Linkzahl, erwartete LSDB, Laufzeiten und Konvergenzvorgaben fehlen. Daraus lässt sich kein allgemeines Limit ableiten. Wohl aber die Erkenntnis, dass die Knotenzahl allein die Architektur nicht entscheidet.

Ein schneller SPF-Lauf verkleinert keine Fehlerdomäne

Beecher verband seine Einschätzung mit der geografischen Verteilung und der gesamten LSDB-Größe. Große Distanzen können andere SPF-Verzögerungen erfordern. Eine umfangreiche Datenbank erhöht den Aufwand. Seine weitergehende Einschränkung: Wenn die LSDB bereits zum Hauptproblem wird, sollte nicht nur das Tuning, sondern die flache Struktur selbst überprüft werden.

Dan Snyder ordnete die Entscheidung nach Hardware, gewünschter Fehlerdomäne und geforderter Konvergenzzeit. Diese Größen beschreiben verschiedene Risiken. Mehr Rechenleistung verkürzt die Berechnung, aber nicht automatisch die Ausbreitung einer falschen Konfiguration. Schnelle Konvergenz garantiert nicht, dass die verbleibenden Links den umgeleiteten Bedarf tragen.

Matthew Petachs später indexierte Antwort liefert den neuen operativen Befund. Er empfiehlt, mit den gewöhnlichen Fehlern zu beginnen: Bugs in Automatisierungswerkzeugen, falsche menschliche Eingaben, Ausfälle auf den physischen und logischen Schichten sowie Faserschnitte. Für jeden Typ soll das Netz einen zulässigen Wirkungsradius und sinnvolle logische „Schutztüren“ definieren.

Petach bestreitet die technische Skalierbarkeit nicht. Er hält 300 Knoten und unter passenden Bedingungen deutlich mehr für beherrschbar. Sein Einwand richtet sich gegen den Schluss, technische Aufnahmefähigkeit sei gleichbedeutend mit einem guten Betriebsdesign.

Reparaturzeit macht Erreichbarkeit zu einer Kapazitätsfrage

Ein defektes Optikmodul in einem besetzten Rechenzentrum und eine beschädigte Fernverbindung können dieselbe Neuberechnung auslösen, haben aber unterschiedliche Zeitprofile. Das Modul lässt sich womöglich rasch ersetzen. Eine Fernverbindung kann so lange eingeschränkt bleiben, dass Reserven, Dienstprioritäten und Kundenverpflichtungen den Betrieb bestimmen.

Petach nutzt transozeanische Verbindungen, um das Problem sichtbar zu machen. Zusätzliche Pfade sind teuer, vermeintlich verschiedene Routen können ein gemeinsames physisches Schicksal haben, und ein regionales Ereignis kann mehrere Kapazitäten zugleich entfernen. IS-IS kann korrekt auf die verbleibenden Pfade konvergieren und trotzdem mehr Verkehr dorthin schicken, als sie verkraften.

Der Thread berichtet keinen tatsächlichen Kabelausfall und enthält keine Messwerte eines bestimmten Systems. Der legitime Schluss ist ein Testverfahren: Für jeden glaubwürdigen Fehlerzustand muss die Nachfragematrix auf die Resttopologie angewendet werden. Dann zeigt sich, wo Sättigung entsteht und an welcher Stelle Traffic Engineering eingreifen muss.

Hierarchie begrenzt Zustand und entfernt zugleich Details

RFC 5302 beschreibt eine IS-IS-Domäne aus mehreren Level-1-Areas, die über eine Level-2-Topologie verbunden sind. Wenn LSPs innerhalb einer Area bleiben, sinken die Größe der Link-State-Datenbank und der Umfang der Kürzestweg-Berechnung.

Dasselbe Dokument nennt den Preis. Zusammenfassung und Abstraktion verlieren Informationen und können weniger optimale Wege erzeugen. Werden mehr spezifische Präfixe domänenweit verteilt, steigt die Genauigkeit, aber auch der Bedarf an Speicher, Übertragung und Berechnung. Hierarchie ist daher kein kostenloser Resilienzschalter, sondern eine Abwägung zwischen Skalierung und Pfadwissen.

RFC 9377 bezeichnet Verarbeitung und Flooding als letztliche Grenzen einer einzelnen IS-IS-Flooding-Domäne und nennt mehrere L1-Domänen mit einem L2-Backbone als üblichen Skalierungsansatz. RFC 8405 verlangt konsistente SPF-Backoff-Parameter innerhalb derselben Area oder Ebene und weist darauf hin, dass passende Werte sich im Lebenszyklus des Netzes ändern.

Keine dieser Spezifikationen setzt die Grenze bei 300. Zu messen sind Knoten, Links, LSDB-Wachstum, Änderungsrate, Flooding-Dauer, SPF-Verhalten und Restkapazität nach Ausfällen.

Vier Nachweise gehören in die Freigabe

Der erste betrifft Control-Plane-Reserve. Tests müssen das langsamste noch eingesetzte Gerät einbeziehen und CPU, Speicher, Aufbau von Adjazenzen, LSP-Verteilung sowie vollständigen und inkrementellen SPF bei realistischen Änderungen messen.

Der zweite betrifft Eingrenzung. Eine falsche Automatisierungskonfiguration, eine fehlerhafte Routing-Policy, Geräte- und Standortverlust sowie der gleichzeitige Ausfall gemeinsam gefährdeter Fernverbindungen benötigen eigene Szenarien. Für jedes sind maximale Reichweite, betroffene Dienste und Verantwortliche festzulegen.

Der dritte betrifft degradierte Kapazität. Konsistente Routingtabellen sind kein Erfolg, wenn die Restlinks überlasten. Das Design muss angeben, wo Traffic Engineering, Zulassungskontrolle oder Dienstpriorisierung ansetzen und welche Telemetrie die Maßnahme auslöst.

Der vierte betrifft den künftigen Betrieb. Petach nennt Horizonte von drei, fünf und zehn Jahren. Wachstum bedeutet nicht nur mehr Router, sondern neue Regionen, gemischte Hardwaregenerationen, größere Wartungsdomänen und genügend Fachleute, die die Topologie unter Zeitdruck sicher verstehen.

Die nächste Zahl ist ein Fehlerbudget

Ein geografisch kompaktes Netz mit tatsächlich unabhängigen Wegen und reichlich Reserve kann vernünftigerweise flach bleiben. Ein weit verteiltes Netz mit wenigen Fernpfaden, langen Reparaturen oder strengen Dienstzusagen kann Grenzen benötigen, lange bevor die Control Plane an ihre Belastungsgrenze kommt.

Der NANOG-Thread trennt zwei Freigaben. Die erste bestätigt, dass Protokoll und Hardware den Zustand von 300 Knoten tragen. Die zweite bestätigt, dass die Organisation den Fehlerumfang akzeptiert und den Verkehr im degradierten Betrieb steuern kann.

Für den Entwurf ist deshalb kein weiterer Bericht über 3.000 Router am wichtigsten. Benötigt wird ein Fehlerbudget: absorbierte Ereignisse, maximale Reichweite und Dauer, verbleibende Kapazität und der Steuerungspunkt, wenn der kürzeste Pfad nicht mehr die gewünschte Betriebsentscheidung liefert.

Quellen