Zusammenfassung

  • Anja Feldmann und fünf weitere Forscher beschrieben Nachfrage als Volumen von einem Eingangslink zu einer Menge möglicher Ausgänge. So blieb das Verkehrsangebot vom aktuell gewählten Pfad getrennt.
  • Im IP-Backbone von AT&T verband das Team NetFlow, Forwarding-Tabellen, Routerkonfigurationen und SNMP-Kontrollen. Verluste, zeitlich unpassende Schnappschüsse und mehrdeutige Eingänge blieben als Grenzen des Ergebnisses sichtbar.

Ein Link erreicht 95 Prozent Auslastung. Die operative Reaktion liegt nahe: Gewicht ändern, Verkehr umleiten, Kapazität schaffen. Doch der Zähler des Links sagt nicht, welche Nachfragen den Wert erzeugt haben. Er kann auch nicht vorhersagen, auf welchem anderen Link dieselben Bytes nach einer OSPF-Änderung erscheinen werden.

Genau dieses Problem bearbeiteten Anja Feldmann, Albert Greenberg, Carsten Lund, Nick Reingold, Jennifer Rexford und Fred True gemeinsam. Ihre Verkehrsmatrix war kein fertiges Messobjekt in einem Router. Sie entstand erst, als mehrere unvollständige Datenbestände miteinander verbunden und gegen die damalige Netzkonfiguration geprüft wurden.

Linklast ist eine Wirkung. Nachfrage ist das Verkehrsvolumen, das das Netz transportieren soll. Topologie und Routing bilden den Mechanismus dazwischen. Wer die heutige Wirkung mit der Nachfrage gleichsetzt, baut den heutigen Pfad in ein Modell ein, das eigentlich eine andere Konfiguration beurteilen soll.

Die Nachfrage darf ihren Namen nicht mit jedem Pfad wechseln

Eine Matrix für jedes Paar von Quell- und Zieladressen wäre riesig gewesen. Zudem besaß kein einzelner Provider die nötige Ende-zu-Ende-Sicht. Der größte Teil des Internetverkehrs durchquerte mehrere administrative Domänen; ein ISP sah nur den Abschnitt im eigenen Backbone.

Die Forschungsgruppe wählte deshalb eine kontrollierbare Abstraktion. Eine Nachfrage bestand aus einem Eingangslink, einem Volumen und der Menge von Ausgangslinks, über die das Zielpräfix erreichbar war. Eine BGP-Änderung konnte diese Menge verändern. Welches Mitglied tatsächlich genutzt wurde, hing von internem Routing und aktueller Konfiguration ab.

Damit blieb die Nachfrage bei einer Änderung des OSPF-Gewichts bestehen; nur ihre Verteilung auf interne Links änderte sich. NetScope, das verwandte System von fünf Teammitgliedern, konnte so einen überlasteten Link finden, die dort verlaufenden Nachfragen bestimmen und eine neue Konfiguration in einer Simulation prüfen, bevor das produktive Netz verändert wurde.

Auch die Zeitauflösung folgte dem Zweck. Für Traffic Engineering waren Intervalle von Dutzenden Minuten bis zu Tagen wichtiger als die Reihenfolge einzelner Pakete. Flow-Datensätze konnten Zeitfenstern zugeordnet und nach Eingang und Ausgangsmenge aggregiert werden. Das Modell sollte keine Sitzung nachspielen, sondern die Folgen einer Netzentscheidung erklären.

Vier Quellen mussten denselben Zustand meinen

Ideal wären Flow-Messungen an allen Eingangslinks gewesen. Ein Datensatz lieferte Eingangsinterface, Zieladresse, Beginn, Ende und Bytezahl. Forwarding-Tabellen ordneten Zielpräfixe möglichen Ausgängen zu. Konfigurationsdateien beschrieben Linknamen, Rollen, Kapazitäten, Filter und OSPF-Parameter. Das Routingmodell prüfte schließlich die möglichen Wege.

Im AT&T-Netz ließ sich die Messung nicht auf jedem Kundenzugang aktivieren. Manche Router unterstützten sie nicht, andere hätten dafür zu viele Ressourcen benötigt. Die Forscher konzentrierten sich auf Peering-Links, an denen leistungsfähige Geräte einen großen Anteil des Providerverkehrs verarbeiteten.

Der Kompromiss hatte drei ausdrücklich benannte Lücken. Interner Verkehr zwischen zwei Kundenzugängen konnte die Peerings umgehen. Ausgehender Verkehr wurde am Ausgang beobachtet, nicht an seinem ursprünglichen Eingang. Mehrstufiger Transit konnte sowohl beim Eintritt als auch beim Austritt aufgezeichnet und damit doppelt gezählt werden.

Für einen ausgehenden Flow ergab die Quelladresse daher zunächst mehrere mögliche Kundenzugänge. Das Routingmodell prüfte jeden Kandidaten: Hätte der Flow unter Topologie und Konfiguration dieses Zeitpunkts das tatsächlich beobachtete Peering-Interface erreichen können? Unmögliche Eingänge wurden ausgeschlossen.

Manchmal blieb genau einer, manchmal mehrere, manchmal keiner. Mehrdeutiges Volumen wurde verteilt und nicht einer erfundenen eindeutigen Quelle zugewiesen. Die Zellen der Matrix hatten damit unterschiedliche Herkunft: beobachteter Ausgang, eindeutig erschlossener Eingang, verbleibende Kandidatenmenge oder Widerspruch zum Schnappschuss.

