Zusammenfassung

  • Der aktive Regelsatz konnte Protokolle verwerfen, die Richtung für einen zweiten Vergleich drehen, Adressen maskieren, nur ausgewählte Attribute übernehmen und das spätere Ausgabeformat bestimmen.
  • NeTraMet übersetzte passende Regelgruppen in Hash-Suchen und ersetzte vollständige Masken durch Ein-Byte-Indizes. Dadurch wurden auch Build-Grenzen Teil des Datensatzkontexts.
  • Bei hoher Tabellenauslastung wechselte der Zähler von Produktions- zu gröberen Standby-Regeln und am FloodMark zum Default; nach einem Neustart lief zunächst ebenfalls der Default-Regelsatz.

Vor dem Zählen stand die Auswahl

RFC 2123 erschien im März 1997 als Informational-Dokument und hielt drei Jahre Erfahrung mit der RTFM-Architektur fest. Das Modell trennte Meter, Meter Reader, Manager und Analyse. NeTraMet setzte den Meter um; NeMaC verband Management und Auslesen.

Eine Zeile entstand erst, nachdem NeMaC einen Regelsatz geladen hatte. Die Packet Matching Engine konnte Attribute prüfen, Werte in einen Flow übernehmen, Pakete ignorieren, zu einem anderen Zweig springen oder Source und Destination vertauschen und erneut vergleichen. Die Regeldatei enthielt zudem das Format, das der Reader tatsächlich abholen und speichern sollte.

Damit war Richtung keine überall identische Eigenschaft. Ein Regelsatz konnte den lokalen Netzrand, ein Gateway oder einen bekannten Port zur Quelle der Darstellung machen. Das erleichterte Auswertungen, blieb aber eine Konvention, die zusammen mit den Zahlen erhalten werden musste.

Der RFC-Editor-Eintrag und der IETF Datatracker grenzen das Dokument als Erfahrungsbericht ab, nicht als Internet Standard oder Abnahme aller Installationen. Die aktuelle offizielle Errata-Suche zu RFC 2123 findet keinen Eintrag. Daraus folgt keine Garantie für Implementierungen oder Berichte.

Verworfener Verkehr hinterließ keinen Beleg seiner Abwesenheit

Wenn nur IP interessierte, musste NeTraMet Novell- oder EtherTalk-Pakete nicht puffern und weiter analysieren. Das Programm las aus dem aktiven Regelsatz die interessierenden Peer-Typen ab. Andere Typen wurden nach der Erkennung verworfen. Ebenso entfiel das Kopieren von Adjacent-Adressen, wenn keine Regel sie testete.

Diese Optimierung war effizient und irreversibel. Eine vollständige IP-Datei konnte den ausgewählten IP-Verkehr beschreiben, aber nicht die Abwesenheit anderer Protokolle belegen. Die Architektur aus RFC 2063 wollte Datenreduktion bewusst nahe am Messpunkt platzieren. Was dort nicht ausgewählt wurde, stand später nicht für eine neue Frage bereit.

Die ausführbare Form prägte den Datensatz

Adressklassifikationen konnten Hunderte Tests umfassen. NeTraMet suchte Gruppen, die dasselbe Attribut mit derselben Maske prüften, und baute vor dem Start Hash-Tabellen. Kleine Gruppen blieben sequenziell, weil eine beim Kompilieren festgelegte Mindestgröße entschied, wann Hashing lohnte.

Für jede maskierte Adresse musste zudem erkennbar bleiben, ob ein Bit wirklich null oder nur ausgeblendet war. Die beschriebene Version führte eine Maskentabelle und speicherte pro Flow einen Ein-Byte-Index. Die Zahl möglicher Masken war beim Build begrenzt, bis maximal 256.

Das machte anspruchsvolle Regeln auf damaliger Hardware möglich. Zugleich zeigte es, warum eine Zeile nicht losgelöst vom ausführbaren Regelsatz gelesen werden durfte: Die Adresse war bereits maskiert, die Klasse folgte einem Regelpfad, und die Ausdrucksfähigkeit hing von Compilergrenzen ab.

Speicherknappheit konnte die Messfrage während des Betriebs ändern

