Was passiert, wenn ich das kaputt mache?

Ein Modell, dem Sie vertrauen, lohnt sich nur, wenn Sie ihm Fragen stellen können, die es noch nie bekommen hat

22. August 2026 Michel Wijnberg

In den ersten acht Beiträgen dieser Reihe ging es darum, das Modell richtig zu bekommen: das Netzwerk zu erkennen, ohne Teil davon zu werden, die Weiterleitung Hop für Hop zu reproduzieren, nicht zu raten, und auf die harte Tour herauszufinden, dass mein eigenes Werkzeug Fiktion zeichnete.

Das alles ist Vorbereitung. Ein Netzwerkmodell, das lediglich genau ist, ist ein sehr teures Foto. Der Grund, diesen Aufwand zu treiben, ist, ihm die Frage stellen zu können, die Sie dem echten Netzwerk nicht stellen können:

Was passiert, wenn ich das kaputt mache?

Diese Frage entscheidet über Wartungsfenster. Irgendjemand muss sagen, ob das Ziehen einer Karte um 03:00 überlebbar ist, und normalerweise beantwortet er das aus einem mentalen Modell und der Erinnerung an den letzten Ausfall. Was jetzt kommt, ist nicht deshalb interessant, weil Osprey einen Simulator hat. Es ist interessant, weil der Ausfall nicht mehr stattfinden muss, bevor man über ihn nachdenken kann.

Sieben Dinge, die Sie ändern können

Der Simulationsmodus von Osprey nimmt das Live-Modell, klont es, wendet Veränderungen an und rechnet neu. Die vollständige Liste dessen, was Sie ändern dürfen, ist kurz, und die Kürze ist Absicht:

Veränderung	Was sie tut
`link_failure`	Einen Link ausfallen lassen
`node_failure`	Einen Router ausfallen lassen
`cost_change`	Einen Link neu metrisieren, Hin- und Rückrichtung unabhängig
`hypothetical_link`	Einen nicht existierenden Link hinzufügen, mit Kosten und Geschwindigkeit
`hypothetical_node`	Einen nicht existierenden Router hinzufügen
`srlg`	Eine Shared-Risk-Gruppe ausfallen lassen: eine Aktion, N korrelierte Linkausfälle
`peer_failure`	Eine BGP-Sitzung abwerfen

Alles andere wird mit unknown mutation type abgelehnt. Es gibt keine Veränderung zum Umbau von Areas, keine für Redistribution und keine für Kaskadenausfälle, denn keine davon ließe sich umsetzen, ohne Daten zu erfinden. Darauf komme ich zurück.

Ein Kabel, und was das Netzwerk daraus macht

Hier ein echter Fall aus dem Labor. nrt1-cr1 ↔ sea1-cr1 ist ein transpazifischer Backbone-Link in AS 200, Kosten 10 unter OSPFv2, einer der 275 Links, die Osprey über die beiden OSPF-Instanzen dieses Mandanten führt. Ich habe ihn rechts angeklickt und Simulate Failure gewählt:

Der Reiter Impact der Simulation: 0 isoliert, 56 Pfade geändert, 0 neue SPOFs

Lesen Sie die drei Zahlen oben. Nichts wurde unerreichbar. 56 Pfade haben sich geändert. Kein neuer Single Point of Failure ist entstanden. Die ganze Auswertung dauerte 57 ms, serverseitig.

Lesen Sie jetzt die Überschrift Failed Links, denn dort passiert etwas, das Leute übersehen: 2 links. Ich habe ein Kabel angeklickt, und Osprey hat zwei Links ausfallen lassen, weil dieses Kabel OSPFv2 und OSPFv3 als zwei unabhängige Protokollinstanzen mit zwei unabhängigen Kosten trägt. Die Leitung ausfallen zu lassen, lässt sie in beiden ausfallen. Ein Werkzeug, das eine Kante je Kabel modelliert, muss sich entscheiden, welches der beiden Leben es beendet.

Der interessante Teil ist die Aufschlüsselung dieser 56:

Der Reiter Paths: 15 Pfade mit gestiegenen Kosten, 41 zu identischen Kosten umgeleitet

