Schätzen, was man nicht messen kann

Eine aus Link-Zählern abgeleitete Verkehrsmatrix, der Flow-Collector, den ich nicht gebaut habe, und die ehrlichen Grenzen meines eigenen Labors

22. August 2026 Michel Wijnberg

Der vorherige Beitrag hat mit Absicht eine Frage vor Schluss aufgehört. Osprey kann Ihnen sagen, dass der Ausfall von nrt1-cr1 ↔ sea1-cr1 56 Pfade ändert und niemanden isoliert. Die Frage, die eine Betreiberin als Nächstes stellt, ist die, die darüber entscheidet, ob die Änderung sicher ist:

Wohin geht der Verkehr, und läuft irgendwo etwas über?

Niemand gibt eine Änderung allein aufgrund von Pfadzahlen frei. Die Zahl, die es entscheidet, ist Kapazität: ob die Links, die den Verkehr erben, Platz dafür haben. Dieser Beitrag handelt davon, wie weit man ehrlich in Richtung dieser Zahl kommt, wenn nichts im Netzwerk sie direkt misst, und davon, wo diese Antwort aufhört, eine zu sein, auf die Sie sich stützen sollten.

Sie zu beantworten setzt voraus zu wissen, wie viel Verkehr von jeder Quelle zu jedem Ziel fließt: eine Verkehrsmatrix. Fast niemand hat eine.

Das Ding, das ich nicht gebaut habe

Der Lehrbuchweg zu einer Verkehrsmatrix ist der Flow-Export: NetFlow, sFlow, IPFIX. Router sampeln Flows, schicken Datensätze an einen Collector, und Sie aggregieren sie zu Nachfragen zwischen Quelle und Ziel.

Ich hatte das geplant. In diesem Repository liegt ein Entwurfsdokument über 1.139 Zeilen für einen Flow-Collector mit LSDB-bewusster Deduplizierung. Es ist in seiner eigenen ersten Zeile gekennzeichnet:

Status: SHELVED (2026-03-12). Deferred indefinitely after cross-plan feasibility review.

mit fünf genannten Gründen. Die beiden, die tatsächlich den Ausschlag gaben:

Volumen. 70 bis 220 GB pro Woche bei 500 Routern, also ungefähr das Hundertfache der gesamten übrigen Datenbank. PostgreSQL ist der einzige Datenspeicher in diesem Produkt, und zwar mit Absicht; eine Flow-Pipeline zu schlucken bedeutet entweder einen zweiten Datenspeicher oder eine Datenbank, die umkippt.
Geringer Zusatznutzen. Etwa 80 % der praktisch nutzbaren Verkehrssicht waren bereits aus den SNMP-Interface-Zählern verfügbar, die ohnehin schon erhoben wurden.

Das ist keine technische Unmöglichkeit. Es ist die Einschätzung, dass die letzten 20 % ein neues Teilsystem, eine neue Betriebslast und eine ganze Klasse von Speicherrisiken kosten, und ich hielt das nicht für lohnend. Vernünftige Leute sehen das anders; manche Netze brauchen Flow wirklich. Was hier zählt, ist, dass die Entscheidung samt Begründung aufgeschrieben ist, damit jeder, der Osprey bewertet, prüfen kann, ob seine Lage meiner entspricht.

Also: keine Flow-Datensätze. Womit das interessante Problem übrig bleibt.

Die Matrix aus dem ableiten, was die Links zugeben

Was Osprey hat, ist die Last jedes Links, ordentlich gemessen: 64-Bit-Zähler ifHCInOctets / ifHCOutOctets, im Takt abgefragt, zu Bit pro Sekunde differenziert, um Überläufe korrigiert und durch die Interface-Geschwindigkeit geteilt, was einen Auslastungsprozentsatz ergibt.

Das ist eine Menge von Link-Summen. Was Sie wollen, ist eine Menge von Paar-Nachfragen. Das Zweite aus dem Ersten zurückzugewinnen ist ein unterbestimmtes inverses Problem: Viele verschiedene Verkehrsmatrizen erzeugen exakt dieselben Link-Lasten. Dafür gibt es einen bekannten Ansatz: Tomogravity (Zhang, Roughan et al., 2003).

Er läuft in zwei Schritten, und Osprey setzt beide um:

// computeTrafficEstimate estimates traffic redistribution after topology
// mutations using the gravity model (Zhang/Roughan et al., "Tomogravity" 2003).
//
// Without a full traffic demand matrix, per-pair demands are estimated using
// the gravity model: demand(i,j) ∝ V(i)·V(j)/V_total, where V(i) is the
// total traffic volume at device i (derived from SNMP interface utilization).
// These gravity demands are then calibrated against observed per-link loads
// so that the model's predictions match reality.

Der Gravitationsschritt nimmt an, dass der Verkehr zwischen zwei Routern proportional zum Produkt dessen ist, was jeder von beiden insgesamt trägt, in derselben Form wie die newtonsche Gravitation oder ein Handelsmodell zwischen zwei Volkswirtschaften. Das ist eine Vorannahme, keine Messung, und sie ist auf bestimmte Weise falsch: Sie kennt kein besonders geschwätziges oder besonders stilles Nachbarpaar.

