ipcad - насколько надежен ?

[Ugnich Anton]

Если на subj делать учет траффика, не будет ли он пропускать не обсчитывая пакеты при большой нагрузке на сервер ? Можно ли на базе subj сделать нормальную систему подсчета ? Нормальную - имеется ввиду без глюков при любой нагрузке.

Система - Linux 2.6.

 

P.S. На каком-то форуме (вроде бы opennet) писали о неточности подсчета через netflow и ip accouting в оборудовании Cisco. Но я так понял, там имелось ввиду, что считается просто разный траффик: в первом случае, тот, что пришел на киску, во втором - что ушел юзерам. Я правильно понял ?

[Guest]

Если на subj делать учет траффика, не будет ли он пропускать не обсчитывая пакеты при большой нагрузке на сервер ? Можно ли на базе subj сделать нормальную систему подсчета ? Нормальную - имеется ввиду без глюков при любой нагрузке.

Система - Linux 2.6.

 

ИМХО нельзя. При нагрузке ipcad (как и любая софтина работающая в user-level) будет не учитывать трафик.

 

Наш выбор: freebsd+ng_netflow (ng_ipacct). Работают в kernel-level, считают при любых нагрузках.

 

Во время тестов разница в показания ng_netflow и цифер с циски составляла сотни килобайт на гиг трафика.

[Ugnich Anton]

ИМХО нельзя. При нагрузке ipcad (как и любая софтина работающая в user-level) будет не учитывать трафик.

 

Наш выбор: freebsd+ng_netflow (ng_ipacct). Работают в kernel-level, считают при любых нагрузках.

 

Во время тестов разница в показания ng_netflow и цифер с циски составляла сотни килобайт на гиг трафика.

Т.е. даже ng_netflow не спасает от потерь ?!

Или разница возникла по другой причине ?

[DiBrain]

ipcad умеет брать статистику с ULOG а это уже кернел уровень.

Причем отправлять ему можно не весь пакет а только заголовок.

Ну и естественно фильтровать, а что именно ему посылать на учет.

[Guest]

ipcad теперь умеет работать и с libipq, что практически исключает потери.

[Guest]

ИМХО нельзя. При нагрузке ipcad (как и любая софтина работающая в user-level) будет не учитывать трафик.

 

Наш выбор: freebsd+ng_netflow (ng_ipacct). Работают в kernel-level, считают при любых нагрузках.

 

Во время тестов разница в показания ng_netflow и цифер с циски составляла сотни килобайт на гиг трафика.

Т.е. даже ng_netflow не спасает от потерь ?!

Или разница возникла по другой причине ?

 

Разницу образуют повторные передачи дропнутых/потерянных пакетов. В тепличных условиях показания совпадали до байта.

[Guest]

ipcad умеет брать статистику с ULOG  а это уже кернел уровень.

Причем отправлять ему можно не весь пакет а только заголовок.

Ну и естественно фильтровать, а что именно ему посылать на учет.

 

А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний?

[RomanRom2]

я затестил ipcad на своем файловом сервере под управлением mandrake 10. ядро 2.6.3. правда тача быстрая надо сказать - p4p800/ip4 2800c/1024/onboard gigabit 3com, винты простые сигейты и максторы. сеть 100мбит, на неуправляемых свитчах.

 

считаю входящий исходящий трафик на этом сервере, там не только самба, там и 5 радио каналов, там игровые сервера (правда практически не юзаются).

 

давал ему загруз с 5 компов, каждый из них прокачивал по 30-40 гиг в каждую сторону ОДНОВРЕМЕННО. время той прокачки заняло несколько часов.

 

результат отличный. ipcad показал чуть больший объем, чем реальные объемы файлов. ну - это и понятно почему.

 

ipcad взял из дистрибутива asplinux 10, готовый, какой есть.

[root@warez root]# rpm -q ipcad

ipcad-3.6.2-0.10.0asp

 

когда тестил старый ipcad версий 2.х.х - пакеты пропускал. правда и тестил я его на первом пне... :)

[Guest]

я затестил ipcad на своем файловом сервере под управлением mandrake 10. ядро 2.6.3. правда тача быстрая надо сказать - p4p800/ip4 2800c/1024/onboard gigabit 3com, винты простые сигейты и максторы. сеть 100мбит, на неуправляемых свитчах.

 

считаю входящий исходящий трафик на этом сервере, там не только самба, там и 5 радио каналов, там игровые сервера (правда практически не юзаются).

 

давал ему загруз с 5 компов, каждый из них прокачивал по 30-40 гиг в каждую сторону ОДНОВРЕМЕННО. время той прокачки заняло несколько часов.

 

результат отличный. ipcad показал чуть больший объем, чем реальные объемы файлов. ну - это и понятно почему.  

 

ipcad взял из дистрибутива asplinux 10, готовый, какой есть.

[root@warez root]# rpm -q ipcad

ipcad-3.6.2-0.10.0asp

 

когда тестил старый ipcad версий 2.х.х - пакеты пропускал. правда и тестил я его на первом пне... :)

 

Сферический конь в ваккуме :)

[DiBrain]

А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний?

А какая считалка вообще в этом случае чегото вразумительное насчитает?

RomanRom2 такая загрузка это не загрузка. Загрузка меряется не только в мбайтах в секунду, но и в пакетах в секунду.

Причем тачки загибаются чаще всего именно из-за кол-ва пакетов.

Особенно когда трафик идет не с одной связкой srs ip -- dst ip

а например srs ip -- очень много dst ip.

Например когда msblast флудит.

[RomanRom2]

хмм...

 

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

 

все четко посчитано. никто не забыт :)

 

не знаю, стоит ли верить всему получившимуся теперь. и тем не менее, можно сказать в первом приближении оно справляется.

 

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

[Guest]

Если трафик считает libipq, то я себе слабо предстваляю ситуацию просасывания трафика. Если прога, на которую вешается libipq не скажет NF_ACCEPT, пакет просто не пройдет.

[Guest]

Решил собрать себе ipcad по-приколу и запустить его через libipq, но вот что-то проблема. Собралось-то все нормально, дальше говорю:

iptables -A INPUT -j QUEUE

т.е. все входящие пакеты кидать в QUEUE

затем:

ak-laptop:/usr/local/bin# ./ipcad

Opening ipq... [LCap] Can't initialize: Connection refused

 

Блин, и чё .... ?

 

У меня вот мой собственный биллинг работает тоже на libipq, там просто маааленький daemon раз в 5 минут скидывает статистику накопившуюся в файлики текстовые + поддерживает файл конфига с ip юзеров которых можно в инет пускать, дак вот ему больше ничего не надо для работы ...

[Guest]

А у меня работает.

ipcad 3.6.5, iptables 1.2.11, debian

[Guest]

А, блин, я сам злобный чебурашка. Забыл сказать

modprobe ip_queue :)

 

так-то видимо тот-же debian sarge, все версии те же, теперь заработало :)

[Guest]

ipcad умеет брать статистику с ULOG  а это уже кернел уровень.

Причем отправлять ему можно не весь пакет а только заголовок.

Ну и естественно фильтровать, а что именно ему посылать на учет.

 

А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний?

 

а что насчитает ng_netflow, при том что количество пакетов будет больше, чем машина способна обработать?

 

всему свое место, и все должно быть в меру,

неразумно ставить слабую машину с ipcad на 100 мегабитные линки с полной нагрузкой и кучей юзеров,

так и на оборот

 

а вообще ng_netflow хорошая вещь, сам его пока в тесте гоняю

 

__________

ky

[Ansy]

До кучи -- отрекомендуйте, пожалуйста, старичка net-acct (юзается в сертифицированных биллингах) и новичка pmacct.

 

Год с лишним юзаю первого и суммирую логи awk-скриптом. Точность устраивает, на 20 гигах внешнего трафа в месяц расхождение с Циской аплинка <0.5%.

 

Плохо, что net-acct уже давно не развивается, и считает закрытые сессии, без возможности сбросить накопленное принудительно :( Т.е. реально втянуть ISO-образ CD одним потоком -- и все 700 метров появятся одной строкой в логе лишь в конце закачки. А то и перейдут на следующий месяц...

Плюс -- логи достаточно полные для разбора полетов. Минус -- забиваются мусором при атаках.

 

pmacct вроде как в усиленной разработке -- опасаюсь ставить, но надежды подает. Однако он только счетчик -- концов не найдешь в случае спора. Впрочем, Циска в этом плане не лучше, да?

 

Вообще, IMHO, главное чтобы с аплинком в "минус" не расходилось, а с клиентом в "плюс" не слишком. Ни байта неучтенного врагу :)

