Кратко

  • GetNext находил первый лексикографический преемник среди переменных, доступных данному запросу, и возвращал одновременно полное имя и значение.
  • Повторяя полученное имя, менеджер обнаруживал индексы концептуальной таблицы без заранее известного числа строк и без отдельной команды перечисления.
  • В SNMPv2 появились индивидуальный endOfMibView и GetBulk, но границы представления, размер сообщения и изменение состояния не позволили обходу стать полной моментальной копией.

В первом запросе ещё не было имени первой строки

Определение MIB сообщало OID столбцов назначения, следующего перехода и метрики. Суффиксы экземпляров зависели от фактических маршрутов на конкретном устройстве. Запрос абстрактного имени столбца не мог сам перечислить эти экземпляры.

RFC 1067 в 1988 году определил GetNextRequest. Агент выбирал непосредственного преемника имени в лексикографическом порядке переменных, доступных для чтения в применимом MIB view. В ответ попадали и OID найденной переменной, и её значение.

Менеджер помещал возвращённый OID в следующий запрос. Новый ответ продвигал границу ещё на одну позицию. Состояние обхода и решение об остановке оставались у менеджера; агенту достаточно было одинаково отвечать на узкий вопрос о преемнике.

Таблица возникала из соглашения об именах

MIB представляла управляемые объекты как виртуальное хранилище, но не была реляционной базой. Имя конкретной переменной складывалось из OBJECT IDENTIFIER типа объекта и фрагмента индекса экземпляра. RFC 2578 позднее описал концептуальные таблицы и INDEX в SMIv2.

В раннем примере менеджер отправляет три OID столбцов маршрутизации. Агент возвращает индексированные имена назначения, следующего перехода и метрики первой строки. Эти имена становятся следующим запросом, и появляется следующая строка. «Следующий» определяется числовыми компонентами OID, а не алфавитом символических меток и не сортировкой интерфейса.

Такая конструкция поддерживала исходную простоту SNMP. Подробное наблюдение строилось главным образом на polling со стороны центра управления, а немногочисленные traps меняли его фокус. Богатую функцию обнаружения можно было собрать на краю из минимальной общей операции.

Граница таблицы находилась по чужому имени

После последнего экземпляра одного столбца может идти первый экземпляр следующего. После всей таблицы лексикографический порядок продолжается объектом другого поддерева.

RFC 3416 показывает, как обход IP net-to-media сначала переходит в соседний столбец, а затем выходит из таблицы. Ответ с внешним OID корректен. Менеджер должен сравнить его с целевым префиксом и завершить собственную операцию.

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

В SNMPv1 окончание обрабатывалось грубо. По RFC 1157, отсутствие доступного преемника хотя бы у одного имени приводило к noSuchName и error-index. Закончившийся столбец мешал получить пользу от других bindings в той же операции.

SNMPv2 позволил нескольким путям закончиться отдельно

RFC 1448 ввёл endOfMibView в конкретный variable binding. Другие bindings ответа могли продолжать нести обычные имена и значения. RFC 1905 сохранил модель при развитии стандарта, а RFC 3416 закрепил современное описание.

Утверждение намеренно узкое: для этого binding в порядке, доступном этой операции, нет более позднего имени. Оно не означает, что у устройства закончилась управляемая информация.

GetBulk объединил несколько шагов. Для non-repeaters запрашивается по одному преемнику, а остальные bindings могут получить последовательность до max-repetitions. Число обменов уменьшается, но запрошенный максимум не гарантируется. Ограничения размера сокращают ответ. RFC 1905 также предупреждает, что большие значения увеличивают риск IP-фрагментации и снижения надёжности.

Обход описывал доступное представление

В правило входят только переменные, доступные запросу. RFC 3415 задаёт MIB views как наборы включённых и исключённых поддеревьев в контексте и связывает с ними права групп.

Поэтому два законно авторизованных менеджера могут спросить одно устройство об одном исходном OID и получить разные правильные ответы. Скрытый объект не участвует в видимом порядке. endOfMibView не доказывает отсутствие частной MIB, другого контекста или данных, доступных более привилегированной личности.

Есть и временная граница. Между первым и последним ответом таблица маршрутов или соседей может измениться. GetBulk уменьшает интервал, но не создаёт snapshot isolation. Чтение sysUpTime рядом с таблицей помогает заметить перезапуск и датировать наблюдение, однако не превращает последовательные строки в атомарный реестр.

Источники и пределы

Механизм подтверждают RFC 1067, RFC 1157, RFC 1448, RFC 1905, RFC 2578, RFC 3415 и RFC 3416. Они устанавливают семантику и историю, но не доказывают современную распространённость, соответствие продукта, безопасность конкретной сессии или эффект прочитанного значения в плоскости данных.