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