Кратко

  • RFC 2358 добавил требования для 100 Мбит/с и счётчик символьных ошибок, сохранив единый тип Ethernet и связав статистику среды с общим индексом интерфейса.
  • Каждый объект фиксировал строго определённое событие, а не виновника; способность, текущая скорость, дуплекс, эпоха, прибор, причина и итог ремонта оставались разными свидетельствами.

У точного графика есть опасное свойство: он легко делает гипотезу похожей на факт. В 1998 году Fast Ethernet дал системам управления новые показания. RFC 2358 подробно определил, когда они должны меняться, и тем самым невольно оставил учебник по пределам телеметрии.

Документ Standards Track заменил RFC 1650 и добавил сведения для управления интерфейсами 100 Мбит/с. Он прямо описывал себя как этап развития. Уже в 1999 году RFC 2665 дополнил модель гигабитом и полным дуплексом, а RFC 3635 позднее довёл её до 10 Гбит/с. Поэтому RFC 2358 — не современная окончательная MIB, а срез момента, когда измерения догоняли Fast Ethernet.

Преемственность началась с типа. Независимо от скорости интерфейс Ethernet должен был оставаться ethernetCsmacd(6), а не превращаться в fastEther(62) или fastEtherFX(69). Текущая линейная скорость находилась в ifSpeed, среда и дуплекс — в ifMauType MIB для MAU 802.3. Постоянная идентичность и переменные свойства получили разные поля.

Так исчезала и ложная арифметика. Полный дуплекс на линии 100 Мбит/с не превращал ifSpeed в 200. RFC 2358 требовал MAU MIB именно потому, что собственный модуль не давал стандартного дуплексного статуса. Наличие скорости не восполняло отсутствие этого свидетельства.

Способность не равнялась текущему режиму. Интерфейс с поддержкой 100 Мбит/с обязан был реализовать ether100MbsCompliance, даже работая медленнее. Специфические счётчики могли не расти. Соответствие говорило о контракте реализации, но не о состоявшемся согласовании и не о здоровье услуги.

dot3StatsIndex обозначал тот же интерфейс, что и равный ему ifIndex. Общие пакеты и октеты можно было сопоставить с коллизиями и ошибками Ethernet. Однако это соединение само нуждалось в проверке: после перезапуска устаревший инвентарь мог прикрепить верное значение к неверному порту.

Характерным новшеством стал dot3StatsSymbolErrors. Он увеличивался при неверном символе данных во время действующей несущей, не более одного раза на событие несущей. Несколько плохих символов внутри события не давали нескольких шагов. Приращение означало одно событие по правилам классификации, а не один бит, кадр или заметный сбой.

Границы коллизий были столь же точны. Поздняя коллизия обнаруживалась после 512 битовых интервалов; на 10 Мбит/с это 51,2 микросекунды. Чрезмерные коллизии считали кадры, чья передача сорвалась из-за их количества. Отложенная передача ждала занятую среду при первой попытке и не включала столкнувшиеся кадры. Необязательная гистограмма делила кадры по точному числу коллизий.

Определения обеспечивали сопоставимость, но не назначали причину. Поздние коллизии могли сочетаться с несогласованным дуплексом или неправильной топологией. Ошибки FCS, выравнивания и символов могли сопровождать кабель, помехи, оптику, микросхему или драйвер. Имя объекта не выбирало виновника.

dot3StatsInternalMacTransmitErrors честно оставлял часть смысла реализации. Он учитывал внутренние сбои передачи, не попавшие в поздние и чрезмерные коллизии или ошибки несущей. Это определённая остаточная категория, а не универсальный диагноз.

dot3StatsEtherChipSet указывал микросхему, которая собирала статистику и признаки ошибок, позволяя учитывать известные аномалии. Это происхождение измерения. Источник показаний не становится причиной события автоматически.

Даже сумма ошибок отражала классификатор. Кадр с несколькими условиями учитывался только по статусу, который MAC-служба выдала пользователю. Столбцы не составляли без потерь все физические признаки каждого кадра.

Counter32 требовал временной эпохи. Перезапуск, сброс или перенумерация могли сделать разность бессмысленной. Время выборки и ifCounterDiscontinuityTime должны храниться вместе со значением, устройством и интерфейсом.

Активные тесты не заменяли расследование. Loopback и TDR были описаны через уже устаревавшую ifTestTable, поддерживались необязательно, а стандартного объекта результата TDR не существовало. Запуск, завершение, получение результата, локализация и проверка ремонта были отдельными квитанциями.

Наконец, read-only не означало безопасную открытость. Объекты нельзя было менять через SNMP SET, но идентификатор чипсета раскрывал сведения о поставщике. SNMPv1 сам по себе не защищал доступ, а IPsec не определял, кто внутри сети вправе делать GET. RFC рекомендовал пользовательскую безопасность и управление представлениями SNMPv3.

Надёжная цепочка выглядела так: устройство, порт, индекс, эпоха, скорость, способность, среда, дуплекс, классифицированное приращение, чип, данные второй стороны, гипотеза, изменение и повторная проверка. Истинность звена не доказывала следующее.