15 gestiegen: Der Pfad wurde teurer. sea1-cr1 → nrt1-cr1 geht von Kosten 1 auf Kosten 11, die direkte Verbindung ersetzt durch einen Drei-Hop-Pfad.
41 umgeleitet: Der Pfad hat andere Hops genommen, und die Kosten haben sich überhaupt nicht bewegt.

Auf die zweite Zahl lohnt es sich zu starren. Zweiundvierzig Quelle/Ziel-Paare haben einen anderen Weg durch das Netz genommen und nichts dafür bezahlt, weil bereits eine gleichwertige Alternative da war. So sieht Redundanz aus, wenn man sie als Messung ausdrückt statt als Adjektiv. “Wir haben diversitäre Pfade” ist eine Behauptung. “41 von 56 betroffenen Paaren leiten zu identischen Kosten um” ist eine Zahl, und es ist die Zahl, die Ihnen sagt, ob das Wartungsfenster um 03:00 Uhr liegen muss.

Nichts davon wurde in einen Router getippt. Das Labor hat keinen Link verloren. Ich habe das Modell gefragt.

Die Verweigerung oben auf dem Bildschirm

Sehen Sie sich jetzt das bernsteinfarbene Banner im ersten Screenshot an, denn es ist ein Eingeständnis, und es ist der Grund, warum ich dem Rest des Panels vertraue:

simulated paths are shown as an SPF projection (source-rooted least-cost tree) so before and after stay comparable; the live path panel shows the hop-by-hop forwarding chain, which can differ where an intermediate router’s own routing table disagrees with the source’s view

Beitrag drei war ein Argument dafür, dass ein von der Quelle gewurzelter Korridor das falsche Modell der IP-Weiterleitung ist, gestützt auf eine Messung: 360 von 2.839 Inter-Area-Routerpaaren hatten einen Korridor mit einem Hop, den kein Paket je nimmt. Ich habe diese Engine durch eine ersetzt, die die eigene Routing-Tabelle jedes Routers abläuft, und sie gegen alle 4.032 Paare validiert.

Und dann benutze ich sie in der Simulation bewusst nicht.

Der Grund steht im Code, und es ist der Satz, auf den ich in diesem Produkt am stolzesten bin:

// The panel shows the hop-by-hop forwarding chain (path_chain.go): every
// router's OWN routing table, read from the per-area LSDBs. A what-if topology
// has no such tables. The Type-3 summaries the surviving ABRs would
// re-originate after the mutation are exactly the thing that cannot be
// synthesised, and inventing them would make the simulation's numbers agree with
// nothing. So both simulation sides stay on the source-rooted SPF projection,
// consistently with each other, and say so. A labelled projection is honest; a
// baseline that disagrees with the baseline is not.

Die eigene Tabelle jedes Routers abzulaufen setzt voraus zu wissen, wie die Tabelle jedes Routers nach der Änderung aussehen würde. Bei OSPF hängt das von den Summary-LSAs vom Typ 3 ab, die die überlebenden ABRs neu erzeugen würden: LSAs, die es nicht gibt, weil der Ausfall nicht stattgefunden hat. Ich kann sie raten. Ich kann sie nicht richtig raten, und eine Hop-für-Hop-Kette auf geratenen Summaries trüge die ganze Autorität der validierten Engine und nichts von deren Validierung.

Also bleiben beide Seiten des Vergleichs bei der klar gekennzeichneten Projektion. Das Vorher-Bild wird absichtlich schlechter gemacht, damit es weiter zum Nachher-Bild passt. Ein “56 Pfade geändert”, das in Wahrheit “36 echte Änderungen plus 20 Artefakte daraus, dass beide Seiten verschiedene Engines benutzen” bedeutet, ist kein Diff. Es ist Rauschen mit einer Zahl davor.

EIGRP: die Grenze liegt bei meinen Daten, nicht beim Protokoll

Lassen Sie etwas im EIGRP-Mandanten ausfallen, und Osprey hält an, statt zu projizieren:

the simulated change affects the observed EIGRP chain (forward and reverse). Osprey cannot predict DUAL re-convergence: the topology tables it reads carry the DUAL distances, not the metric components (bandwidth, delay) a recomputation needs. After a real event the live view shows the new chain.

