Кратко

  • Один агент SNMP мог показывать несколько логических сущностей и дерево физических компонентов; одинаковый индекс в разных областях мог обозначать разные объекты.
  • Таблицы вложенности, логико-физических связей и псевдонимов позволяли восстановить локальную ссылку, но не доказывали собственность, местоположение, полноту или согласие агентов.

Число 5 может быть верным в двух строках инвентаря и всё же относиться к двум разным интерфейсам. RFC 2037 строила Entity MIB, исходя именно из этого риска.

В документе приводился маршрутизатор, входящий в две автономные системы, каждая со своей магистральной областью OSPF 0.0.0.0. Один корпус также мог нести несколько логических маршрутизаторов, мостов или повторителей, доступных через одну точку управления. Идентификатор объекта и индекс оставались корректными, но были уникальны только в своём контексте.

Область имен была частью ключа

RFC называла областью имен набор управляемой информации, доступный за одну операцию и использующий единое пространство уникальных идентификаторов. В SNMPv1 и SNMPv2c entLogicalCommunity указывала community для доступа к области логической сущности.

Поэтому две записи ifIndex.5 нельзя было объединять только по суффиксу. Полное наблюдение включало агента, время, community и логический индекс. Запись «интерфейс 5» сохраняла значение, но выбрасывала его адрес.

Совпадающая community не создавала административной связи между логическими сущностями. Строка не сообщала, реализована ли сущность внутри корпуса или доступна через proxy. Управление самими областями имен тоже не входило в задачи Entity MIB.

Пустой слот оставался элементом структуры

entPhysicalContainedIn соединяла компонент с непосредственным контейнером. От порта можно было подняться к модулю, слоту и корпусу, а затем к индексу ноль. Контейнеры требовалось представлять и заполненными, и пустыми.

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

Логическая и физическая схемы связывались многие-ко-многим

entLPMappingTable допускала, что одна логическая сущность опирается на несколько компонентов, а один компонент обслуживает несколько логических сущностей. Такая связь описывала поддержку, но не исключительную собственность, административное управление, аренду или юридическую ответственность.

Важна была и детализация. Если порты концентратора можно переключать между повторителями, свёртывание отдельных портовых связей в одну связь модуля скрывало реальную поверхность управления. Упрощённая схема могла оказаться менее точной.

Псевдоним возвращал внешний индекс к физическому объекту

entAliasMappingTable объединяла логическую сущность, физический компонент и идентификатор другой MIB, например ifIndex. Логический индекс выбирал область имен, физический — компонент, а псевдоним — внешний объект.

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

Два агента могли видеть одну систему по-разному

RFC не требовала эквивалентности или согласованности пересекающихся экземпляров Entity MIB. Агенты могли выбирать другие произвольные индексы, идентификаторы производителя и подмножества. Одинаковый индекс между агентами не доказывал тождество; разные описания не доказывали ошибку.

Для сверки нужны были внешние основания: серийные данные, топология, эксплуатационные записи или другая проверенная связь. Надёжность вывода зависела от этой связи, а не от гарантии Entity MIB.

В RFC 2037 все доступные объекты модуля были только для чтения. Успешный ответ доказывал лишь, что этот агент вернул значение в этой области и в этот момент. Он не доказывал текущую эксплуатацию, достижимость, полноту или полномочия. Позднее RFC 2737 добавила контексты SNMPv3 и изменяемые административные объекты; за ней последовали RFC 4133 и RFC 6933. Эти возможности нельзя приписывать версии 1996 года.

Источники