Кратко

  • RFC 1513 расширила RMON для Token Ring. dropEvents считал случаи, когда зонд отбрасывал пакеты из-за нехватки ресурсов, а не точное количество отброшенных кадров.
  • Отчёт о мягкой ошибке мог доставляться гарантированно и дважды попасть к зонду в promiscuous-режиме. Сообщившая станция, ближайший верхний сосед, порядок станций и интервал измерения были частью смысла числа.
  • Измерение, оценка потери, назначение виновника, разрешение на управляющее действие и результат требовали разных квитанций. Поздний RMON-2 отдельно назвал счётчики точного числа отброшенных кадров.

Точное число с узким смыслом

RFC 1271 переносила постоянное наблюдение на удалённый зонд: статистика, история, хосты, матрицы, фильтры, захват и события становились доступны станции управления. Часть канальных представлений была рассчитана на Ethernet. В сентябре 1993 года RFC 1513 добавила объекты IEEE 802.5 Token Ring и группы станций, их порядка, конфигурации и source routing.

Ключевая граница находилась в описании tokenRingMLStatsDropEvents. Счётчик рос, когда зонд из-за нехватки ресурсов отбрасывал пакеты. Спецификация сразу уточняла: это не обязательно число пакетов, а лишь количество обнаруженных случаев такого состояния.

Один эпизод мог скрыть кадр или целую вспышку. Два эпизода могли иметь разную длительность. Зонд точно знал, сколько раз заметил собственную неспособность успевать, но не мог этим числом восстановить то, что не обработал.

Счётчик не лгал. Ошибка возникала, когда «эпизоды» без доказательств переименовывали в «кадры».

Наблюдатель тоже был частью системы

RMON экономил передачу данных, потому что классифицировал и сводил их рядом с сегментом. Поэтому у зонда были конечные процессор, память, буферы и таблицы. При насыщении dropEvents описывал потерю видимости наблюдателя не меньше, чем состояние сети.

Одинаковая семантика применялась в MAC-статистике, promiscuous-статистике и исторических интервалах. Для сравнения нужны interface, data source, control row, owner, status, эпоха активации и окно выборки. Перезапуск, пересоздание строки, wrap счётчика или смена источника могли склеить разные эксперименты.

RFC 4502 позднее ввела отдельные DroppedFrames и назвала их точным числом кадров, исключённых из коллекции, в отличие от dropEvents. Более сильное утверждение получило собственный измерительный объект.

Надёжная доставка могла удвоить сообщение

RFC 1513 предупреждала: пакеты отчётов о soft error могли использовать assured delivery. Зонд, слушавший promiscuously, иногда считал одну ошибку дважды. Надёжность доставки отчёта не означала уникальность события.

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

Верхний сосед ещё не становился причиной

Правила учёта использовали топологию кольца. Address Copied errors увеличивали запись ближайшего верхнего соседа сообщившей станции. Line и burst errors увеличивали записи сообщившей станции и соседа. Internal и abort errors оставались у сообщившей станции.

Так доказательства удобно раскладывались для расследования, но физическая причина не устанавливалась. Станция могла попасть в таблицу как источник отчёта, как сосед или как адресат правила. Ring Station Order Group показывала порядок станций, но снимок не доказывал неизменность топологии в момент ошибки и доставку кадра.

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

Возможность записи не давала полномочий

Ring Station Configuration Group позволяла удалить станцию из кольца или загрузить ей конфигурацию. Но RFC 1513 отделяла access level от административной политики: чтение или запись могли иметь протокольный смысл, не выдавая актору разрешения.

read-write не был мандатом. Рост dropEvents, соседская атрибуция или потенциально повторный отчёт не оправдывали автоматическое удаление. Нужна отдельная цепочка: личность заявителя, решение о доступе, цель, прежний порядок, команда, ответ, новое состояние и наблюдаемый эффект.

Статистика source routing тоже оставалась частичной, поскольку выводилась из необязательных данных в кадрах. Классификация на одном кольце не доказывала end-to-end путь.

Что выдерживают источники

Карточка RFC Editor и Datatracker подтверждают публикацию, авторство, связи и статус. RFC 1271, 1757, 2021, 2819, 3577 и 4502 показывают развитие RMON.

Они не подтверждают конкретное внедрение, потерю, аварию, дефект поставщика или успешное вмешательство. Historic — не отчёт об инциденте. Поздняя deprecation некоторых Token Ring-дополнений RMON-2 из-за недостатка независимых реализаций для доказательства интероперабельности также не доказывает эксплуатационный провал RFC 1513.

Running-Code Primacy требует проверять выполнение и эффект. Minimum Initial Specification удерживает общий смысл минимальным и оставляет локальные решения видимыми. On Reality Layers не даёт символу присвоить полномочия представляемой реальности.

Число 42 могло честно означать 42 обнаруженных эпизода дефицита. Без других квитанций оно не становилось 42 потерянными кадрами, авариями или разрешениями наказать станцию.

Источники

  1. RFC 1513 — сведения
  2. RFC 1513 — текст
  3. RFC 1513 — Datatracker
  4. RFC 1271 — сведения
  5. RFC 1271 — текст
  6. RFC 1757 — сведения
  7. RFC 1757 — текст
  8. RFC 2021 — сведения
  9. RFC 2021 — текст
  10. RFC 2819 — сведения
  11. RFC 2819 — текст
  12. RFC 3577 — сведения
  13. RFC 3577 — текст
  14. RFC 4502 — сведения
  15. RFC 4502 — текст
  16. Running-Code Primacy
  17. Minimum Initial Specification
  18. On Reality Layers