Sotflow и потери пакетов

[dark_stealth]

Есть железяка c FreeBSD 6.3 на борту 512Мb/2.8PIV/80Gb. Крутится все Апач1.3, squid2, bind9, mpd5, ipcad, mysql3 .Загрузка процессора не более 10-20% в среднем за сутки. Трафа проходит не более 10гиг в теже сутки.
Для обсчета установлен netup utm5, который получает стату по netflow с ipcad'a. C недавних пор статистика начала иметь расхождение с upstrеam провом до 20%. Причем контрольные замеры показали ,что нагло врет мой утм, но очень странно, временами .Установил на входящий интерфейс softflowd c которого по netflow стату лью на соседний пустой как бубен сервер, где стоит только клон основного утма с чистенькой базой в одного пользователя.
После softflowctl -c /var/run/sfd.ctl.re0 statistics видим :

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

softflowd[70506]: Accumulated statistics:
Number of active flows: 1852
Packets processed: 1023043
Fragments: 1092
Ignored packets: 13161 (13161 non-IP, 0 too short)
Flows expired: 26411 (0 forced)
[b]Flows exported: 50363[/b] in 1748 packets (0 failures)
Packets received by libpcap: 1036243
Packets dropped by libpcap: 0
Packets dropped by interface: 3217012652

В утме на вкладке статистика всего записей netflow 49150(пропало 1213 записей) и это всего за два часа и трафике в 300 мег. Трафик меньше чем на основном утм и гораздо меньше чем по статистике провайдера.
Ошибок на интерфейсах нет, флуда нет, соединения на гигабитных линках.
Вроде что мог через sysctl поднял а потоки нетфлоу куда то теряются. Куда еще копать ?!

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[APM]

А что поднимал то через sysctl?

d 6.3 фряхе можно попробовать netflow собирать из ядра - netgraph

[dark_stealth]

про тюнинг я слегка поторопился, единственное что поднял net.inet.tcp.sendspace=131072,net.inet.tcp.recvspace=131072.
Стата и снималась непосредственно со всех интерфейсов ng_netflow и она расходилась с апстримом. Поставил ipcad и загоняю на него весь траф дивертом- потери, но как не странно меньше. Сейчас fprobe запущен так - fprobe -v7 -n7 -i re0 -fip -S 54 -B4096 -r10 -q10000 -t10000:10000000 192.168.0.2:9996 прямо из мана нагло выдранная строка. Потери чуть меньше но есть.
Softflow ставил из-за статистики, только так стало видно, что количество записей отправленных сенсором не равно принятому на коллекторе. Сразу еще раз оговорюсь- аналогичный утм стоит на тойже локальной машине где и сенсор и у него тоже потери.
На все согласен- канал забит был бы под 100%, народу под 3000 человек, железо глючило бы. НЕТ -все в порядке, а стата не сходится.
p.s. Прову доверяю на 100%

[paradox]

при очень активной загрузке канала все что работает на Libcap будет глючить
юзайте как вам посоветовали ng_netflow
будет вам счатье

[dark_stealth]

Счастье будет, но не скоро Я выше указал, что ng_netflow работал уже, успешно снимал данные с гигабитных интерфейсов и ... занижал статистику.
Сейчас стоит ipcad c и ВСЕ льется через divert через него- считает .... чуть более точно чем ng_netflow.
Стоит ли считать поток 10гиг в сутки "большой нагрузкой" ? Я верю и вижу, что где то теряются netflow записи от сенсора до коллектора

[paradox]

... занижал статистику

а ты уверен что он занижал а не вам завышали?

я перепробовал в свое жизни кучу биллингов и систем обсчета
все показывают разные значение

поэтому пришел к выводу
что если у вас какие то договора с апстрим провайдером
то юзайте туже систему учета и построену таким же способом как и у него
а иначе будут разные значения

если траф раздаеться клинетам выделинщикам
то любыми способами заворачивайте их на pptp или pppoe
потому как просчитаные байтики в соединении виндовса и снятые с ng* интерфейсов совпадают 1:1
и проблем с клиентами тогда нет по претензии обсчета итд

[dark_stealth]

ну я не стал бы во всеуслышание заявлять о беззаветной вере в провайдера на пустом месте Вопрос не в том.
Вопрос почему не все доходит до коллектора, что может мешать прохождению netflow потоков. Давайте примем что стататистика сверху точна 1 к одному. Что может быть не так с сервером... ?

[paradox]

нетфлов это протокол UDP
если путь прохождения статистики это тот же канал где сидять 3000 пользователей
так что ж вы хотите?)

зы
по нормальному
статистику снимают прямо на месте и кладут в базу
зызы
ничего хорошего о УТМ сказать немогу

[dark_stealth]

