Mikrotik + netflow = чудеса в решете
Mikrotik + netflow = чудеса в решете
При использовании сабжа как коллектора трафика (версия Микротика - 2.9.6) выяснилась интересная проблема.
Иногда (при невыясненных до сих пор обстоятельствах) с Микротика на биллинг прилетает "чудесная" запись о потоке трафика - например:
<row>
<row_id>5607</row_id>
<col_Дата>16.11.2005 20:34:43</col_Дата>
<col_ID_связки>43</col_ID_связки>
<col_Лицевой_счет>44</col_Лицевой_счет>
<col_Класс_трафика>Входящий (10)</col_Класс_трафика>
<col_Источник>212.118.48.163</col_Источник>
<col_Получатель>192.168.0.12</col_Получатель>
<col_Пакетов>2</col_Пакетов>
<col_Байт>890037757</col_Байт>
<col_Порт_ист.>2347</col_Порт_ист.>
<col_Порт_получ.>59841</col_Порт_получ.>
<col_TCP-флаги>62</col_TCP-флаги>
<col_протокол>127</col_протокол>
<col_Tos>109</col_Tos>
</row>
т.е. между отправителем и получателем прошло 2 пакета данных общим объемом 848 мегабайт (!!!!!!).
Откуда Микротик берет такую инфу и Микротик ли в этом виноват - доподлинно не известно. На текущий момент биллинг словил 5 штук таких потоков с 3 разных роутеров, на всех - микротик.
Чем это плохо - со счета пользователя мгновенно слетает весьма крупная сумма денег (например, за 3 гигабайта входящего трафика за секунду). Причем данный поток явно некорректен и невозможен в принципе.
Каким образом можно отфильтровать такие потоки и откуда они берутся?
NetUp предложил "индивидуальную доработку", но может быть кто-то уже сталкивался?
P.S. UTM-5.1.10-016, установлен на FreeBSD 5.4
Иногда (при невыясненных до сих пор обстоятельствах) с Микротика на биллинг прилетает "чудесная" запись о потоке трафика - например:
<row>
<row_id>5607</row_id>
<col_Дата>16.11.2005 20:34:43</col_Дата>
<col_ID_связки>43</col_ID_связки>
<col_Лицевой_счет>44</col_Лицевой_счет>
<col_Класс_трафика>Входящий (10)</col_Класс_трафика>
<col_Источник>212.118.48.163</col_Источник>
<col_Получатель>192.168.0.12</col_Получатель>
<col_Пакетов>2</col_Пакетов>
<col_Байт>890037757</col_Байт>
<col_Порт_ист.>2347</col_Порт_ист.>
<col_Порт_получ.>59841</col_Порт_получ.>
<col_TCP-флаги>62</col_TCP-флаги>
<col_протокол>127</col_протокол>
<col_Tos>109</col_Tos>
</row>
т.е. между отправителем и получателем прошло 2 пакета данных общим объемом 848 мегабайт (!!!!!!).
Откуда Микротик берет такую инфу и Микротик ли в этом виноват - доподлинно не известно. На текущий момент биллинг словил 5 штук таких потоков с 3 разных роутеров, на всех - микротик.
Чем это плохо - со счета пользователя мгновенно слетает весьма крупная сумма денег (например, за 3 гигабайта входящего трафика за секунду). Причем данный поток явно некорректен и невозможен в принципе.
Каким образом можно отфильтровать такие потоки и откуда они берутся?
NetUp предложил "индивидуальную доработку", но может быть кто-то уже сталкивался?
P.S. UTM-5.1.10-016, установлен на FreeBSD 5.4
С такой проблемой не сталкивались. Можно предложить разобраться по порядку.
включите в get_xyz логгинг собранных данных в файл. Как появится вновь такая запись - посмотрите в этот файл. Есть ли такая запись ?
Вторым вариантом можно аналогично использовать tcpdump на 80 порту. Вы ведь собираете данные с микротика через cgi-bin ?
включите в get_xyz логгинг собранных данных в файл. Как появится вновь такая запись - посмотрите в этот файл. Есть ли такая запись ?
Вторым вариантом можно аналогично использовать tcpdump на 80 порту. Вы ведь собираете данные с микротика через cgi-bin ?
Пользуем тоже 2.9.6. Для фильтрации исползуется конструкция:
filter-primitive test-routers
type ip-address
deny ipaddr1
deny ipaddr2
... bla-bla-bla...
default permit
filter-definition routers
match nexthop-ip-addr test-routers
ipaddr1...N - это IP маршрутизаторов, которые одновременно снимают статистику по netflow, являются транзитными для остальных маршрутизаторов, и ко всему еще и терминируют клиентские PPPoE/PPTP/IPIP/GRE соединения.
Таким макаром происходит отсеивание удванивания-утраивания- и тд трафика в отчетах по мере прохождения пакета от одного роутера к другому.
filter-primitive test-routers
type ip-address
deny ipaddr1
deny ipaddr2
... bla-bla-bla...
default permit
filter-definition routers
match nexthop-ip-addr test-routers
ipaddr1...N - это IP маршрутизаторов, которые одновременно снимают статистику по netflow, являются транзитными для остальных маршрутизаторов, и ко всему еще и терминируют клиентские PPPoE/PPTP/IPIP/GRE соединения.
Таким макаром происходит отсеивание удванивания-утраивания- и тд трафика в отчетах по мере прохождения пакета от одного роутера к другому.
у нас на шлюзах с микротиком стоит нат на статические адреса пользователей, так что удваивания-утраивания не происходит - ip пользователей терминируются натом. Но "бракованные" пакеты имеют место быть. Ручным анализом таблиц гигабейса было выявлено еще несколько более мелких неправильных потока (по несколько десятков, но не сотен мегабайт). Временно решили ее путем записи всего трафика с ненулевым полем ToS в отдельный, нетарифицируемый класс в биллинге. Но кроме неправильных пакетов в этот класс накапливаются также и какая-то часть правильных (весьма незначительная, порядка 5-10 мегабайт на 2Гб трафика).
Кроме ТоСа эти потоки можно отсеять, если при приеме потока проверять корректность MTU - соотношение байт/пакетов. По-умолчанию MTU=1500, и при его превышении в 100 раз, как в приведенном мной примере, этот поток явно можно отфильтровать.
Видимо придется сочинять громоздкую конструкцию из flow-receive, декодирования полученного потока, расчета MTU и flow-send на биллинг.
Видимо придется сочинять громоздкую конструкцию из flow-receive, декодирования полученного потока, расчета MTU и flow-send на биллинг.