Zusammenfassung

  • RFC 2358 ergänzte die Ethernet-MIB um 100-Mbit/s-Konformität und Symbolfehler, ohne für jede Geschwindigkeit eine neue Schnittstellenidentität zu erfinden.
  • Die Objekte zählten definierte Ereignisse, nicht deren Verursacher; Fähigkeit, Betriebszustand, Duplex, Epoche, Messinstrument und Reparatur blieben getrennte Belege.

Eine präzise Zahl kann eine unpräzise Geschichte stützen. Genau darin lag 1998 das Risiko der Netzüberwachung: Fast Ethernet lieferte neue Messwerte, und ihr technischer Name klang leicht wie eine fertige Diagnose. RFC 2358 machte die Messung genauer, begrenzte aber durch seine Definitionen zugleich, was aus ihr folgen durfte.

Das Standards-Track-Dokument löste RFC 1650 ab und fügte Informationen für 100-Mbit/s-Schnittstellen hinzu. Es verstand sich als Zwischenstand. RFC 2665 ersetzte es 1999 mit Gigabit- und Vollduplex-Erweiterungen; RFC 3635 führte die Linie bis 10 Gbit/s fort. RFC 2358 ist deshalb ein historischer Ausschnitt der MIB-Evolution, nicht die heutige Endfassung.

Die Kontinuität begann beim Typ. Ethernet-artige Schnittstellen sollten unabhängig von der Geschwindigkeit ethernetCsmacd(6) verwenden. fastEther(62) und fastEtherFX(69) waren nicht die gewünschte Identität. Die aktuelle Leitungsrate stand in ifSpeed, Medium und Duplex in ifMauType der 802.3-MAU-MIB. Eine stabile Klasse trug wechselnde Eigenschaften.

Damit entfiel auch die falsche Verdopplung: Eine 100-Mbit/s-Vollduplexleitung meldete 100, nicht 200 Mbit/s. RFC 2358 verlangte die MAU-MIB, weil das eigene Modul keinen standardisierten Duplexwert bot. Durchsatz war kein Ersatz für diese fehlende Information.

Fähigkeit war ebenfalls nicht Zustand. Eine 100-Mbit/s-fähige Schnittstelle musste ether100MbsCompliance erfüllen, selbst wenn sie gerade langsamer lief. Nur für 100 Mbit/s relevante Zähler durften stillstehen. Konformität belegte die Ausstattung des Agenten, nicht die aktuelle Aushandlung oder Dienstgüte.

dot3StatsIndex bezeichnete dieselbe Schnittstelle wie der gleichwertige ifIndex. So ließen sich allgemeine Paket- und Oktettwerte mit Ethernet-spezifischen Fehlern verbinden. Doch auch der Join war beweispflichtig. Nach Neustart oder Umnummerierung konnte ein veraltetes Inventar genaue Werte dem falschen Port zuschreiben.

Kennzeichnend war dot3StatsSymbolErrors. Der Zähler stieg, wenn bei gültigem Träger ein ungültiges Datensymbol auftrat, höchstens einmal pro Trägerereignis. Mehrere fehlerhafte Symbole im selben Ereignis ergaben nicht mehrere Schritte. Ein Schritt war daher weder ein Bit noch ein Frame noch ein Kundenausfall.

Auch Kollisionen hatten enge Einheiten. Eine späte Kollision wurde nach 512 Bitzeiten erkannt; bei 10 Mbit/s entsprach das 51,2 Mikrosekunden. Übermäßige Kollisionen zählten Frames, deren Übertragung daran scheiterte. Verzögerte Übertragung bedeutete, dass der erste Versuch wegen eines belegten Mediums wartete, ohne kollidierte Frames einzuschließen. Das optionale Histogramm gruppierte Frames nach exakter Kollisionszahl.

Diese Grenzen ermöglichten Vergleich, nicht Schuldspruch. Späte Kollisionen konnten zu Duplexfehlern oder unzulässiger Topologie passen. FCS-, Ausrichtungs- und Symbolfehler konnten Kabel, Störungen, Optik, Silizium oder Treiber begleiten. Das MIB-Objekt benannte keines davon als eindeutige Ursache.

dot3StatsInternalMacTransmitErrors machte die Unsicherheit ausdrücklich. Es sammelte interne Sendefehler, die nicht bereits als späte oder übermäßige Kollision oder Trägerfehler galten; die genaue Bedeutung war implementierungsspezifisch. Das war ein abgegrenzter Resttopf, keine universelle Diagnose.

dot3StatsEtherChipSet lieferte Messprovenienz. Es identifizierte den Chip, der Statistiken und Fehleranzeigen erfasste, damit bekannte Anomalien berücksichtigt werden konnten. Wer misst, ist jedoch nicht automatisch die Ursache des Gemessenen.

Selbst Fehlersummen waren Klassifikation. Erfüllte ein empfangener Frame mehrere Bedingungen, wurde er ausschließlich nach dem Status gezählt, den der MAC-Dienst seinem Benutzer meldete. Die Spalten waren kein vollständiges Inventar aller gleichzeitigen physikalischen Symptome.

Counter32 brauchte außerdem eine Epoche. Ohne Abtastintervall und Diskontinuitätszeit konnte ein Neustart, Reset oder Indexwechsel jede Differenz entwerten. Wert, Schnittstelle, Instrument und Zeitraum gehörten zusammen.

Aktive Tests waren kein Orakel. Loopback und TDR liefen über eine bereits als veraltet bezeichnete ifTestTable, waren optional und wurden von vielen Chips nicht unterstützt. Für TDR-Ergebnisse gab es kein Standardobjekt. Start, Abschluss, Ergebnis, Ortung und verifizierte Reparatur waren getrennte Nachweise.

Schreibschutz bedeutete schließlich nicht Öffentlichkeit. Das Modul bot keine per SNMP SET änderbaren Objekte, doch die Chipkennung konnte den Gerätehersteller verraten. SNMPv1 war allein unsicher, und IPsec entschied nicht, welcher Teilnehmer GET ausführen durfte. Empfohlen wurden Benutzer- und Sichtkontrollen von SNMPv3.

Die belastbare Kette lautete damit: Gerät, Port, Index, Epoche, Geschwindigkeit, Fähigkeit, Medium, Duplex, klassifizierte Zunahme, Chip, Gegenstelle, Hypothese, Änderung und Nachmessung. Kein Glied füllte das nächste automatisch aus.