Кратко

  • RFC 5190 распределяет логический ответ между несколькими SNMP-операциями. Notification с oper status и lifetime может потребовать GET для адресов, портов или ошибки; один event не всегда содержит весь результат.
  • Даже реконструированный ответ доказывает локальное состояние middlebox. Packet capture, удалённый receipt и application outcome остаются отдельными слоями.

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

RFC 5190 описывает, как семантика MIDCOM реализуется через SNMP. Запрос может занять несколько SET. Последний trigger только запускает проверку и обработку. После результата notification приносит status и lifetime, а клиент читает остальные поля из rule table.

Получается две границы. Сначала нужно собрать полный локальный ответ. Затем нельзя расширять его до результата сети.

SET подтверждает запись, а не завершение

У SNMP SET есть собственная атомарность. Он подтверждает набор varbinds. Логический запрос может включать несколько таких операций и ещё не быть обработанным.

checkingRequest и processingRequest отделяют принятые параметры от reserved, enabled или error. Если последний SET reply становится зелёным итогом, transient state исчезает из истории.

Хранить нужно principal, VACM decision, varbinds, row coordinates, reply или timeout каждого SET. Отдельно — trigger и последующие переходы oper status.

Это не общий рассказ о RowStatus. Здесь важна сборка одной операции из сообщений с разной доказательной силой.

Notification указывает, что читать дальше

midcomSolicitedRuleEvent содержит oper status и lifetime. При положительном lifetime клиент читает положительные параметры. При нуле — status и error.

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

Дополнительные GET должны сохраняться со своим временем. Нельзя задним числом изображать их полями исходного event.

Если notification потеряна, отсутствие не доказывает failure. Клиент опрашивает строку. RFC называет polling более дорогим, но более надёжным, потому что наблюдение можно повторить.

Timeout оставляет развилку

SET request и reply могут потеряться в UDP. Если исчез request, запись не сделана. Если исчез только reply, запись уже могла изменить состояние. Клиент видит одинаковую тишину.

Перед повтором RFC предлагает GET, а также snmpSetSerialNo, ограничение retransmission timer или отказ от retransmission. Эти механизмы уменьшают idempotency risk.

Они не доказывают exactly-once вне своего протокольного контекста. Lifetime может уже уменьшаться, когда приходит повтор.

Evidence record сохраняет первый timeout, recovery read и retry decision. Финальная строка «успешно» не должна стирать неоднозначность первой попытки.

Полный локальный ответ всё ещё локален

Допустим, event прибыл, GET вернул адрес и порт, oper status равен enabled. Это сильное свидетельство состояния данного middlebox.

Оно не наблюдало следующую ACL, маршрут, удалённый listener или приложение. Оно также не является packet capture на самом устройстве. Локальная конфигурация, packet passage, remote receipt и application acceptance требуют разных источников.

Положительный lifetime говорит, что rule получила срок. Он не говорит, что хотя бы один пакет соответствовал правилу или был доставлен.

Leadership reporting должен останавливаться на факте, который авторитетно сообщает источник: local rule established; traffic outcome unknown.

Строка результата может исчезнуть раньше

midcomRuleStorageTime показывает оставшееся время после error или termination. Однако implementation может удалить terminated row до окончания этого значения.

Если GET отложен, notification остаётся, а поясняющие поля пропадают. Позднее отсутствие строки не доказывает, что operation не существовала.

Collector должен быстро копировать owner, group, request, status, error, granted values и timestamps. Device row — диагностический cache, не долговечный архив.

Нужно также фиксировать storage type, наблюдавшийся countdown и момент исчезновения. Тогда «не найдено» остаётся ограничением доказательства, а не выдуманным отрицанием прошлого.

Несколько GET не создают один момент

Monitoring transaction может читать список несколькими запросами. Пока идёт сбор, rules добавляются и удаляются. RFC предлагает объединить пришедшие notifications или повторить чтение.

Snapshot должен иметь start/end, события внутри окна и reconciliation method. Иначе список может включать элементы, которые никогда не существовали одновременно.

Polling надёжнее в смысле повторяемости, не атомарности. Notification быстрее, но может потеряться. Вместе они дают версионированную реконструкцию.

Точная цифра без окна наблюдения — символ порядка, а не доказательство состояния.

Параллельные авторы

Если request parameters заполняются несколькими SET, другой authorised client может изменить строку до trigger. Все сообщения могут быть корректно аутентифицированы, а итог не соответствовать замыслу одного автора.

RFC рекомендует разделять время доступа, group indexes или rule-index ranges. Evidence должен хранить writer и before/after для каждого поля.

Общий owner описывает namespace и права. Он не доказывает единую авторскую волю. При failover эта разница отделяет продолжение от split brain.

Практический объект доказательства

Зафиксировать logical operation ID, middlebox, rule/group/interface, owner и expected parameters. Добавить каждый SET с security context, varbinds, serial, reply или timeout.

Отметить trigger, transient states и terminal observation. Указать notification или poll, сохранить literal event и отдельные GET. Скопировать terminal row до удаления, включая error и storage evidence.

После этого связать local state с NAT/firewall resource, packet capture с двух сторон, remote receipt и application result.

Положительный lifetime остаётся важным. Его ценность именно в узкой точности: он сообщает предоставленный срок локального правила и не притворяется доставкой пакета.

Источники

  1. RFC 5190 HTML
  2. RFC 5190 текст
  3. RFC 5190 информация
  4. Datatracker RFC 5190
  5. История RFC 5190
  6. Ссылки RFC 5190
  7. Errata RFC 5190
  8. RFC 5189
  9. RFC 5189 информация
  10. RFC 3416
  11. RFC 3418
  12. RFC 3414
  13. RFC 3415
  14. RFC 2578
  15. RFC 2579
  16. RFC 2580
  17. RFC 3304
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy