Кратко

  • RFC 2366 разрешал удалить родительскую строку клиента MARS, сервера MARS или MCS, даже если связанные строки VC сохранялись или использовались; их очистка была отдельной условной операцией.
  • read-create задавал максимально допустимый доступ модели, но совместимая реализация могла быть только читаемой. Активная строка, счётчик, уведомление и успешный SET не доказывали сами по себе разбор канала или доставку.

После команды удаления запись пропадает с экрана. Интерфейс становится чище, и глаз принимает чистоту за завершённость. RFC 2366 прямо допускал другое: управленческое представление могло закончиться раньше сетевого ресурса.

Объект marsClientRowStatus создавал, изменял и удалял строку клиента. Для перехода в active требовались настроенные столбцы и соответствующая строка статистики. Однако удалить клиента можно было при существующих или используемых записях в связанных таблицах, в том числе в marsClientVcTable.

После этого агенту или, если возможно, станции управления рекомендовалось с помощью SET удалить устаревшие дочерние строки. Это не был один каскадный переход. Удаление родителя меняло MIB; сверка и очистка зависимостей требовали отдельной возможности и отдельного результата.

Поэтому оставшаяся строка VC не имела единственного толкования. Она могла описывать работающий канал, быть следом уже освобождённого канала или отражать незавершённую сверку. Её наличие не доказывало жизнь, а отсутствие родителя не доказывало прекращение сигнализации.

То же правило повторялось для основной строки MARS и основной строки MCS. Каждую можно было удалить при сохраняющейся или используемой таблице VC. Повторение во всех трёх ролях фиксировало принцип: жизненный цикл модели управления и жизненный цикл ATM-инфраструктуры не были одной атомарной процедурой.

Базовую архитектуру задавал RFC 2022. MARS распространял сведения о членстве в мультикаст-группах внутри ATM-кластера. Отправитель строил VC «точка-многоточка» до получателей либо передавал трафик MCS. RFC 2366 не превращал SNMP-менеджер в этот механизм. Он переносил выбранные состояния в виртуальное хранилище информации.

Для клиента модель показывала ATM-адрес, MARS по умолчанию, регистрацию, идентификаторы, таймеры, диапазоны групп, резервные серверы, VC и статистику. Для MARS были предусмотрены статус, приоритет, карты хостов и MCS, зарегистрированные участники, каналы и счётчики. У MCS имелся параллельный набор регистрации, резерва, VC и активности.

Эти таблицы были связаны, но не взаимозаменяемы. Строка зарегистрированного клиента не содержала всей его конфигурации. Карта адресов не была каналом. Даже строка VC с VPI/VCI, группой, другой стороной, типом PVC или SVC, назначением, таймером, флагом перепроверки, инкапсуляцией и согласованным MTU не показывала, удерживает ли коммутатор соединение и получили ли пакеты все листья.

Источник строки определял право на действие. Настроенные карты можно было администрировать, динамически изученные строки нельзя было изменить или удалить тем же RowStatus. Часть полей активного VC допускала изменение, но строку SVC нельзя было модифицировать или удалить этим путём. Видеть объект не означало владеть им.

Вторая граница проходила между объявлением доступа и минимальной совместимостью. Многие объекты имели MAX-ACCESS read-create: модуль разрешал реализации предоставлять создание и запись. Но его условия совместимости снижали минимальный доступ до read-only и многократно указывали, что запись не обязательна.

Следовательно, полностью совместимый агент мог быть только окном наблюдения. RFC 1904 пояснял, что действительно записываемый объект должен позволять SET разумно влиять на управляемую сущность. Верхняя граница схемы не являлась перечнем возможностей конкретного устройства.

Даже принятый SET не доказывал полномочие и конечный эффект. Требовались аутентифицированный субъект, разрешённое представление VACM, операция, значение, ответ агента и устойчивость изменения. Затем шли ATM-сигнализация, состояние коммутатора, пакеты и наблюдение получателя. Успех SNMP квитировал лишь управленческий шаг.

Счётчики имели столь же ограниченный смысл. Они суммировали запросы, JOIN, LEAVE, составные ответы, NAK, миграции и ожидания последнего MARS_MULTI. MARS и MCS считали свои семейства управляющих сообщений. Без времени сбора, базового значения, сброса и идентичности экземпляра даже разность была неоднозначна. С ними она доказывала управляющую активность, а не доставку данных.

MTU по умолчанию в строке клиента или MCS мог отличаться от согласованного MTU конкретного VC. HSN, CSN и SSN помогали заметить пропущенные управляющие сообщения или изменение членства, но не подтверждали путь данных. marsFaultTrap означал, что агент обнаружил отказ; генерация, отправка, получение менеджером, диагностика, исправление и восстановление оставались разными событиями.

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

Читающий наблюдатель мог увидеть ATM-адреса, членство, карты, приоритеты резерва, стороны VC, MTU, таймеры и отказы. Шифрование транспорта, проверка личности, полномочие на представление и законная эксплуатационная цель были четырьмя разными условиями.

Через два месяца идентификатор самого модуля потребовал ремонта. RFC 2366 поместил MIB под snmpModules. RFC 2417 исправил канцелярскую ошибку назначения, перенёс почти ту же семантику в mib-2 57 и объявил прежний документ устаревшим. Значение строк сохранилось, но общая координата для их обнаружения должна была измениться.

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

Источники