Нереалистичные данные в Elastiflow?

Question

[neo2121]

Добрый день! Недавно развернул ElastiFlow для мониторинга происходящего в среде. Добавил пару Mikrotik для теста. По некоторым из них наблюдаю всплески по типу таких, как на скриншоте. Не могу понять от куда берутся такие объемы данных, которые рисует ElastiFlow. Наблюдаемые Mikrotik обычные антенны, аля SXT R, на мой взгляд, у них не наберется столько мощи для выдачи таких показателей, да и пропускная способность канала не позволила бы. Может быть кто-то встречался с аналогичной проблемой? Подскажите куда копать. Также стоит сказать, что указанные ip адреса не принадлежат данным хостам

Answer 1

[neo2121]

Дело оказалось в реализации Mikrotik'ом протокола Net Flow v9, переключил на IPFIX проблемы более не наблюдается

Upd. Я все еще не решил проблему

Comments

[neo2121]

При дальнейших тестах стало понятно, что это не было решением. Я также менял версию netflow на 5. Изменял параметры кеша и таймаут времени активного потока, но безуспешно. Я все еще получаю странные данные которые исходят из одной записи. Я также тестировал параллельно писать данные в другой коллектор (NetFlow Analyzer), пики с неизвестными данными в нем аналогично можно увидеть, но в другое время. Видимо дело в поведении самого микротика.

Сегодня я писал в Slaсk разработчику, он пеняет на то что их софт всего лишь отображает то, что приходит и посоветовал попробовать найти проблему анализатором трафика..

В общем, любые мысли по поводу этой проблемы будут полезны. В данный момент на mikrotik (6.49.13) следующие настройки

[neo2121]

После дальнейших разбирательств стало ясно что "нереалистичные" записи приходят с идентификаторами неких динамических интерфейсов (например IfIndex45448), тогда как данные с реальных интерфейсов (IfIndex4, IfIndex8) это не затрагивает. Почему возникают динамические интерфейсы и что за данные в них "летают", при мониторинге l2tp интерфейса, я пока не понимаю. Мониторю я клиентов vpn и дополнительно зафиксировать интерфейс l2tp подключения, как в случае с сервером, я не могу

Answer 2

[DoctorCat92]

Думаю вам нужно ещё задать этот вопрос на форуме Elastiflow. Хабр место где есть люди с опытом, но всётаки, когда вы тут задаёте вопрос - вы предполагаете что найдётся человек, среди Ру комьюинити, среди системных администраторов, да ещё и среди тех кто читает хабр, а среди них те кто отвечают на вопросы, у которых в свою очередь была такая же была проблема.

Рекомендую вопрос задать на форуме продукта, т.к. там топики читают не абы кто, а разработчики.

Раз уж меня 13 августа занесло в этот топик, и если проблема всё ещё актуальна - у меня была похожая проблема, и я как раз ответ на нё нашёл на форуме разработчика. Моя проблема была связана с использованием старой версии из докера, которую я установил по мануалу от ноунейма с гитхаба, и после установки самой новой и актуальной версии - проблема больше не наблюадалсь.

Comments

[neo2121]

Выше я писал о том, что обращался к разработчикам в Slaсk, мы выяснили что версия у меня не старая, а проблема со стороны микротика. Забегая вперед в поддержке микротика построили дурачка и забили на мой тикет. Проблема актуальная и я решил ее для себя тем что удаляю информацию о "динамических" интерфейсах на стороне системы мониторинга

Answer 3

[zeebeedee]

Столкнулся с этой проблемой, и решил её.
Дело в следующем: протокол netflow v9 весьма гибкий, и позволяет экспортерам netflow задавать свои шаблоны данных. Так, экспортеры netflow регулярно передают особые flowset, которые определяют шаблоны передаваемых данных.
Шаблон идентифицируется полем Template Id. Микротик использует 256 для шаблона ipv4 и 257 для шаблона ipv6. И всё бы ничего, если б микротик не менял шаблон от версии к версии, или менял бы template Id со сменой шаблона!
Логстеш или flowbit ориентируются на template Id при выборе шаблона для парсинга пакетов netflow. При получении нового шаблона с тем же Id, шаблон заменяется, и пакеты с хостов с несоответствующим шаблоном начинают парситься неправильно.
Решение одно - разнести микроты разных версий по разным пайплайнам логстеш.