Traffic flow и interfaces: all

Обсуждение ПО и его настройки
Ответить
weasel
Сообщения: 3
Зарегистрирован: 23 сен 2019, 15:19

Добрый день! Столкнулся с проблемой, есть несколько разных микротиков, все на 6.45.6. На отдельный порт прилетают клиентские влан-ы, разбираются и бриджуются с аплинком. Нужно логировать клиентский трафик. Для теста установил на сервер flow-tools, настроил порты на приём, настраиваю на микротиках traffic flow:

Код: Выделить всё

/ip traffic-flow> print 
                enabled: yes
             interfaces: all
          cache-entries: 16k
    active-flow-timeout: 30m
  inactive-flow-timeout: 15s
Смотрю в логи flow-tools - тишина, меняю настройки интерфейсов: вместо all выбираю один из клиентских vlan-ов, flow-пакеты появляются. Причем на отдельных железках всё работает ок, на других вот так.
Может кто нибудь подсказать особенности использования опции interfaces: all или в какую сторону имеет смысл копать?

Прим.: железо и конфиги разношерстные, общая только версия прошивки и логика заведения клиентов


Sertik
Сообщения: 1598
Зарегистрирован: 15 сен 2017, 09:03

Не понял как это клиентские вланы бриджуются с аплинком ?
Если Вы имеете ввиду что аплинк это WAN-порт а Вланы это фактически разные локальные сети то зачем WAN бриджевать с LAN ?


фрагменты скриптов, готовые работы, статьи, полезные приемы, ссылки
viewtopic.php?f=14&t=13947
weasel
Сообщения: 3
Зарегистрирован: 23 сен 2019, 15:19

Суть схемы в том чтобы принять тэгированый клиентский трафик, порезать его шейпером по номерам вланов и пустить его выше уже не тэгированым, в этой части всё ок, всё работает, шейпится и роутится. А вот трафик флоу не летит, просто интересно что именно он подразумевает под interfaces: all, если по отдельному влану он трафик флоу видит и шлет, т.е. в нужные цепочки этот трафик все таки попадает... ну или вариант что он просто не может такой поток трафика обработать (150-200 вланов, ~150мбит), но вроде железки должны тянуть (ccr1009)


weasel
Сообщения: 3
Зарегистрирован: 23 сен 2019, 15:19

оказалось все проще, всё дело в мту на выходе с микротика стоял мту 1500, но на стороне сервера с нетфлоу всё прилетало в бридж с мту 1430, и с загруженных микротиков пакеты нетфлоу начинали фрагментироваться, после чего становились не читаемы для флоу-тулз и прочишь собиралок, после выравнивания мту по пути следования проблема ушла


Ответить