Кратко

  • RFC 1452 связывал приложения SNMPv2 с агентами SNMPv1 через прокси или двуязычный менеджер, выбирающий версию по локальной базе.
  • GetBulk превращался в GetNext с нулевыми полями повторения, тогда как некоторые старые ошибки намеренно сохранялись.
  • Переведённый ответ подтверждал обмен через отображение, но не тождество операции, объёма сведений, защиты или результата.

Невидимый выбор в локальной базе

RFC 1452 вынес различия версий из приложения. Прокси SNMPv2 мог обращаться к агенту SNMPv1, а менеджер мог говорить на обоих протоколах.

До контакта с целью менеджер проверял локальную базу. Запрос приложения описывал намерение; запись цели выбирала версию; правило создавало фактический PDU. Устаревшая база могла выбрать неправильно, не разрушив единую оболочку. Двуязычность не удостоверяла свежесть каталога.

Пакетный запрос лишился повторений

GetRequest, GetNextRequest и SetRequest передавались без изменения. Для GetBulk прокси устанавливал non-repeaters и max-repetitions в ноль, затем менял тег на GetNextRequest.

Старый агент делал один шаг к следующему объекту для каждого binding. Это позволяло продолжить работу, но не исполняло пакетный объём исходного запроса. RFC 1448 определяет нативный GetBulk; RFC 1452 показывает его сужение на границе.

Один request-id не доказывает цепочку. Нужны исходный PDU, запись цели, выбранная версия, правило, нижний PDU и ответ.

Старый ответ не маскировали под новый

Значения noSuchName, badValue и readOnly из SNMPv1 следовало передавать без изменения, хотя нативный SNMPv2 их не создавал. Более точная ошибка была бы выдуманной деталью.

Сохранение защищало происхождение, но не делало ответ нативным. При tooBig прокси удалял variable bindings перед передачей. Поэтому верхний GetBulk мог получить форму отказа, возникшую после нижнего GetNext.

Trap получил вычисленные поля

При переводе Trap-PDU добавлялся sysUpTime.0, вычислялся snmpTrapOID.0, добавлялся enterprise binding. Новое сообщение было определённой правилами реконструкцией, а не байтовой копией.

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

Идентификатор пережил смену грамматики

Старые MIB можно было применять с SNMPv2 и не объявлять объекты устаревшими без настоящего изменения смысла. Но конверсия меняла imports, типы, доступ, status, описания и индексы. ACCESS становился MAX-ACCESS, mandatorycurrent, optionalobsolete, Counter и Gauge получали явные 32 бита.

Стабильный OID доказывал сохранение имени, а не разрешение или одинаковое чтение. RFC 1908 позднее отметил неоднозначность групп, если разные редакции старого MIB имели разные обязательные листья под одним subtree.

Новые версии раскрыли цену прозрачности

RFC 2576 и BCP RFC 3584 добавили SNMPv3. Исключения по binding могли сжаться в один noSuchName; Counter64 мог сделать уведомление непереводимым; многократный GetNext для пропуска таких значений мог быть дорогим.

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

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

Источники