Die maximale Flowzahl wurde beim Start gesetzt. Ein inkrementeller Garbage Collector gab inaktive Zeilen frei, wenn bekannte Reader weit genug fortgeschritten waren. Blieb die Sammlung zurück, näherte sich die Tabelle trotzdem ihrer Grenze.

Oberhalb HighWaterMark konnte ein Standby-Regelsatz übernehmen. In Auckland ähnelte er der Produktion, legte jedoch viel weniger Information ab. Dadurch blieb ein Meter nach Ausfall des Readers mitunter noch ein oder zwei Tage aktiv; später ließen sich kumulierte Werte einsammeln.

Am FloodMark schaltete NeTraMet auf den eingebauten Default-Regelsatz, bevor die Speicherbereinigung so viel Rechenzeit beanspruchte, dass Management-Anfragen ausfielen. 65 und 95 Prozent funktionierten in der beschriebenen Praxis gut, waren aber keine universellen Grenzwerte.

Verfügbarkeit und semantische Kontinuität waren damit verschieden. Produktion, Standby und Default konnten jeweils gültige Zeilen erzeugen, aber andere Attribute und Granularitäten abbilden. Ein laufender Prozess garantierte nicht dieselbe Beobachtungsfrage.

Nach dem Neustart kam zuerst der Default

Ein neu gestarteter Meter begann mit dem eingebauten Regelsatz 1. NeMaC verglich regelmäßig sysUptime; ein kleinerer Wert zeigte den Neustart. Dann lud der Manager Backup- und Produktionsregeln neu und aktivierte die Produktion.

Im dokumentierten Alltag betrugen Keepalive und Sammelintervall fünf beziehungsweise fünfzehn Minuten. Bis zum Neuladen konnten laut RFC bis zu fünf Minuten Daten verloren gehen. Diese Spanne ergab sich aus der lokalen Konfiguration. Währenddessen konnte der Default den Verkehr anders schneiden.

Ein erneut steigender Zähler verband die Zeitreihen daher nicht automatisch. Regelidentität, Uptime-Grenze und Abschluss der Wiederherstellung gehörten dazu.

FlowIndex war eine wiederverwendbare Position

Nach der Freigabe einer Tabellenzeile durfte ihr FlowIndex einem neuen Flow gehören. RFC 2123 verlangte deshalb FlowRuleSet, FlowIndex und StartTime gemeinsam als eindeutige Kennung. Der Index allein war kein dauerhaftes Objekt.

Auch das Auslesen war kein atomarer Schnappschuss. NeMaC las ausgewählte Spalten; eine Zeile, die erst nach einer früheren Spalte aktiv wurde, kam beim nächsten Durchgang an die Reihe. Der Meter MIB aus RFC 2064 stellte die zugehörigen Steuerobjekte bereit. Die spätere Architektur aus RFC 2722 von 1999 darf nicht rückwirkend als Zustand aller Installationen von 1997 gelten.

Auch Leistungsangaben blieben ortsgebunden: ungefähr 750 Pakete pro Sekunde auf einem 10-MHz-286, 1.250 auf einem 25-MHz-386SX und gemeldete Spitzen um 3.000 auf einem 40-MHz-486 ohne Verlust. Solche Werte belegten weder universelle Vollständigkeit noch Abrechnungsbefugnis, Integrität oder Vertraulichkeit. Für Letztere verwies RFC 2123 auf Management- und Sammelprotokolle.

Lu Hengs spätere Running-Code Primacy lenkt den Blick auf die tatsächlich ausgeführte Konfiguration. Minimum Initial Specification verhindert, dass eine lokale Wahl zur allgemeinen Autorität wird. Reality Layers trennt Dokument, Implementierung, Datensatz und Wirkung. Das sind spätere Deutungsrahmen, keine historischen Belege für die Absicht des RFC-Autors.

Das bleibende Ergebnis von RFC 2123 ist eine Beweiskette: Der Manager stellte die Frage, der Meter projizierte Pakete, Knappheit änderte die Auflösung, der Reader gewann eine nicht atomare Sicht, die Analyse formulierte den Befund. Die Zeile war dann stark, wenn diese Kette sichtbar blieb — nicht wenn sie sich als neutrale Kopie des Kabels ausgab.

Quellen