Ugnich Anton Опубликовано 27 января, 2005 · Жалоба Если на subj делать учет траффика, не будет ли он пропускать не обсчитывая пакеты при большой нагрузке на сервер ? Можно ли на базе subj сделать нормальную систему подсчета ? Нормальную - имеется ввиду без глюков при любой нагрузке. Система - Linux 2.6. P.S. На каком-то форуме (вроде бы opennet) писали о неточности подсчета через netflow и ip accouting в оборудовании Cisco. Но я так понял, там имелось ввиду, что считается просто разный траффик: в первом случае, тот, что пришел на киску, во втором - что ушел юзерам. Я правильно понял ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 27 января, 2005 · Жалоба Если на subj делать учет траффика, не будет ли он пропускать не обсчитывая пакеты при большой нагрузке на сервер ? Можно ли на базе subj сделать нормальную систему подсчета ? Нормальную - имеется ввиду без глюков при любой нагрузке.Система - Linux 2.6. ИМХО нельзя. При нагрузке ipcad (как и любая софтина работающая в user-level) будет не учитывать трафик. Наш выбор: freebsd+ng_netflow (ng_ipacct). Работают в kernel-level, считают при любых нагрузках. Во время тестов разница в показания ng_netflow и цифер с циски составляла сотни килобайт на гиг трафика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ugnich Anton Опубликовано 27 января, 2005 · Жалоба ИМХО нельзя. При нагрузке ipcad (как и любая софтина работающая в user-level) будет не учитывать трафик. Наш выбор: freebsd+ng_netflow (ng_ipacct). Работают в kernel-level, считают при любых нагрузках. Во время тестов разница в показания ng_netflow и цифер с циски составляла сотни килобайт на гиг трафика. Т.е. даже ng_netflow не спасает от потерь ?! Или разница возникла по другой причине ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DiBrain Опубликовано 27 января, 2005 · Жалоба ipcad умеет брать статистику с ULOG а это уже кернел уровень. Причем отправлять ему можно не весь пакет а только заголовок. Ну и естественно фильтровать, а что именно ему посылать на учет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 27 января, 2005 · Жалоба ipcad теперь умеет работать и с libipq, что практически исключает потери. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 28 января, 2005 · Жалоба ИМХО нельзя. При нагрузке ipcad (как и любая софтина работающая в user-level) будет не учитывать трафик. Наш выбор: freebsd+ng_netflow (ng_ipacct). Работают в kernel-level, считают при любых нагрузках. Во время тестов разница в показания ng_netflow и цифер с циски составляла сотни килобайт на гиг трафика. Т.е. даже ng_netflow не спасает от потерь ?! Или разница возникла по другой причине ? Разницу образуют повторные передачи дропнутых/потерянных пакетов. В тепличных условиях показания совпадали до байта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 28 января, 2005 · Жалоба ipcad умеет брать статистику с ULOG а это уже кернел уровень.Причем отправлять ему можно не весь пакет а только заголовок. Ну и естественно фильтровать, а что именно ему посылать на учет. А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanRom2 Опубликовано 28 января, 2005 · Жалоба я затестил 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.х.х - пакеты пропускал. правда и тестил я его на первом пне... :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 28 января, 2005 · Жалоба я затестил 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.х.х - пакеты пропускал. правда и тестил я его на первом пне... :) Сферический конь в ваккуме :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DiBrain Опубликовано 29 января, 2005 · Жалоба А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний? А какая считалка вообще в этом случае чегото вразумительное насчитает? RomanRom2 такая загрузка это не загрузка. Загрузка меряется не только в мбайтах в секунду, но и в пакетах в секунду. Причем тачки загибаются чаще всего именно из-за кол-ва пакетов. Особенно когда трафик идет не с одной связкой srs ip -- dst ip а например srs ip -- очень много dst ip. Например когда msblast флудит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanRom2 Опубликовано 29 января, 2005 · Жалоба хмм... к предыдущим условиям добавил два компа, сканирующих B-шную сеть. плюс еще один маскарадом на этой же таче в инет пустил. инет тормозит, спору нет, все ж забито. но... все четко посчитано. никто не забыт :) не знаю, стоит ли верить всему получившимуся теперь. и тем не менее, можно сказать в первом приближении оно справляется. конечно, демон, пропускающий через себя пакеты - совсем другое дело. я написал и его, им тоже считаю. да вроде как одинаково, до байта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 30 января, 2005 · Жалоба Если трафик считает libipq, то я себе слабо предстваляю ситуацию просасывания трафика. Если прога, на которую вешается libipq не скажет NF_ACCEPT, пакет просто не пройдет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 30 января, 2005 · Жалоба Решил собрать себе 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 юзеров которых можно в инет пускать, дак вот ему больше ничего не надо для работы ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 30 января, 2005 · Жалоба А у меня работает. ipcad 3.6.5, iptables 1.2.11, debian Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 30 января, 2005 · Жалоба А, блин, я сам злобный чебурашка. Забыл сказать modprobe ip_queue :) так-то видимо тот-же debian sarge, все версии те же, теперь заработало :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 30 января, 2005 · Жалоба ipcad умеет брать статистику с ULOG а это уже кернел уровень.Причем отправлять ему можно не весь пакет а только заголовок. Ну и естественно фильтровать, а что именно ему посылать на учет. А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний? а что насчитает ng_netflow, при том что количество пакетов будет больше, чем машина способна обработать? всему свое место, и все должно быть в меру, неразумно ставить слабую машину с ipcad на 100 мегабитные линки с полной нагрузкой и кучей юзеров, так и на оборот а вообще ng_netflow хорошая вещь, сам его пока в тесте гоняю __________ ky Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ansy Опубликовано 31 января, 2005 · Жалоба До кучи -- отрекомендуйте, пожалуйста, старичка net-acct (юзается в сертифицированных биллингах) и новичка pmacct. Год с лишним юзаю первого и суммирую логи awk-скриптом. Точность устраивает, на 20 гигах внешнего трафа в месяц расхождение с Циской аплинка <0.5%. Плохо, что net-acct уже давно не развивается, и считает закрытые сессии, без возможности сбросить накопленное принудительно :( Т.е. реально втянуть ISO-образ CD одним потоком -- и все 700 метров появятся одной строкой в логе лишь в конце закачки. А то и перейдут на следующий месяц... Плюс -- логи достаточно полные для разбора полетов. Минус -- забиваются мусором при атаках. pmacct вроде как в усиленной разработке -- опасаюсь ставить, но надежды подает. Однако он только счетчик -- концов не найдешь в случае спора. Впрочем, Циска в этом плане не лучше, да? Вообще, IMHO, главное чтобы с аплинком в "минус" не расходилось, а с клиентом в "плюс" не слишком. Ни байта неучтенного врагу :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 31 января, 2005 · Жалоба ipcad умеет брать статистику с ULOG а это уже кернел уровень.Причем отправлять ему можно не весь пакет а только заголовок. Ну и естественно фильтровать, а что именно ему посылать на учет. А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний? а что насчитает ng_netflow, при том что количество пакетов будет больше, чем машина способна обработать? ng_netflow посчитает все что пройдет через машину. Если пакетик передан - он посчитан и информация о нем уйдет на коллектор. всему свое место, и все должно быть в меру, неразумно ставить слабую машину с ipcad на 100 мегабитные линки с полной нагрузкой и кучей юзеров, А вот кастрюлю с ng_netflow туда ставить можно. И пусть она будет стоять раком, до полной потери интерактивности, но весь трафик будет посчитан. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 31 января, 2005 · Жалоба А что насчитает ipcad когда ядро сожрет весь процессор на обработку прерываний? А какая считалка вообще в этом случае чегото вразумительное насчитает? ng_netflow, ng_ipacct Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
avial Опубликовано 31 января, 2005 · Жалоба У меня ipcad отказался собираться из сырцов (сильно разбираться не стал, может из-за gcc-2.95). Поставил fprobe-ulog, netflow с него падает в файлики и сразу в mysql экспортируется. В отличии от остальных коллекторов ULOG (перепробовал все, какие собрались, особенно ulogd не понравился), очень мало грузит проц. 60-70Мбит поток всего 0.3-0.6% отъедает. Если вирусная атака - 2-3%. Ulogd сам брал 30% и при прямом экспорте в mysql остальное брала база. С таким коллектором загрузить роутер трафиком проблематично. А если роутер грузится чем-то еще - никакие ng_netflow не помогут - терятся будут не пакеты, а потоки netflow. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 1 февраля, 2005 · Жалоба У меня 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 с цисок, такие роутеры довольно просто вписываются в существующую схему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...