7.1rc1+ Отчёты о трафике показывают несуществующие IP-адреса как SRC в отчётах о потоках для пакетов, которые никогда не появлялись в сети.

Вопрос к более широкой аудитории, есть ли у кого-то опыт использования netflow-отчетности и наблюдал ли кто-то такое поведение? Кто-то, кто использует flow-отчеты, сталкивался с этим? Мне удалось воспроизвести это на разных моделях, к которым у меня есть доступ, и я удивлён, что никто этого раньше не заметил. Я проверил версию 7.1rc5 — проблема там тоже есть. Корень проблемы в том, что устройства Mikrotik через netflow сообщают о потоке, которого на самом деле не было в сети. При включённом flow-отчёте запрос wget http://some-ip-that-does-not-exist-on-network-but-defined-in-network-subnet создаёт netflow-запись на исходящий пакет (TCP SYN), что ожидаемо, но также указывает на возвратный пакет ACK/FIN от IP-адреса, которого в сети нет. Анализатор пакетов и torch не показывают такого возвратного пакета в сети. Похоже, что этот пакет полностью выдуман в flow-отчётах Mikrotik и нигде больше не отражается. В результате, команда nmap -p 80 -Pn 192.168.0.0/16 или 10.0.0.0/8 или 172.16.0.0/12 испортит работу любого инструмента flow-отчётности, создавая в них несуществующие конечные точки. В моих тестах я проверял это с ntop-ng. Также проверялся VyOS, pfSense, Cisco, Juniper, Ruckus и Mikrotik до серии 7.1 RC — эти устройства с netflow так не ведут себя. Там возвратные пакеты не отображаются, как и должно быть.

7.1 ТЕСТИРОВАНИЕ по-прежнему показывает проблемное поведение.

— Документирую на случай, если кто-то из сообщества столкнется с такой же ситуацией — Обновление по делу: последний ответ от mikrotik был 4 октября, несмотря на то, что я предоставлял обновления по запросу. Моя последняя попытка до включения этого вопроса в решение по обновлению сети в январе. Сейчас просто хочу получить какое-то подтверждение — будет ли это решаться или нет. К сожалению, мой кейс требует исправной работы netflow.

Отправил в поддержку по моему делу:  
Хотел бы узнать новости по SUP-60021. Уже больше двух месяцев нет никакого ответа. Теперь, когда v7 считается «стабильной», отсутствие обратной связи меня беспокоит. Мне сказали, что, вероятно, это задуманный механизм. Но за последние два месяца я доказал (прикреплённые материалы к делу), что такого поведения не было в 7.1beta6 и ранее (в том числе в 6.x), оно появилось в 7.1rc1 и новее. Мог бы кто-нибудь ответить, чтобы я понимал, что вопрос расследуется? Или хотя бы скажите, если это не собираются исправлять, пока не начнут жаловаться другие, кто зависит от netflow, чтобы я мог начать искать производителя сети, который соблюдает RFC.

Мне нужно использовать возможности v7.1 в моей продуктивной сети, но из-за неработающего netflow обновление невозможно.  

Кратко: netflow в текущей реализации умеет отправлять отчет о трафике, когда TCP-сессия пытается установиться с несуществующим IP — этот несуществующий IP попадает в отчет как src трафика, из-за чего анализаторы потока думают, что это реальная точка, искажая отчеты и делая netflow ненадежным источником информации. В 7.1BETA6 и версиях ниже такого не было.

Спасибо за исследование. Я ценю ваши усилия. Однако это не объясняет, почему поведение изменилось. Я проверял в своём тикете поддержки, и действительно подтвердил, что поведение изменилось. Кроме того, это происходит только с TCP и только иногда. Если бы такое поведение было обязательным для завершения сессии, я бы ожидал, что оно будет постоянным, но это не так. Ещё, Mikrotik — единственный производитель, на оборудовании которого я это тестировал и где такое происходит. Что касается меня, то в моей сети эта проблема больше не актуальна, так как мы обновили роутеры на другого производителя, где корректно работает netflow.