Telemetrie kann selbst zum überlasteten Verkehr werden

NetFlow exportierte seine Datensätze per UDP an einen Sammler. Unter hoher Last gingen auf dessen Zuleitung bis zu 90 Prozent der Exportpakete verloren. Die empfangene Kurve blieb dennoch plausibel und bewegte sich weiter. Gerade deshalb hätte sie ohne Gegenprobe als vollständige Messung gelten können.

Sequenznummern machten die Lücken erkennbar. Ihr Muster stützte eine näherungsweise unabhängige Verlustannahme. Das Team berechnete für Zehn-Minuten-Intervalle eine Verlustwahrscheinlichkeit und skalierte die empfangenen Flows entsprechend. Das stellte keine einzelnen verlorenen Datensätze wieder her. Es war eine statistische Hochrechnung mit offengelegter Annahme.

SNMP-Zähler lieferten eine unabhängige Prüfung. Sie erfassten alle fünf Minuten die Bytes eines Interfaces. Nach der Korrektur verlief die aus NetFlow rekonstruierte Auslastung relativ nah an den SNMP-Werten. SNMP enthielt nicht die Nachfragebeziehungen, konnte aber prüfen, ob deren Summe auf Linkebene stimmte.

Hinzu kamen Identitäts- und Zeitprobleme. NetFlow bezeichnete Interfaces mit numerischen SNMP-Indizes; Konfiguration und Forwarding nutzten Namen und IP-Adressen. Uhren einzelner Interfacekarten waren nicht immer mit dem Route Processor synchron. Die vier Quellen wurden zudem zu unterschiedlichen Zeiten aufgenommen. Korrekte Tabellen aus unvereinbaren Momenten konnten zusammen einen Netzzustand ergeben, der nie existiert hatte.

Ein auffälliger Versuchstag zeigte diese Gefahr. Ein Zugangslink war nach dem Konfigurationsabzug modernisiert worden, eine spätere Forwarding-Tabelle kannte bereits den neuen Link. Kundenpräfixe ließen sich nicht mehr mit der alten Identität verbinden, und die Fehlzuordnungen stiegen. Die Berücksichtigung des tatsächlichen Austauschs brachte die Rate in die Nähe der übrigen Tage zurück. Der Widerspruch war kein lästiger Datenfehler, sondern ein Hinweis auf zwei verschiedene Versionen des Netzes.

Fast vollständige Abdeckung ist keine eindeutige Zuordnung

In vier Versuchen im November 1999 ließen sich üblicherweise mehr als 98 Prozent der an Peerings beobachteten Bytes einer Nachfrageform zuordnen. Für ausgehenden Verkehr fand sich bei mehr als 99,3 Prozent zumindest ein möglicher Eingang. Gleichwohl hatten anfangs etwa 35 bis 45 Prozent dieses Volumens mehrere Eingangskandidaten.

Das Routingmodell verringerte die Menge. Je nach Lauf ließ sich etwa ein Viertel bis ein Drittel des mehrdeutigen Volumens auf einen Eingang reduzieren. Redundante Zugänge desselben Kunden in derselben Stadt blieben oft ununterscheidbar und nahmen ähnliche interne Wege. Am Ende waren rund 2,5 bis 4 Prozent der ausgehenden Bytes keiner konsistenten Nachfrage zuzuordnen.

Diese Zahlen stammen aus vier Tagen eines Netzes von 1999. Sie sind kein heutiger Leistungswert. Dauerhaft wichtig ist ihre Buchführung: Hohe Volumenabdeckung beantwortet nicht automatisch die Frage nach dem eindeutigen Ursprung. Ein kleiner Rest kann gerade jene Routingbewegungen enthalten, die für den Betrieb entscheidend sind.

Die Analyse zeigte außerdem eine starke Konzentration auf wenige große Nachfragen, deutliche Tageszeitmuster und eine gewisse Stabilität der größten Gruppen über aufeinanderfolgende Tage. Selektives Messen konnte damit viel Nutzen bringen. Zugleich erhöhte die Konzentration die Folgen einer Fehlkonfiguration oder eines plötzlichen Verhaltenswechsels.

Eine belastbare Matrix nennt ihr Verfallsdatum

Feldmanns Forschung verbindet Verkehrsanalyse, Modellierung und Routing, weil keines dieser Felder allein genügte. Messungen ohne Routingzustand beschrieben nur die Wirkung. Ein Routingmodell ohne gemessene Nachfrage verteilte erfundenen Verkehr. Eine undatierte Konfiguration erklärte womöglich sehr genau ein Netz, das bereits verschwunden war.

Die Matrix blieb eine zeitgebundene Rekonstruktion mit Korrekturen, Kandidaten und Restfehlern. Gerade diese Begrenzung machte sie für Entscheidungen brauchbar. Sie konnte zeigen, woher die Last wahrscheinlich kam, wohin sie nach einer Änderung gehen konnte und welcher Teil der Antwort beobachtet oder erschlossen war.

Für heutige Observability gilt dieselbe Zumutung. Neben dem Rohzähler müssen Routing- und Konfigurationsversion, Sammelverlust, Interfacezuordnung, ungelöste Kandidaten und unabhängige Kontrollmessung erhalten bleiben. Der rote Link zeigt den Ort des Problems. Erst die nachvollziehbare Matrix zeigt, ob die geplante Abhilfe das Problem nur verlagert.

Quellen