Сеанс UDP Netflow
Как netflow определяет конец сессии udp. То есть, как я понимаю, должен быть какой-то таймаут при отсутствии запросов с динамического порта с течением времени, по истечении которого формируется новый сеанс для этого порта. Если да, то как это реализовано, и если есть тайм-аут, сколько он длится
Это область, в которой может быть написано огромное количество, но вот несколько быстрых моментов:
1.) Существует ряд таймеров с любой реализацией Netflow, которые при превышении вызывают запись потока, которая будет экспортирована и удалена из кеша.
2.) Один из этих таймеров - это максимальный таймер. Идея здесь в том, что даже текущий поток вызовет создание записи. Долгоживущий поток на самом деле может генерировать десятки (или сотни) последовательных записей. Хорошим примером этого может быть поток TCP, продолжающийся, скажем, 60 минут в реализации с максимальным таймером 5 минут. Этот поток фактически может быть представлен 12 (+/-) записями. Иными словами, записи создаются даже без FIN (или без завершения сеанса).
3.) Другой таймер - это таймер неактивности / простоя. В этом случае, если трафик для данного потока не виден в течение x секунд, тогда время ожидания записи в кэше истекает и запись экспортируется. Вот как Netflow определяет конец любого потока, отличного от TCP ( подсказка: не все реализации правильно обрабатывают TCP FIN как метод закрытия ). Здесь есть ключевой момент, который следует учитывать: если этот таймер очень длинный, у вас может не быть очень точного представления о том, когда именно данный поток фактически закончился.
переполнение кеша на сборщике Netflow, тогда многие реализации фактически будут устаревать потоки раньше, чтобы освободить место.В идеале это потоки с более длинными таймерами простоя, которые выбираются, но если исчерпание кеша становится достаточно сильным, мы можем фактически достичь вырожденного состояния, когда буквально каждый пакет генерирует новый поток. В стороне, вот почему полный (то есть несэмплированный) Netflow в большинстве современных коммутаторов постоянного тока в значительной степени ушел в прошлое, поскольку сам размер кэша потока становится совершенно неприемлемым.
Итак, как всегда, Дьявол кроется в деталях. Реализации Netflow различаются с точки зрения размера кеша и частоты дискретизации, того, насколько низкими (или высокими) могут быть установлены эти таймеры (и некоторые другие), правильно ли они отслеживают флаги TCP и т.д. фигурирует в IPFIX / v9, где локально программируемая агрегация добавляет еще один уровень посредничества при сборе потоков и т. д.