Кратко

  • Активные правила могли отбросить протокол, поменять местами источник и назначение, применить маску, поместить в поток лишь выбранные атрибуты и задать формат, который затем считывал NeMaC.
  • Для скорости NeTraMet превращал однотипные тесты в хеш-поиск и хранил маски как однобайтовые индексы; границы сборки программы становились частью контекста записи.
  • При заполнении таблицы production-набор мог смениться более грубым standby, а на FloodMark — default-набором. После перезапуска meter также начинал с default, пока manager не восстанавливал production.

Сначала выбирался вопрос, потом появлялся счётчик

RFC 2123 вышел в марте 1997 года как Informational и зафиксировал три года опыта с архитектурой RTFM. В ней meter наблюдал пакеты, meter reader переносил данные, manager настраивал систему, а analysis applications превращали строки в отчёты.

В описанной реализации NeTraMet был измерителем, NeMaC совмещал управление и чтение. До создания строки NeMaC загружал набор правил в Packet Matching Engine. Правило могло проверить атрибут, записать значение в поток, проигнорировать пакет, перейти к другой ветви либо повторить сопоставление после перестановки Source и Dest. В том же файле формат определял, какие поля reader соберёт.

Поэтому направление было не вечным свойством пакета. Его можно было нормализовать относительно локальной сети, шлюза или well-known port. Это облегчало анализ, но соглашение должно было храниться вместе с числом.

Карточка RFC Editor и IETF Datatracker сохраняют границу: опыт реализации, а не стандарт Интернета и не свидетельство обо всех инсталляциях. Текущий официальный поиск errata RFC 2123 не находит записей. Отсутствие зарегистрированной ошибки не сертифицирует код или последующий вывод.

Отброшенный трафик не оставлял доказательства своего отсутствия

Если интерес представлял только IP, не было смысла буферизовать и разбирать Novell или EtherTalk. NeTraMet изучал активные правила и определял нужные Peer types. Остальные протоколы отбрасывались после распознавания типа. Если Adjacent address нигде не использовался, его не копировали.

Оптимизация экономила процессор и память, но лишала будущего ответа. Полный IP-файл мог точно описать выбранный IP-трафик и всё же не доказывал, что по сегменту не шёл другой протокол. Архитектура RFC 2063 намеренно помещала сокращение данных рядом с точкой измерения. RFC 2123 показал: эффективность и необратимая потеря невыбранного — две стороны одного решения.

Исполняемая форма входила в происхождение данных

Классификация адресов могла включать сотни тестов. NeTraMet находил группы, сравнивающие одинаковый атрибут с одинаковой маской, и перед запуском строил для них хеш-таблицы. Малые группы оставались последовательными; минимальный размер был задан при компиляции.

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

Эти решения делали сложные правила практичными. Одновременно они связывали строку с точным исполняемым представлением. Адрес уже прошёл маску, класс возник по конкретной ветви, а возможности файла ограничивал бинарник. Без этой истории число теряло вопрос, на который отвечало.

Давление памяти меняло смысл без остановки процесса

Максимальный размер таблицы устанавливался при запуске NeTraMet. Инкрементальный garbage collector освобождал неактивные строки после достаточного продвижения известных readers. При отставании сбора свободное место всё равно заканчивалось.

Выше HighWaterMark meter мог включить standby-набор. В Окленде он был похож на production, но сохранял заметно меньше атрибутов. Иногда это позволяло измерителю работать ещё один-два дня после отказа reader и отдать накопленные итоги после его возвращения.

На FloodMark NeTraMet переходил к встроенному default-набору, чтобы сбор мусора не занял столько времени, что manager перестанет получать ответы. Значения 65% и 95% хорошо показали себя в описанном опыте, но не были универсальными порогами.

Работоспособность процесса не равнялась неизменности смысла. Production-, standby- и default-строки могли быть корректны каждая в своей схеме, но различаться охватом и гранулярностью.

Перезапуск начинался раньше возвращения политики

После сбоя meter запускал встроенный набор 1. NeMaC периодически сравнивал sysUptime; уменьшение означало перезапуск. Затем manager вновь загружал backup и production и активировал последний.

В примере keepalive составлял пять минут, сбор — пятнадцать. До загрузки правил могло потеряться до пяти минут данных. Это следствие локального интервала, не общий предел протокола. Кроме того, default-набор мог иначе классифицировать пакеты в этом окне.

Возобновившийся рост счётчика сам по себе не соединял периоды. Нужны были rule identity, граница uptime и момент восстановления.

FlowIndex был повторно используемым местом

После освобождения строки тот же FlowIndex мог достаться новому потоку. RFC 2123 требовал сочетать FlowRuleSet, FlowIndex и StartTime. Один индекс не был постоянной идентичностью.

Чтение по колонкам тоже не замораживало таблицу. Строка могла активироваться после чтения предыдущего столбца и попасть лишь в следующую выборку. Meter MIB RFC 2064 задавал соответствующие объекты управления. Более поздняя архитектура RFC 2722 1999 года относится к следующей редакции и не описывает задним числом каждую площадку 1997 года.

Границы относились и к производительности: около 750 пакетов в секунду на 10-МГц 286, 1 250 на 25-МГц 386SX и сообщения о пиках 3 000 на 40-МГц 486 без потерь. Это наблюдения конкретного железа и нагрузки, не гарантия полноты, расчёта счетов, целостности или конфиденциальности. Последние две задачи RFC оставлял протоколам управления и сбора.

Поздняя работа Lu Heng Running-Code Primacy предлагает смотреть на реально исполненную конфигурацию. Minimum Initial Specification не позволяет локальному выбору стать всеобщим авторитетом. Reality Layers разделяет документ, реализацию, запись и результат. Это поздние аналитические рамки, а не свидетельства о намерениях автора RFC.

Исторический итог RFC 2123 — цепочка хранения доказательства. Manager формулирует вопрос, meter проецирует пакеты, нехватка ресурсов снижает разрешение, reader получает неатомарный вид, analysis создаёт утверждение. Строка ценна, когда эта цепочка видна, а не когда она притворяется нейтральной копией провода.

Источники