Das Netzwerk hat ein Gedächtnis
Rekonstruieren, was das Netzwerk um 14:02 Uhr glaubte, und der Unterschied zwischen dem, was sich änderte, und dem, was Sie erfuhren
Michel Wijnberg
Jedes Werkzeug in dieser Reihe beantwortet bisher Fragen über das Jetzt. Das ist die falsche Zeitform für die beiden Momente, in denen eine Ingenieurin am meisten Hilfe braucht.
Der erste ist während eines Vorfalls: Das Netzwerk verhält sich falsch, und was Sie brauchen, ist nicht sein aktueller Zustand, sondern sein Zustand von vor zwanzig Minuten, bevor jemand anfing, Dinge zu reparieren. Der zweite ist danach: Das Netzwerk läuft wieder, alle haben eine Theorie, und niemand kann die Topologie vorlegen, wie sie zum Zeitpunkt des Ausfalls aussah.
Ospreys Antwort ist eine Uhr.
Das ist keine Wiedergabe einer Aufzeichnung. Jedes Element auf diesem Canvas wurde
für einen Zeitstempel rekonstruiert: die Geräte, die Links, ihre Kosten und
Zustände, die Area-Mitgliedschaften. Der Regler darunter sagt Jul 29, 14:02 und
(30/36): der dreißigste von sechsunddreißig verschiedenen Topologiezuständen im
gewählten 24-Stunden-Fenster.
Jeder Punkt auf dieser Spur ist ein Moment, in dem das Netzwerk wirklich anders war.
Jedes Monitoring-Werkzeug hebt Historie auf, deshalb braucht dieser Satz eine schärfere Kante. Aufgehoben werden Messwerte: die CPU lag bei 83 %, das Interface machte 4 Gbit, die Abfrage war erfolgreich. Das sind Ablesungen am Netzwerk, und um 14:02 sagen sie Ihnen, dass ein Gerät beschäftigt war. Sie können nicht sagen, was es geglaubt hat. Osprey hebt Zustand auf: welche Nachbarschaften bestanden, welche Routen mit welcher Metrik installiert waren, zu welchen Areas ein Router gehörte, welche BGP-Pfade ausgewählt waren und warum. Der Unterschied zeigt sich in dem Moment, in dem Sie eine echte Frage stellen. Eine Messwert-Historie kann Ihnen sagen, dass ein Link um 14:02 ausgelastet war. Eine Zustands-Historie kann Ihnen sagen, dass er ausgelastet war, weil ein ABR vier Minuten zuvor eine Summary zurückgezogen hatte und die halbe Region plötzlich den weiten Weg nahm. Das eine ist ein Symptom mit Zeitstempel. Das andere ist die Überlegung des Netzwerks selbst, aufbewahrt.
Snapshots, die es nur gibt, wenn etwas passiert ist
Die naive Umsetzung schreibt einen Snapshot nach Zeitplan. Alle fünf Minuten die Topologie ausgeben. Das ist einfach und erzeugt eine Datenbank, die überwiegend aus identischen Kopien besteht, plus eine Auflösungsgrenze, hinter die Sie nicht sehen können.
Osprey schreibt einen Snapshot, wenn die Topologie sich ändert, und sonst nie.
Jedes Topologie-Ereignis von einem Collector wird zuerst gehasht:
// computeTopologyHash computes an FNV-64a hash over the topology snapshot data.
// Uses addition accumulation of per-element hashes for order-independence.Geräte steuern ihre Router-ID und ihre ABR-/ASBR-Bits bei, Links ein richtungsnormalisiertes Routerpaar samt beider Kosten und ihres Zustands, Stub-Netzwerke und Interfaces das Ihre. Die Akkumulation ist additiv, damit der Hash nicht davon abhängt, in welcher Reihenfolge die Elemente eintrafen: Zwei Collectors, die dieselbe Area in unterschiedlicher Reihenfolge melden, müssen denselben Hash ergeben, sonst sähe jede Abfrage wie eine Änderung aus.
Der Hash wird im Speicher mit dem letzten für diese Area verglichen. Gleich: Es wird nichts geschrieben. Verschieden: Eine Snapshot-Zeile wird eingefügt.
Das Ergebnis ist eine Zeitachse, die von Bauart her informationsdicht ist. Mein Labor hat in den letzten 30 Tagen 478 Snapshots über 51 Areas erzeugt: rund 16 pro Tag über den ganzen Bestand, jeder davon ein echter Unterschied. Die Punkte auf dem Regler sind keine Stichproben. Sie sind Ereignisse.
Es bedeutet auch, dass eine stabile Area viele Stunden ohne Zeile bleiben kann, und das ist richtig und keine Lücke: Es ist nichts passiert, also gibt es nichts aufzuzeichnen. Der nächstgelegene Snapshot am oder vor Ihrem gewählten Zeitstempel ist der Zustand zu diesem Zeitstempel.
Time Travel ist nicht eine Funktion
Die Uhr ist der sichtbare Teil. Nützlich wird sie dadurch, dass ungefähr zwanzig
API-Endpunkte denselben Parameter at= annehmen und zu diesem Moment antworten:
der Topologiegraph, der LSDB-Browser, die Pfadberechnung, SPF-Bäume, RIBs je
Router, Inter-Area- und externe Routen, ASBR-Einträge, Interfaces,
Stub-Netzwerke, BGP-Peers, BGP-Best-Paths, empfangene Pfade je Peer.
BGP wird stärker behandelt als Snapshots, denn BGP ändert sich weit häufiger als
die Topologie. Es wird als bitemporales Änderungsprotokoll gespeichert: Jeder
Best-Path, jede Peer-Sitzung und (optional) jeder empfangene RIB-Eintrag ist ein
Intervall mit einem valid_from und einem valid_to, wobei ein offenes valid_to
“gilt weiterhin” bedeutet. Eine Frage zum Zeitpunkt T zu stellen ist dann ein
Prädikat statt einer Rekonstruktion: valid_from <= T AND (valid_to IS NULL OR valid_to > T).
Zwei Details darin haben am längsten gedauert, und bei beiden geht es darum, Dinge nicht aufzuzeichnen:
- Das Aufflackern von Intervallen wird durch einen Attribut-Hash unterdrückt, der die IGP-Metrik und das aufgelöste Next-Hop-Gerät bewusst ausschließt. Die ändern sich, sobald das IGP neu konvergiert, und würden sie ein neues Intervall öffnen, sähe jedes BGP-Präfix im Netz jedes Mal nach Flapping aus, wenn irgendwo eine unbeteiligte Link-Metrik sich bewegt.
- Ein ausfallender Peer wird als Beobachtungslücke aufgezeichnet und nicht als Massenrücknahme. Wenn eine BMP-Sitzung abbricht, hat der Router nicht hunderttausend Präfixe zurückgezogen. Mir wurde nur nichts mehr über sie erzählt. Das als Rücknahme zu schreiben würde jedes Mal, wenn eine Monitoring-Sitzung stolpert, das größte Routing-Ereignis der Netzgeschichte erfinden.
In beiden Fällen erfindet die einfache Umsetzung ein Ereignis. Eine Historie, die Ereignisse erfindet, ist schlimmer als gar keine, denn Sie werden ihnen nachgehen.
In der Vergangenheit simulieren
Die beiden Modi lassen sich kombinieren, und das ist mein Lieblingsstück im Produkt.
Sie können Time Travel betreten, die Uhr stellen und dann die Simulation
betreten. Der Canvas trägt ein Wasserzeichen SIMULATION @ <timestamp>, und das
What-if läuft gegen die Topologie, wie sie zu diesem Moment bestand.
Damit lautet die Frage, die Sie stellen können:
Wäre dieser Ausfall überlebbar gewesen, so wie das Netzwerk um 14:02 Uhr tatsächlich dastand?
Nicht gegen die heutige Topologie, die seither repariert, neu metrisiert und erweitert wurde. Gegen die, die wirklich da war. Für die Arbeit nach einem Vorfall ist das der Unterschied zwischen einer belastbaren und einer plausiblen Antwort.
Sie achtet auch auf ihre eigenen Grenzen. Eine Analyse von Peer-Ausfällen zu einem vergangenen Zeitpunkt setzt voraus, dass für diesen Bereich die vollständige RIB-Historie aufgezeichnet wurde; wo das nicht der Fall war, ist das Ergebnis keine stille Näherung, sondern ein ausgesprochenes Auslassen:
BGP effects (peer failure, hot-potato exit shifts, BGP traffic) are not evaluated at this time: no full-RIB history (history_mode=‘full’) is recorded for the scope. Enable full history mode on a BMP target to time-travel BGP.
Diese Meldung benennt die fehlende Eingabe und die Einstellung, die sie liefern würde. Es ist eine Meldung, auf die Sie reagieren können.
Was nicht in der Vergangenheit liegt, laut ausgesprochen
Einige Dinge haben tatsächlich keine Historie, und die Endpunkte, die sie berühren, sagen das, statt stillschweigend Live-Daten als historische Daten zu servieren.
Fragen Sie den LSDB-Browser nach einem vergangenen Moment, trägt die Antwort:
Topology and route LSAs reflect the selected time; LSA header metadata (age/seq/ checksum) is not historized and shows live values.
Fragen Sie nach einem domänenübergreifenden Pfad zu einem vergangenen Moment, dann wächst die Erklärung um zusätzliche Schritte, aber nur dort, wo die Antwort sich tatsächlich auf Live-Belege gestützt hat:
Time travel: L2 detail is live: L2/port annotations on this path reflect current LLDP/CDP wiring, not the selected time. L2 adjacency is not historized.
Time travel: entry resolved via current router-id: identity attributes (router-id, local address) are not historized and were borrowed from the live session record.
Auf die Bedingtheit kommt es an. Ein Zusammenfügen, das sich vollständig aus der Historie belegen lässt, trägt keinen der beiden Hinweise, und deshalb bedeuten die Hinweise etwas, wenn sie doch erscheinen. Ein pauschales “manche Daten könnten live sein” auf jeder historischen Ansicht wäre technisch wahr, würde dauerhaft ignoriert und wäre nutzlos.
Es gibt noch eine Grenze, die ich unverblümt nenne, weil Sie sie sonst durch Verwirrung entdecken würden: Die Einfärbung nach Link-Auslastung ist während Time Travel abgeschaltet. Die Verkehrs-Heatmap bleibt leer, statt Ihnen Live-Last auf einer historischen Topologie zu zeigen. Das ist das sichere Verhalten und das falsche. Leer liest sich als “kein Verkehr”, wo es sich als “zu diesem Zeitpunkt nicht verfügbar” lesen sollte. Der Reader, der das beheben würde, ist eingeplant, nicht gebaut.
Der Unterschied zwischen dem, was sich änderte, und dem, was Sie erfuhren
Time Travel hat einen Begleitbericht: zwei Momente vergleichen und die Unterschiede auflisten.
In den letzten 24 Stunden in AS 200: keine Geräte hinzugefügt, entfernt oder
geändert. Keine Links hinzugefügt oder entfernt. Und 56 Stub-Netzwerke
hinzugekommen, jedes davon ein IPv6-/128-Loopback.
Das sieht nach einer Netzänderung aus. Es ist keine.
Ich habe nachgesehen, wann diese 56 Präfixe zum ersten Mal in die Datenbank kamen,
und jedes einzelne traf heute Morgen zwischen 10:00:49 und 10:01:14 ein: ein
Fenster von 25 Sekunden. Kein Netz konfiguriert 56 Loopbacks über 64 Router in
25 Sekunden um. Was passiert ist, war ein Erkennungslauf: Diese Präfixe standen
die ganze Zeit in der OSPFv3-Datenbank, und das ist der Moment, in dem Osprey
anfing, sie aufzuzeichnen.
Diese Unterscheidung verdient einen Namen, denn die beiden zu vermengen schickt Leute auf die Jagd nach einer Änderung, die nie stattgefunden hat:
Ein Topologie-Diff sagt Ihnen, was das Modell erfahren hat. Das ist nicht dasselbe wie das, was das Netzwerk getan hat.
Manchmal fällt beides zusammen: Ein Link fällt aus, das Modell zeichnet einen ausgefallenen Link auf. Manchmal nicht, und der Verräter ist meist die Form der Zeitstempel: Echte Netzänderungen treffen im Takt der Protokollkonvergenz ein, Modelländerungen im Takt eines Poll-Zyklus. Sechsundfünfzig identische Präfixe in 25 Sekunden sind ein Poll-Zyklus in den Kleidern einer Änderung.
Ein Observability-Produkt, das Ihnen nicht sagen kann, welches von beiden Sie vor sich haben, kostet irgendwann jemanden einen Nachmittag. Osprey kennzeichnet das nicht automatisch. Der Diff zeigt, was das Modell aufgezeichnet hat, und die Überlegung oben ist meine, nicht die des Werkzeugs. Aber jede Zeile trägt die Zeitstempel, die Sie brauchen, um selbst zu entscheiden, und das ist das Mindeste, das ehrliches Werkzeug Ihnen meiner Meinung nach schuldet.
Wo diese Reihe endet
Drei Serien, und eigentlich ein Argument, aus drei Richtungen erreicht.
Serie 1 ging darum, ob das Modell wahr ist: das Netzwerk so modellieren, wie es tatsächlich ist, es beobachten, ohne Teil davon zu werden, die Weiterleitung Hop für Hop reproduzieren und nicht raten.
Serie 2 ging darum, ob sich die Belege einstufen lassen: mehrere Wahrheiten gleichzeitig halten, widersprüchliche Quellen bewerten, die eigenen Fehler finden, bevor die Kunden es tun.
Serie 3 ging darum, was das einbringt: ein Modell, das korrekt genug ist, um damit zu denken. Etwas kaputt machen und sehen, was passiert. Fragen, was von was abhängt. Schätzen, was sich nicht messen lässt, und dazusagen, dass man schätzt. Fragen, was das Netzwerk eine Stunde vor dem Ausfall glaubte.
Nichts davon funktioniert auf einem Modell, dem Sie nicht vertrauen. Jede ehrliche Verweigerung aus Serie 1 und jeder eingestufte Beleg aus Serie 2 existieren, damit die Antworten aus Serie 3 etwas bedeuten: Ein What-if auf einer Topologie, die zu 9 % Fiktion ist, ist kein Planungswerkzeug, es ist ein Zufallszahlengenerator mit hübschem Canvas.
Beitrag acht hat diesem Argument seine kürzeste Form gegeben: Eine Topologie-Engine ist ein Compiler für Netzwerkzustand, mit unordentlicher, widersprüchlicher Eingabe, einem deterministischen Modell als Ausgabe und den Routern selbst als Orakel. Compiler werden an Konformität gemessen und nicht an Plausibilität, und jede Verweigerung in diesen zwölf Beiträgen ist das, was Konformität in den Fällen kostet, in denen die Antwort nicht verfügbar ist.
Bringen Sie das Modell in Ordnung. Sagen Sie, woher Sie es wissen. Und dann, erst dann, fangen Sie an, ihm Fragen zu stellen.
Die ganze Reihe: Vertrauen: Drei IGPs, eine Karte · Kein Fußabdruck · Hop-für-Hop-Wahrheit · Was Osprey nicht raten will. Die Wahrheit konstruieren: Derselbe Router, drei verschiedene Wahrheiten · Wenn das Netzwerk sich selbst widerspricht · Der Tag, an dem meine Topologie mich anlog · Die Unit-Tests eines Netzwerkingenieurs. Vom Sehen zum Schließen: Was passiert, wenn ich das kaputt mache? · Der Wirkungsradius · Schätzen, was man nicht messen kann · dieser hier.