Кратко

  • RFC 3020 задавал четыре класса активации: достаточно одной линии, нужны все, нужно указанное число или применяется правило конкретной реализации.
  • Статус пучка up доказывал выполнение выбранного условия, но не полную пропускную способность, отсутствие ошибок переупорядочения или получение данных приложением.

Линии не восстановились. Изменилось определение достаточности.

Оператор снизил порог с трёх активных членов до двух. Агент пересчитал состояние, логический интерфейс перешёл в up, система отправила штатное уведомление. Все элементы могли работать строго по RFC 3020, хотя физически ничего не починили.

Опубликованный в декабре 2000 года документ определял MIB для UNI/NNI Multilink Frame Relay по FRF.16. Несколько физических каналов объединялись в один логический пучок, который выглядел для Q.922 как единый интерфейс и должен был восстанавливать порядок распределённых кадров.

Исторический урок состоит в происхождении статуса. Состояние агрегата вычисляется над набором компонентов. Без правила, состава набора и версии конфигурации зелёная отметка теряет точный смысл.

Логический интерфейс жил в двух пространствах индексов

Каждый физический член имел ifIndex в Interface MIB. Пучок тоже получал ifIndex. Специализированная таблица MFR использовала отдельный mfrBundleIndex.

Менеджер выбирал индекс MFR при создании строки, агент назначал общий индекс интерфейса. Двусторонние таблицы связывали их. Разные номера могли указывать на один объект, а не на два разных пучка.

SET createAndGo для mfrBundleRowStatus создавал пучок, после чего агент создавал запись интерфейса. Поддержка createAndWait была необязательной. Строка члена использовала ifIndex физического интерфейса и ссылалась на существующий пучок через mfrBundleLinkConfigBundleIndex; без корректной ссылки она оставалась notReady.

Существование строки было квитанцией конфигурации. Оно ещё не подтверждало состояние протокола, активацию агрегата и передачу кадров.

Одно слово up означало четыре разных теста

Класс A требовал хотя бы одну активную линию. Класс B — все линии. Класс C — число из mfrBundleThreshold. Класс D был пользовательским и зависел от реализации. По умолчанию применялся A.

В классе C достижение порога переводило пучок в active, а падение ниже — в inactive. Когда порог не применялся, объект возвращал -1. Для D значение зависело от кода.

Уведомления linkUp и linkDown повторяли этот расчёт. ifOperStatus пучка менялся, когда число активных членов становилось достаточным или недостаточным согласно классу и порогу.

Из четырёх членов одного достаточно для A. Трёх недостаточно для B. При пороге два второй член меняет двоичный статус, а третий и четвёртый — только ёмкость. Для D без версии реализации нельзя восстановить решение.

Хранить только событие означало потерять объяснение. Вместе требовались класс, порог, число настроенных и число активных линий.

Ёмкость и доставка не помещались в двоичный статус

RFC 3020 отдельно сообщал количество настроенных и активных членов и доступную полосу пучка. Активность агрегата не означала равенство первых двух чисел.

Доступная полоса тоже не была измеренным throughput приложения. В ней не было нагрузки, окна измерения, перегрузки, повторов, удалённого приёма и завершения операции.

MIB также содержала параметры фрагментации, размера фрагмента, длины sequence number и максимальной разницы задержек, а для членов — round-trip delay. Распределённые по линиям кадры нужно было не только передать, но и собрать по порядку.

Минимальная связность и обещанная ёмкость были разными целями. Один индикатор не мог честно заменить оба контракта.

Одно событие переупорядочения могло означать несколько потерянных кадров

mfrBundleResequencingErrors считал события. В примере RFC после 56 приходили 59 и 60, а 57 и 58 считались потерянными; счётчик увеличивался на единицу.

Поэтому delta 1 не равнялась одному кадру. Неизменный счётчик тоже не доказывал полную доставку без данных о reset, wrap, перезапуске агента, окне опроса и других классах отказов.

Отдельные счётчики отражали недопустимые управляющие кадры, истечение таймеров, подозрение на loopback, неожиданную последовательность и несовпадение имён пучка. Состояние члена происходило из автомата FRF.16, а не из одного электрического сигнала.

Mismatch trap показывал настроенные локальные и полученные удалённые имена. Стандарт отмечал, что настроенные значения могли быть созданы автоматикой. Уведомление доказывало расхождение представлений, но не назначало виновника.

Такие данные могли показать деградацию при всё ещё зелёном агрегате. Результат на получателе оставался отдельным фактом.

Изменение политики могло выглядеть как ремонт

Класс, порог, таймеры, фрагментация и размер последовательности имели максимум доступа read-create. Менеджер мог создавать, менять, удалять строки и назначать член пучку.

Но maximum access не доказывал доступность записи во всяком продукте. Условия соответствия разрешали minimum read-only для ряда объектов, требуя сообщать используемое значение. Схема, реализация и полномочия принципала были разными свидетельствами.

Если запись поддерживалась, понижение порога меняло состояние без физического ремонта. Новый up был корректен относительно новой политики. Называть его восстановлением инфраструктуры было бы неверно.

Раздел безопасности предупреждал об опасности незащищённых SET. SNMPv1 сам по себе не определял, кто мог читать, менять, создавать и удалять объекты, даже в защищённой IPsec сети. Рекомендовались USM и VACM SNMPv3, а корректная выдача прав оставалась обязанностью оператора.

Аутентификация отвечала, кто изменил. Авторизация — имел ли он право. Ни одна не отвечала, достаточен ли новый порог для услуги.

Proposed Standard не доказывал внедрение

RFC 3020 имел статус Proposed Standard. RFC 9141 позже обновил только ссылки на выведенный из эксплуатации FTP-сервис IETF и не изменил смысл активации.

Источники подтверждают проект MIB, но не конкретную реализацию, развёртывание, аварию, измеренную доступность или доставку заказчику. Эти утверждения не делаются.

Reality Layers Лу Хэна разделяет строку, политику, состояния членов, проекцию агрегата, счётчики целостности и результат приёма. Running-Code Primacy особенно важен для класса D. Minimum Initial Specification объясняет ценность ограниченной MIB без притязания на end-to-end контроль.

Это раскрытые аналитические линзы. Лу Хэн не писал и не одобрял RFC 3020.

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

Источники