forum.lissyara.su

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

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

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

про тюнинг я слегка поторопился, единственное что поднял 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%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

так я понял?

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

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

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

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

ipacctd рулит

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

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

zg писал(а):ipacctd рулит

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

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

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

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

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

фантастика

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

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

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

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

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

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

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