Summary

  • RFC 2358 extended the Ethernet-like MIB for 100 Mb/s interfaces while keeping a common Ethernet identity and joining media-specific observations to the generic interface index.
  • Its counters recorded tightly defined events, not causes: speed, duplex, symbol errors, collisions, chip identity, polling epoch and remediation all remained separate evidence.

A faster wire creates a quiet temptation. If traffic moves ten times faster, perhaps the old management screen needs only a larger speed field. RFC 2358, published in June 1998, showed why that answer was too small. Fast Ethernet changed which physical events could be observed, which capabilities had to be declared and how an operator could compare the generic interface view with the Ethernet-specific one. It did not make a counter omniscient.

The document was a Standards Track revision of RFC 1650. It defined managed objects for Ethernet-like interfaces and added information useful for 100 Mb/s operation. Its own language treated the work as a snapshot: Ethernet would continue to acquire faster media, new cabling and new features, and the MIB would have to follow. That forecast arrived quickly. RFC 2665 replaced it in 1999 with gigabit and full-duplex additions; RFC 3635 later extended the line to 10 Gb/s. RFC 2358 matters because it preserves the moment when management had to absorb Fast Ethernet without turning each speed into a different species of network.

Its first decision was taxonomic. Ethernet-like interfaces were supposed to use ethernetCsmacd(6) regardless of speed or encapsulation. Vendor-registered types such as fastEther(62) and fastEtherFX(69) were not the preferred way to identify the technology. The current operational rate belonged in ifSpeed; the medium and duplex mode belonged in the 802.3 MAU MIB. “An Ethernet is an Ethernet” was more than neat naming. It let management software keep one stable class while asking separate objects for the changing properties.

That separation prevented a common arithmetic mistake. Full duplex did not make a 100 Mb/s line report 200 Mb/s. ifSpeed described the line rate, independent of duplex. RFC 2358 required MAU information because its own module did not offer a standard way to determine duplex. A dashboard that had a speed value but no MAU evidence could not safely fill in the missing mode from traffic volume or marketing language.

Capability was also distinct from current state. An interface capable of 100 Mb/s had to implement ether100MbsCompliance even when it was operating at a lower speed. Counters applicable only at 100 Mb/s would simply remain still at the lower rate. A conformance declaration therefore said what the interface must be able to expose. It did not say what rate had been negotiated at the moment of a poll, how much traffic crossed the link or whether the link was healthy.

The join between views was explicit. dot3StatsIndex identified the same interface as the equal ifIndex. Generic octet, packet and status objects could therefore be read beside Ethernet-specific collision and error objects without inventing a second identity. That join is mundane until an incident: if indices are stale, remapped after a restart or attached to the wrong device record, precise counters can be attributed to the wrong port with great confidence.

RFC 2358's characteristic new observation was dot3StatsSymbolErrors. It counted occasions on which an invalid data symbol appeared while valid carrier was present. The unit was not “bad symbols.” It incremented at most once per carrier event even if several invalid symbols occurred within that event. The difference matters. A rise from ten to eleven is evidence of one additional qualifying event under the agent's implementation; it is not proof of one corrupt bit, one damaged frame or one faulty cable.

Older collision counters carried equally exact boundaries. A late collision was detected after 512 bit-times of a transmission; at 10 Mb/s, the RFC gave 51.2 microseconds as the equivalent. Excessive collisions counted frames whose transmission failed after too many collisions. Deferred transmission meant the first attempt waited because the medium was busy and did not include collided frames. The optional collision histogram grouped frames by the exact number of collisions encountered. These categories made symptoms comparable because they constrained when a counter moved.

They also made clear what the counters could not settle. A late-collision increase might be consistent with a topology or duplex problem, but RFC 2358 did not encode the offending cable, peer, transceiver or configuration. Alignment errors, FCS errors and symbol errors could cluster around a physical fault, yet the MIB observation alone did not adjudicate among medium damage, electrical noise, optics, interface silicon or driver behavior. Correlation is an investigation, not an automatic consequence of the object name.

Some objects disclosed their uncertainty openly. dot3StatsInternalMacTransmitErrors covered otherwise uncounted MAC transmit failures and said its precise meaning was implementation-specific. Frames already classified as late collisions, excessive collisions or carrier-sense errors were excluded. That made the bucket useful, but only with the vendor and implementation context that defined it.

The chipset object supplied part of that context. dot3StatsEtherChipSet identified the chip that gathered the statistics and error indications, allowing a manager to account for known anomalies. It was instrument provenance: which component produced the observation. It was not a confession by the component. A chip identifier plus a counter anomaly could guide a compatibility check; it could not prove that silicon caused the service failure.

Even the counting rules resisted naïve addition. When a received frame met several error conditions, IEEE 802.3 conventions assigned it exclusively according to the status presented by the MAC service to its user. The total across counters was therefore a classified ledger, not a complete inventory of every symptom present in every frame. A graph could be internally correct and still answer a narrower question than its viewer imagined.

Time completed the evidence. Counters were Counter32 values; a useful delta required the sample interval and the relevant discontinuity or reset epoch. A reboot, interface reset or identity remap could make subtraction meaningless. RFC 2358 referred managers to the generic interface MIB for that surrounding state. A number without its interface, instrument and epoch was not portable evidence.

Active tests were no shortcut. The document described loopback and time-domain reflectometry through the already deprecated ifTestTable, made support optional and noted that many chips supported neither. Standard objects did not carry the TDR result; vendors had to provide their own result objects. “Test invoked,” “test completed,” “result returned,” “fault located” and “repair verified” were different receipts.

The security section extended the same discipline to access. None of the module's objects was read-write or read-create, so a correct implementation did not let an intruder change them through direct SNMP SET operations. Read-only did not mean harmless. Chipset identity could reveal equipment vendor information. SNMPv1 alone was insecure, and an IPsec-protected network still did not decide which principal was entitled to issue GET requests. The RFC recommended the user-based and view-based controls of SNMPv3.

RFC 2358 thus left a practical evidence chain: device and interface identity; counter epoch; current line rate; supported capability; MAU and duplex; classified error increments; instrument identity; peer-side observations; hypothesis; change; and post-change verification. Every link can be true while the next remains unproved.