Кратко

  • Ноль уведомлений имеет смысл только после доказательства, что агент умеет их создавать, менеджер имеет доступ, а канал действительно доставляет сообщения.
  • RFC 2006 позволяет отделить «событий не наблюдали» от «наблюдать было невозможно», если хранить возможности, успешность опроса и эпоху sysUpTime.

Молчание системы мониторинга часто превращают в зелёный цвет. В RFC 2006 такой вывод не следует из объекта. Необязательное уведомление mipAuthFailure появляется лишь после того, как реализация распознала ошибку проверки, обновила контекст и сумела отправить сообщение доступному менеджеру.

Сбой на любом участке даёт тот же внешний результат — уведомления нет. Поэтому состояние «ноль ошибок» должно отличаться от состояния «данных нет». Иначе мониторинг скрывает собственную неисправность под видом исправности Mobile IP.

Эта логика распространяется на всю MIP-MIB, размещённую под mib-2 44. Объекты сгруппированы по мобильному узлу, внешнему агенту и домашнему агенту; часть групп и журналов зависит от возможностей реализации. Само отсутствие строки ещё не сообщает причину отсутствия.

Сначала доказать возможность наблюдения

mipEntities сообщает, поддерживает ли система мобильный узел, внешний агент или домашний агент; можно установить несколько битов. mipEnable запрашивает включение или выключение Mobile IP, а mipEncapsulationSupported перечисляет возможности. Бит роли не доказывает обслуживание трафика. Успешная запись не подтверждает прекращение всей активности обнаружения и регистрации. Бит возможности не показывает согласованный туннель и прошедший по нему пакет.

На мобильном узле mnState различает состояния дома, зарегистрирован, ожидание, изоляция и неизвестно. Таблица внешних агентов пополняется из полученных объявлений и стареет вместе с ними. Счётчики фиксируют запросы, объявления, неверные расширения и события, которые узел «определил» как перемещение или перезапуск агента. Такое определение — вывод реализации, а не доказательство физического движения или причины изменения номера последовательности.

Таблица регистрации объединяет адрес агента, care-of address, флаги, Identification, запрошенное и оставшееся время, время отправки и признак принятия. Она обновляется по отправленным запросам, полученным ответам и повторным передачам. Это локальная память, а не захват пакетов и не единый журнал транзакций.

Опрос тоже может молчать

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

Строка привязки тоже не видит весь путь. Она показывает, что домашний агент сохранил домашний адрес, care-of address, полученный адрес источника, флаги, Identification и срок жизни на момент чтения. Она не показывает доставку к care-of address, декапсуляцию, последний канал и получение приложением.

Тип данных входит в смысл показания. Counter32 переполняется. Оставшийся срок в Gauge32 — значение в момент опроса. TimeStamp привязан к эпохе sysUpTime, а не непосредственно к абсолютному времени. Суммарное время обслуживания отсчитывается от последнего перезапуска домашнего агента. Без ширины, эпохи и интервала разность значений может создать ложную непрерывность.

Полученное уведомление не завершает расследование

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

Объекты нарушений сохраняют последние сообщённые адрес, SPI, Identification, время и причину. Необязательное уведомление mipAuthFailure передаёт часть этих данных при неудачной проверке Registration Request или Reply. Это основание начать расследование, но не идентификация человека. Отчёт сам не различает взломанный узел, подделку и устаревший контекст и не подтверждает получение менеджером всех уведомлений.

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

Источники