Zusammenfassung

  • Der ursprüngliche 32-Bit-Zähler von SNMP sprang nach seinem Höchstwert ordnungsgemäß auf null. Ein kleinerer Folgewert war daher weder Rückwärtsverkehr noch automatisch ein Neustart.
  • Schnellere Leitungen verkürzten die Umlaufzeit. 64-Bit-Hochkapazitätszähler verlängerten das Beobachtungsfenster, während die unteren 32 Bit für alte Manager sichtbar blieben.
  • Mehr Breite löst keinen Reset. sysUpTime und ifCounterDiscontinuityTime begrenzen die Messepoche; zeigt einer der Werte einen Bruch zwischen zwei Polls, muss die berechnete Differenz verworfen werden.

Die Leitung lief weiter, die Zahl sprang zurück

Ein Poll liefert beinahe 4,3 Milliarden Oktette, der nächste nur noch einige Millionen. Link und Paketweiterleitung waren ununterbrochen verfügbar. Gewöhnliche Subtraktion ergibt dennoch eine negative Zahl.

Wer jeden Rückgang zum Reset erklärt, verliert den echten Verkehr über der Obergrenze. Wer immer einen Umlauf ergänzt, erfindet nach einem Neustart Milliarden Oktette. Eine Rate braucht deshalb nicht nur zwei Werte, sondern auch Zählerbreite, Zeitabstand und die Gewissheit, dass beide Werte derselben Messgeschichte entstammen.

Ein Diagramm kann all das hinter einer glatten Linie verstecken. Das Protokollmodell hält fest: Die Identität einer Schnittstellenzeile kann länger leben als die Vergleichbarkeit ihrer Messwerte.

Der Umlauf gehörte schon zum ersten Counter

RFC 1155 definierte 1990 Counter als nichtnegative Ganzzahl, die bis 2^32-1 steigt und anschließend bei null weiterzählt. Der Umlauf ist eine reguläre Folge im endlichen Wertebereich. Er widerruft keine früheren Ereignisse und meldet keinen Hardwarezustand.

RFC 1213 verankerte diese Semantik in MIB-II. Schnittstellenzeilen enthielten ifInOctets, ifOutOctets und Paketzähler; sysUpTime und ifLastChange lieferten zeitlichen Kontext. Der Zähler selbst trug jedoch weder absoluten Beginn noch Zahl der bereits vollendeten Umläufe.

RFC 2578 formulierte die Grenze in SMIv2 ausdrücklich. Counter32 und Counter64 besitzen keinen festgelegten Anfangswert; eine einzelne Probe hat deshalb im Allgemeinen keinen Informationsgehalt. Beide laufen um. Der größere Typ verschiebt lediglich die Wiederverwendung eines Werts.

Innerhalb einer durchgehenden Epoche lässt sich ein einzelner möglicher Umlauf modular berechnen. Ist die Lücke lang genug für mehrere Umläufe, verraten die beiden Endpunkte deren Anzahl nicht mehr.

Geschwindigkeit machte Zahlenbreite zur Pollingfrist

Mit jedem schnelleren Medium schrumpfte das sichere Fenster. RFC 1573 berechnete unter der dort genannten Vollast, dass ein 32-Bit-Oktettzähler bei 10-Mb/s-Ethernet nach etwas mehr als 57 Minuten, bei FDDI nach 5,7 Minuten und bei 1 Gb/s nach ungefähr 34 Sekunden umlaufen kann. RFC 2863 übernahm diese Warnung.

Immer häufigeres Polling verbraucht Rechenzeit und Managementbandbreite; ein verpasster Abruf kann weiterhin einen ganzen Umlauf verbergen. Auch eine Skalierung auf Blöcke von beispielsweise 1.024 Oktetten wurde verworfen. Bei geringer Last bliebe der Wert lange stehen und spränge dann, sodass gleichmäßiger Verkehr wie ein Burst erschiene.

Gewählt wurde der breitere Typ. RFC 1573 führte 64-Bit-Hochkapazitätsgruppen ein. RFC 2863 verlangt bis 20 Mb/s 32-Bit-Oktett- und Paketzähler, oberhalb davon 64-Bit-Oktettzähler und ab 650 Mb/s zusätzlich 64-Bit-Paketzähler.