[Guest]

ipcad умеет брать статистику с ULOG  а это уже кернел уровень.

Причем отправлять ему можно не весь пакет а только заголовок.

Ну и естественно фильтровать, а что именно ему посылать на учет.

 

А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний?

 

а что насчитает ng_netflow, при том что количество пакетов будет больше, чем машина способна обработать?

 

ng_netflow посчитает все что пройдет через машину. Если пакетик передан - он посчитан и информация о нем уйдет на коллектор.

 

всему свое место, и все должно быть в меру,  

неразумно ставить слабую машину с ipcad на 100 мегабитные линки с полной нагрузкой и кучей юзеров,

 

А вот кастрюлю с ng_netflow туда ставить можно. И пусть она будет стоять раком, до полной потери интерактивности, но весь трафик будет посчитан.

[Guest]

А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний?

А какая считалка вообще в этом случае чегото вразумительное насчитает?

 

ng_netflow, ng_ipacct

[avial]

У меня ipcad отказался собираться из сырцов (сильно разбираться не стал, может из-за gcc-2.95). Поставил fprobe-ulog, netflow с него падает в файлики и сразу в mysql экспортируется.

В отличии от остальных коллекторов ULOG (перепробовал все, какие собрались, особенно ulogd не понравился), очень мало грузит проц. 60-70Мбит поток всего 0.3-0.6% отъедает. Если вирусная атака - 2-3%. Ulogd сам брал 30% и при прямом экспорте в mysql остальное брала база.

С таким коллектором загрузить роутер трафиком проблематично. А если роутер грузится чем-то еще - никакие ng_netflow не помогут - терятся будут не пакеты, а потоки netflow.

[Guest]

У меня ipcad отказался собираться из сырцов (сильно разбираться не стал, может из-за gcc-2.95). Поставил fprobe-ulog, netflow с него падает в файлики и сразу в mysql экспортируется.

В отличии от остальных коллекторов ULOG (перепробовал все, какие собрались, особенно ulogd не понравился), очень мало грузит проц. 60-70Мбит поток всего 0.3-0.6% отъедает. Если вирусная атака - 2-3%. Ulogd сам брал 30% и при прямом экспорте в mysql остальное брала база.

С таким коллектором загрузить роутер трафиком проблематично. А если роутер грузится чем-то еще - никакие ng_netflow не помогут - терятся будут не пакеты, а потоки netflow.

 

Проводился эксперимент, понятно что мерялись попугаи, причем весьма относительные, но нас именно это и интересовало.

 

P166MMX + 2 риалтека

1) какой-то редхат + fprobe, ulog и др...

2) та же кастрюля, но freebsd 5.3 + ng_netflow

 

Качалось кино с одной быстрой машины на другую быструю машину через вышеописанный роутер.

 

В случае с fprobe, без потерь удавалось учесть траф при потоке до 20-30Мбит/сек (причем ближе к 20, чем к 30). Максимум лежал в районе 60 Бмит/сек. При прокачке на максимальной скорости роутер впадал в кому, полностью терял интерактивность. Трафик не учитывался вообще.

 

Во втором случае, максумум лежал в райное 70 Мбит/сек, роутер впадал в кому, терял интерактивность, но netflow исправно пукало и разница с цифрами с циски составляла менее 0.1%.

 

В результате, было принято решение менять на роутерах ОС. На тот момент их было около 150. Сейчас новые роутеры ставятся исключительно на фре и потихоньку меняются линуксовые.

 

Я не пытаюсь никого ни в чем переубедить, просто случай из жизни :)

 

Понятно, что когда роутеры на P4, для подсчета трафика можно использовать что угодно. Но когда речь идет о "любой нагрузке" - ng_netflow only :) imho.

 

P.S. Кроме того, если в сетке уже льется/считается netflow с цисок, такие роутеры довольно просто вписываются в существующую схему.