Der tomografische Schritt ist das, was sie brauchbar macht. Die Gravitationsschätzung wird so skaliert, dass die sich ergebenden Link-Lasten den gemessenen Lasten entsprechen, wenn man jede geschätzte Nachfrage über die Pfade routet, die das IGP tatsächlich wählt. Die Vorannahme wird durch Belege korrigiert, und die Belege sind hier das Einzige, was keine Vermutung ist.

Dann, und erst dann, werden die kalibrierten Nachfragen über die Pfade nach dem Ausfall neu geroutet (ECMP-gewichtet, sodass ein Paar, dessen Verkehr sich vierfach aufteilt, zu jedem Link ein Viertel beiträgt), und die Differenz ist die prognostizierte Umverteilung.

Drei bewusst unspektakuläre Entscheidungen

Die interessante Ingenieursarbeit in einem Schätzer steckt ganz in den Stellen, an denen man ihn davon abhält, selbstbewusst zu sein.

Global kalibrieren, nicht je Link. Die verlockende Variante berechnet für jeden Link einen eigenen Skalierungsfaktor. Sie passt besser zu den Daten und ist viel schlechter:

// Compute a GLOBAL calibration factor: total observed bps / total gravity sum.
// Per-link calibration can amplify noise when gravitySumPerLink is small
// relative to observed traffic, producing extreme scaling factors that
// inflate per-pair demands unrealistically. Global calibration distributes
// the error uniformly, producing more stable and realistic results.

Ein stiller Link mit einer Gravitationssumme nahe null und ein wenig gemessenem Verkehr erzeugt einen gewaltigen Skalierungsfaktor, der dann jedes Paar aufbläht, das ihn kreuzt. Die engere Anpassung erkauft Ihnen gelegentlichen Unsinn. Ein einziger globaler Faktor verteilt den Fehler gleichmäßig und explodiert nie.

Jedes einzelne Paar auf 5 % des Gesamtvolumens deckeln. Eine harte Obergrenze dafür, wie viel vom Netz eine geschätzte Nachfrage sein darf, denn der Fehlermodus eines inversen Problems ist, dass ein Paar alles aufsaugt.

Sich weigern, kleine Änderungen zu melden. Eine prognostizierte Verschiebung unter 0,5 % der Link-Auslastung wird verworfen, und 0,1 % auf dem Kostenänderungspfad, der auch hypothetische Links und Knoten trägt und die Wirkung eines neuen Transitknotens dünn über viele Links verteilt. Darunter ist die Zahl von Zähler-Rauschen nicht zu unterscheiden, und sie auszugeben lädt jemanden dazu ein, auf Rauschen zu reagieren.

Jede dieser Entscheidungen lässt die Ausgabe weniger präzise aussehen. Präzision ist nicht das Ziel; das Ziel ist, dass eine Zahl auf dem Bildschirm eine ist, auf die Sie sich stützen können.

Und jetzt der Teil, bei dem mein Labor mir nicht helfen kann

Alles in den vorherigen acht Beiträgen wurde gegen ein Labor validiert, das mir widersprechen konnte. 4.032 Routerpaare gegen echte Routing-Tabellen geprüft. 360 erfundene Korridore gefunden. Drei Protokolle, drei Erkennungswege, die sich über denselben Single Point of Failure einig waren.

Beim Verkehr ist das Labor nahezu nutzlos, und ich will genau sagen, warum.

Die Router in diesem Labor leiten fast nichts weiter. Sie fahren Protokolle, sie tauschen LSAs und BGP-Updates aus, und das ist im Wesentlichen alles. Die Messwerte:

Messung	Wert
Interfaces mit Auslastungsdaten	1.279
…unter 0,05 % Auslastung	1.241
Höchste Auslastung überhaupt	0,431 %, auf einem 10-Mbps-Port
Höchste Interface-Rate überhaupt	~43 kbps
Spitze über die 368 Interfaces mit 10 Gbps Nennleistung	~24 kbps, also 0,00024 %

Die Folge sehen Sie im Simulations-Screenshot aus dem vorherigen Beitrag, wenn Sie wissen, wohin Sie schauen müssen. Die Kopfzeile der ausgefallenen Links liest sich “2 links, 6Kbps displaced”, sechs Kilobit, und das Panel zeigt keinen Abschnitt zur Verkehrsumverteilung und überhaupt kein Congestion-Risiko. Nicht, weil der Code nicht gelaufen wäre. Sondern weil jede prognostizierte Verschiebung unter dieser Rauschgrenze von 0,5 % lag und korrekterweise verworfen wurde.

Die Mechanik ist nachweislich richtig: Zähler werden gelesen, Raten differenziert, Gravitationsnachfragen gebildet, die Kalibrierung läuft, die Umverteilung wird über die ECMP-Pfade nach dem Ausfall berechnet, und die Rauschgrenze verwirft, was sie verwerfen soll. Was das Labor mir nicht sagen kann, ist, ob die Schätzung irgendetwas taugt, denn einen Schätzer zu validieren erfordert eine gesicherte Wahrheit zum Vergleich, und gesicherte Wahrheit heißt hier echter Verkehr mit bekannter Quelle-Ziel-Matrix.

Ein Labor ohne Verkehr kann keine erzeugen. Synthetische Last hinzuzufügen würde es auch nicht richten: Ich würde Verkehr aus einer Matrix erzeugen, die ich gewählt habe, und dem Schätzer dann dazu gratulieren, dass er genau die Matrix zurückgewinnt, die ich ihm gerade gefüttert habe. Das ist keine Validierung, das ist eine sehr langsame Art, meine eigene Rechenkunst zu prüfen.

Wie sehr sollten Sie ihm also vertrauen?

Hier die ehrliche Leiter, in der Reihenfolge, in der die Zahlen weniger fest werden:

Link-Auslastung, live und historisch: gemessen. 64-Bit-Zähler, differenziert, um Überläufe korrigiert, gegen die Interface-Geschwindigkeit auf Plausibilität geprüft. Das sind Daten.
Welche Pfade sich nach einer Veränderung ändern: aus der Topologie berechnet. Deterministisch, und die Topologie darunter ist die, die gegen 4.032 Routerpaare validiert wurde.
Wie viel Verkehr auf jeden Link wandert: geschätzt, aus einer Gravitations-Vorannahme, korrigiert durch gemessene Link-Lasten. Der Richtung nach nützlich, gegen echte Belege kalibriert, und keine Messung.

Sprosse 3 ist wirklich wertvoll. Sie ist der Unterschied zwischen “diese zwölf Links fangen den Ausfall auf” und “dieser eine Link fängt das meiste davon auf und liegt bereits bei 70 %”. Sie ist zugleich die einzige Sprosse in dieser ganzen Reihe, neben die ich keine Validierungszahl schreiben kann, und es wäre unehrlich, sie im selben Tonfall zu präsentieren wie “4.032 von 4.032”.

Das Produkt zieht diese Linie, wo es kann. Wenn der Verkehr eines BGP-Peers aus Präfix-Verhältnissen abgeleitet werden muss statt aus einem zugeordneten SNMP-Interface, trägt die Zeile einen Tooltip, der genau das sagt: “Traffic estimated from prefix count ratios (no SNMP interface match)”, direkt neben Zeilen mit dem Kennzeichen SNMP, die aus Zählern stammen. Dieselbe Tabelle, abgestuft, und das ist das Muster, bei dem diese ganze Reihe immer wieder landet; dies ist das dritte Mal, dass es dieselbe Form annimmt. Ein domänenübergreifender Pfad stuft seine Segmente als resolved / inferred / opaque ein (Beitrag vier); eine Port-Annotation stuft ihre vier Urteile von der ausgesprochenen Tatsache bis zur ausdrücklichen Mehrdeutigkeit ein (Beitrag sechs); die drei Sprossen oben stufen eine Verkehrszahl ein. Drei Leitern, eine Gewohnheit: Wo die Belege unter einer Antwort ungleichmäßig sind, stufe sie an Ort und Stelle ein, statt eine einzige Sicherheit für das Ganze auszugeben.

Wofür das Labor da ist, neu formuliert

Beitrag sieben argumentierte, dass das Labor nicht dazu da ist, Osprey gut aussehen zu lassen, sondern dazu, Osprey zu widerlegen. Dieser Beitrag ist die Folgerung, die niemandem Freude macht: Ein Labor kann nur die Dinge widerlegen, die es überhaupt in Gang setzen kann.

Meines ist außerordentlich gut darin, mir bei Topologie, Protokollsemantik und Weiterleitung zu widersprechen, weil es 192 echte Router mit echten Routing-Tabellen hat, die ich lesen und vergleichen kann. Es ist außerstande, mir beim Verkehr zu widersprechen, weil es keinen trägt.

Zu wissen, in welcher der beiden Lagen Sie sich für jede Zahl befinden, die Ihr Produkt ausgibt, macht den größten Teil des Unterschieds zwischen einem Werkzeug, dem man vertrauen kann, und einem, das nur selbstbewusst ist. Ich weiß genau, welche Aussagen in Osprey durch Messung gedeckt sind, welche durch Berechnung über ein validiertes Modell, und welche durch einen Schätzer, an den ich glaube, den ich hier aber nicht beweisen kann.

Dieser Beitrag ist die dritte Kategorie. Es gibt genau eine davon, und jetzt wissen Sie, wo sie steckt.

Als Nächstes der letzte Beitrag dieser Reihe: Das Modell stimmt, und es ist auch ein Modell des Jetzt. Wie sah das Netzwerk eine Stunde aus, bevor es kaputtging? Das Netzwerk hat ein Gedächtnis.