Diese Schwellen waren ein Kompromiss zwischen Agentkosten, damaliger Implementierungsbreite und Umlaufrisiko. Sie machten die Breite nicht zum Gütesiegel einer Messung.

Das neue Fenster ließ das alte bestehen

Die bisherigen Objekte wurden nicht abgeschafft. Existiert ein Hochkapazitätszähler, bleibt sein 32-Bit-Gegenstück als untere 32 Bit des 64-Bit-Werts verfügbar. Ein alter Manager kann weiterarbeiten; ein neuer erhält einen wesentlich längeren Zeitraum ohne gewöhnliche Umlaufmehrdeutigkeit.

Beide Ansichten stimmen modulo 2^32 überein, tragen aber nach einer langen Pollinglücke nicht dieselbe Aussage. Ein stiller Wechsel von ifInOctets zu ifHCInOctets ändert die historische Reichweite der Zeitreihe, selbst wenn Port und Bezeichnung unverändert bleiben.

Auch Counter64 ist kein endloses Hauptbuch. RFC 2578 schreibt den Umlauf nach 2^64-1 vor. Breite verringert die Häufigkeit; sie verhindert weder Reinitialisierung noch Neuerzeugung, Probenausfall oder Bedeutungswechsel.

Dieselbe Schnittstelle konnte eine neue Messgeschichte beginnen

Ein anderer Bruch lässt sich nicht mit mehr Bits beheben. Eine Linecard kann entfernt und wieder eingesetzt werden. Hardwarezähler können zurückgesetzt werden, während der SNMP-Agent weiterläuft. Betrieblich ist es dieselbe Schnittstelle und ein stabiles ifIndex sinnvoll; rechnerisch dürfen alte und neue Werte nicht verbunden werden.

Früher mussten alle Zähler während der Abwesenheit erhalten oder ein neuer Index vergeben werden. RFC 2233 ergänzte ifCounterDiscontinuityTime: Die Zeilenidentität kann bleiben, während eine neue Messepoche offengelegt wird.

RFC 2863 definiert das Objekt als den sysUpTime-Wert beim jüngsten Bruch eines zugehörigen Counter32 oder Counter64. Trat seit der letzten Reinitialisierung des Managementsubsystems kein Bruch auf, steht dort null.

Damit benennt ifIndex weiterhin die Schnittstelle im betreffenden Verwaltungskontext. Es verspricht nicht, dass der heutige Akkumulator dort fortsetzt, wo der gestrige endete.

Der Zeitstempel nannte den Bruch, nicht seine Ursache

Für den Manager gilt eine klare Regel: Unterscheidet sich ifCounterDiscontinuityTime in den beiden Polls, muss die berechnete Differenz verworfen werden. sysUpTime ist zusätzlich zu prüfen, weil eine Agent-Reinitialisierung den größeren Zeit- und Namenskontext zurücksetzen kann.

Verwerfen heißt nicht, null Verkehr einzutragen. Es heißt, dass die standardisierten Beobachtungen keine genaue Summe für das Intervall tragen. Eine Planungsschätzung darf separat bestehen, aber nicht unter dem Namen des gemessenen Zählers.

Der Marker ist auch kein Ursachencode. Er unterscheidet weder Kartentausch und Softwareupdate noch Objektneuanlage und Implementierungsfehler. RFC 3635 übernimmt dieselbe Grenze für Ethernet-Objekte, ohne daraus Diagnose oder Authentisierung zu machen.

Ein unveränderter Marker ermöglicht somit den Vergleich im definierten Modell. Er zertifiziert weder Produktkonformität noch Paketzustellung, Abrechnung oder Diensteffekt.

Quellen und Beweisgrenzen

Der geschlossene historische Bestand umfasst RFC 1155, RFC 1213, RFC 1573, RFC 2233, RFC 2578, RFC 2863 und RFC 3635. Die Texte belegen Typen, Entwicklung und Managerpflichten. Sie messen keine heutige Verbreitung, zertifizieren kein Produkt, erklären keinen konkreten Bruch und beweisen weder Lieferung noch Rechnung.