Эх... не умею я максимально точно формулировать вопросы, как и ответы .
В первом посте описано, что нагрузки нет. Данные передаются по гигабитным линкам в которых- ничего и никого нет .Чистота эксперимента
Качество утма- это притча во языцах -согласен, но опять не в этом суть- даже подставлю на локалхосте flow-tools я теряю потоки. Выделеный сервер для коллектора- избавление от сомнений на сам коллектор. Как выловить ошибку на сервере где расположен сам сенсор ?

[paradox]

хорошо
поставь утм на локальной машине тоесть тамже
что бы записи через лупбек шли
если будет теряться
значит выкинуть утм и всю эту конструкцию
и сдесть нормально
если за несколько суток непотеряеться ниодной записи
значит будем дальше думать...

[dark_stealth]

1.основной утм стоит на локальной машине получает поток netflow от ipcad'a через loсalhost:9996
2.тестовый утм стоит на удаленной машине получает поток netflow от fprobe (softflow,ng_netflow) через никем не занятый выделенный гигабитный интерфейс.
3.Потоки проходящие через локальную машину 10 гиг всего за 24 часа.
4. Думаем дальше?
p.s. чуток выше все описано более подробно

[paradox]

)) все мозг мой вскипел
все что выше я тоже читал

и так
то что понял я
1 это есть машина через котороую идет траф
2 она собирает статистику и по нетфлов кидает их на другую машину
3 на другой машине нетфлов скаладываеться статистика

так вот отправленная статистика 2) несооотвествует принятой статитике 3) точнее отсутсвуют записи нетфлов

так я понял?

[dark_stealth]

нет мозг вскипел у меня
Есть машина через которую идет траф, на ней стоит сервер статистики который недосчитывает какое то количество байт. Данные статистики отправляет по локальному интерфейсу ipcad по netflow.

[paradox]

Есть машина через которую идет траф, на ней стоит сервер статистики который недосчитывает какое то количество байт

ipcad работает на основе libcap а либкап всегда будет дропать пакеты - даже в мане написано что она негарантирует что все пакеты поймает...

или чего то опять непонимаю))

[zg]

ipacctd рулит

[paradox]

ipaсctdd грузит систему слишком

[dark_stealth]

хорошо, я меняю ipcad на ng_netflow- потери остались. Общая точка соприкосновения netflow поток у этих двух сенсоров.

ipacctd рулит

да нормально он работает на другом роутере он и стоит считает от силы гиг в сутки.
Но не устраивает, что слишком мало у него инфы в отличии от netflow v5. ng_ipacctd не предлагать- большого отличия не вижу от тогоже ng_netflow:)

[paradox]

хорошо, я меняю ipcad на ng_netflow- потери остались. Общая точка соприкосновения netflow поток у этих двух сенсоров

флов експорт идет локально на этот же комп или куда то далеко в сеть?

потери в записях поличество експортируемых к принятым или в подсчитаном траффике?

[dark_stealth]

экспорт netflow идет на этот же комп.
Потери и в количестве принятых-переданных записей netflow. так и в статистике соответственно

[paradox]

фантастика

зы
ng_netflow помоему неведет статику сколько пакетов отдал или?

[dark_stealth]

"в лоб" нет статистики перадача-прием у ng_netflow. Такое есть у softflow и по ней видно,что количество переданных записей от сенсора больше чем количество принятых коллектором.

[paradox]

это уже за гранью фантастики
либо нетап неумеет быстро отрабатывать прием пакетов

попробуй другие альтернативы по приему нетфлов пакетов....
будут там потери такие же?

[dark_stealth]

Не хочется огород городить с flow-tools. Хотя чую- придется.
В скорости обработки.... были бы там потоки толстые я бы еще и подумал, а то пара десятков гиг мелочи...
у апстрима стоит тотже 5 утм и поток "слегка" потолще и там считает точно, тому свидетель второй роутер в другом месте со считалкой на основе ipacctd'a. Здесь стата идентична с провом.
что то не в порядке в прохождении netflow-stream в пределах одной машины

[paradox]

может стоит сравнить uname -a
на обеих машинах
и посмотреть на тюнинг
как вариант уменьшить время сбрасывания потока нетфлов
может реально в системе неуспеваеться отаботаться огромноге количество пакетов UDP за один глоток воздуха

[dark_stealth]

время сбрасывания активного потока в ipcad'e уменьшал до 5 секунд (знаю, что меньше минуты нельзя по дефолту- правил чуток conf.y)
время сбрасывания неактивного снижал до 5 сек, увеличивал до 10, 30 сек результата нет.
uname машин несколько различаются- debian у провайдера и freebsd у меня.
Все машины у меня идентичны- frebsd 6.3 c идентичным тюнингом.