Zusammenfassung

  • Das Informationsmodell richtet die Discard-Klassifikation auf Geräte-, Interface- und Flow-Ebene aus. Gleichartige Klassen erleichtern Korrelation, stellen aber keine Identität her.
  • Der Entwurf verlangt für künftige Flow-Datenmodelle eine Verankerung, damit Discards eindeutig einem Flow zugeordnet werden. Zeitnähe und ähnliche Volumina sind Evidenz, kein Schlüssel.

Ein Interface meldete 18 400 eingehende Policy-Discards. Ein Flow-Exporter meldete im selben Zeitfenster fast dieselbe Zahl für einen Kundendatenstrom. Das Analysewerkzeug verband beide Reihen und erklärte: Diese ACL hat genau diesen Kundenfluss verworfen.

Später zeigte sich, dass der Exporter nach einem Failover eine andere Beobachtungsdomäne verwendet hatte. Die Flow-Identität war lokal neu vergeben worden. Die beiden Zahlen beschrieben verschiedene Verkehrsmengen. Die Korrelation war statistisch elegant und sachlich falsch.

Der OPSAWG-Entwurf Information and Data Models for Packet Discard Reporting will solche Analysen verbessern. Revision 16 trägt das Datum 30. Juli 2026 und läuft am 31. Januar 2027 aus. Am Recherche-Stichtag 2. Oktober war sie ein aktiver Internet-Draft mit angestrebtem Status Proposed Standard, beim IESG eingereicht und in der RFC-Editor-Queue zur Zuweisung. Eine RFC-Nummer gab es noch nicht.

Der Entwurf standardisiert eine präzisere Klassifikation als die alten Interface-Aggregate. Er enthält eine Flow-Komponente, damit Flow-Discards dieselben Klassen wie Geräte und Interfaces verwenden können. Das ist semantische Ausrichtung. Die Charakterisierung und Identifikation eines Flows bleibt dem darunterliegenden Datenmodell überlassen. Künftige Modelle müssen die Struktur so verankern, dass die Zuordnung eindeutig ist.

Gleiche Semantik ist nicht gleiche Identität

Zwei Datensätze können beide policy/l3/acl korrekt verwenden und dennoch verschiedene Ereignisse beschreiben. Sie können auf unterschiedlichen Geräten, an verschiedenen Punkten eines Tunnels, vor und nach NAT, in abweichenden Zeitfenstern oder mit verschiedenen Sampling-Raten entstanden sein.

Auch eine Five-Tuple-Ähnlichkeit genügt nicht immer. Adressübersetzung verändert Tupel. Load Balancer teilen Sessions. Encapsulation verbirgt innere Flows. ECMP verteilt Pakete. Ein Neustart kann Export-Domain, Sequenz oder lokale Kennung ändern. Ein eindeutiger Anker braucht Beobachtungsdomäne, Messpunkt, Zeit, Richtung und eine Identität, deren Lebenszyklus definiert ist.

Ohne diese Provenienz erzeugt die Plattform Genauigkeit aus Nähe. Sie nimmt zwei wahrheitsgemäße Aussagen und erfindet die Beziehung zwischen ihnen.

Korrelation ersetzt weder Absicht noch Wirkung

Selbst eine richtige Zuordnung beantwortet noch nicht, ob der Discard beabsichtigt war. Der Entwurf sagt ausdrücklich, dass Geräte-Zähler die Betreiberabsicht nicht feststellen. Klasse, lokale Policy, konfigurierte Absicht, Baseline, Dauer, Umfang, Servicekontext und weitere Evidenz müssen zusammenkommen.

Ein ACL-Discard kann eine genehmigte Sicherheitsregel oder eine Fehlkonfiguration sein. Ein No-Route-Discard kann durch Konvergenz, falsche Konfiguration oder ungültige Ziele entstehen. Ein Flow-Anker beweist, welcher Verkehr betroffen war; er beurteilt nicht die Rechtmäßigkeit oder Zweckmäßigkeit der Regel.

Auch Kundenwirkung bleibt eine eigene Beobachtung. Wiederholte Pakete, Scans und produktive Transaktionen tragen unterschiedliches Gewicht. Die Anzahl verlorener Pakete ist kein Ersatz für Service-Semantik.

Ein Kausalgraph braucht Kantenbelege

Heng Lus Realitätsschichten zeigen den institutionellen Fehler: Der Packet-Discard ist Ausführung, der Counter ein Datensatz, die Klasse ein Label, die Flow-Verknüpfung eine Identitätsbehauptung, die Ursache eine Hypothese und die Mitigation eine neue Handlung. Häufig prüfen Systeme die Knoten, aber nicht die Kanten.

Eine Minimum Initial Specification sollte deshalb für jede Korrelation den Anker speichern: Export-Domain, Observation Point, Interface, Richtung, Zeitfenster, Sequenz, Sampling, Encapsulation- und NAT-Kontext sowie Reset-Zustand. Wenn nur probabilistische Übereinstimmung möglich ist, gehört eine Konfidenz und eine Liste offener Alternativen dazu.

Running-Code Primacy macht die Kante prüfbar. Flows werden über NAT, Tunnel, ECMP und Failover geschickt. Exporter werden neu gestartet. Zeitfenster werden verschoben. Sampling wird verändert. Die Plattform muss eine gebrochene Identität als gebrochen zeigen, statt sie mit ähnlichen Zahlen zu reparieren.

Die Stärke eines standardisierten Modells liegt darin, dass Systeme dasselbe Vokabular benutzen können. Seine Grenze liegt darin, dass ein gemeinsames Wort zwei Ereignisse nicht automatisch zu demselben Ereignis macht.

Quellen