EIGRP hat keine Link-State-Datenbank, gegen die man neu rechnen könnte. Was Osprey hat, ist die eigene Topologietabelle jedes Routers, gelesen aus der CISCO-EIGRP-MIB, und diese zwölf Spalten tragen die DUAL-Distanzen (Feasible Distance, Computed Distance, Reported Distance), nicht die Komponenten, aus denen die Distanzen gebaut wurden.

Um DUAL nach einer Änderung neu zu rechnen, brauchen Sie minimale Bandbreite, Gesamtverzögerung, Zuverlässigkeit, Last, MTU und Hop Count. Auf dem Gerät gibt es die; ich habe es auf e-ams1-cr1 mit show ip eigrp topology 10.64.0.0/15 geprüft. In der MIB-Tabelle, die Osprey liest, stehen sie schlicht nicht.

Dieser Unterschied steht mit Absicht im Codekommentar:

// Scoped to what Osprey READS, deliberately not to what SNMP can carry: … A future
// CLI enricher could lift part of this ceiling, so the sentence must not read as a
// permanent property of the protocol.

Es gibt einen echten Unterschied zwischen “dieses Protokoll lässt sich nicht simulieren” und “ich erhebe die Eingangsdaten derzeit nicht”, und ein Produkt, das beides verwischt, sagt Ihnen stillschweigend, Sie bräuchten gar nicht mehr zu fragen. Hier ist es eine Grenze der Datenerhebung, und die lässt sich anheben. Wenn ich sie anhebe, verschwindet die Meldung.

Darunter liegt eine kleinere, schärfere Regel. Wenn die Veränderung eine reine Entfernung ist (ein Link- oder Knotenausfall) und das Entfernte nachweislich nicht auf der beobachteten Kette liegt, zeigt Osprey weiter die echte Kette und sagt, warum: “observed live EIGRP chain: the simulated failure does not touch it (EIGRP re-convergence itself is not modelled)”. Kapazität woanders zu entfernen kann einen Distanzvektor-Pfad, der sie nicht benutzt hat, niemals verbessern. Aber eine Kostenänderung oder ein neuer Link kann einen Pfad von überall anziehen, also gelten die immer als Berührung. Die Engine verweigert genau dann, wenn sie muss, und nicht grundsätzlich.

Was nicht in der Veränderungsliste steht, und warum

Die sieben Veränderungen sind das, was ich umsetzen konnte, ohne Eingangsdaten zu erfinden. Die fehlenden fehlen aus benannten Gründen:

Umbau von Areas. Einen ABR zu verschieben oder eine Area-Grenze neu zu ziehen ändert, welche Summary-LSAs überhaupt existieren. Das ist keine Veränderung der Topologie, das ist eine andere Topologie.
Änderungen an der Redistribution. Sie hängen von Route-Maps und Prefix-Lists ab, in die Osprey keinen Einblick hat. Ich würde eine Politik modellieren, die ich nicht lesen kann.
Kaskadenausfälle. Den zweiten Ausfall vorherzusagen erfordert Warteschlangen- und TCP-Dynamik, deren Modellierung ein Topologie-Werkzeug nicht behaupten sollte. Das Risiko benennen, ja; die Kaskade vorhersagen, nein.

Jedes davon ließe sich wunderbar vorführen. Jedes wäre eine Zahl, hinter der nichts steht.

Der Punkt

Die Simulation ist die Stelle, an der ein Topologie-Produkt die Modellierungsarbeit entweder einlöst oder bloßstellt. Jede Abkürzung, die im Datenmodell genommen wurde, taucht hier als selbstbewusst falsche Antwort auf, denn ein What-if hat keine gesicherte Wahrheit, gegen die man prüfen könnte. Der Ausfall hat nicht stattgefunden, also kann Ihnen nichts widersprechen. Genau deshalb ist es die Funktion, bei der Sorgfalt sich am meisten lohnt.

Die ehrliche Fassung ist je Screenshot weniger beeindruckend und um 03:00 Uhr erheblich nützlicher: sieben Dinge, die Sie ändern können, vier Zahlen, die herauskommen, und ein Banner, das erklärt, welche Engine sie erzeugt hat.

Als Nächstes: Ein Link fällt aus, aber welche Teile des Netzes hingen tatsächlich daran? Der Wirkungsradius.