LINUX.ORG.RU

SUB Billing - открытая биллинговая система


0

0

Стартовал проект открытой биллинговой системы SUB Billing, основанной на демоне ulog-acctd.

Краткий список функций:
- Подсчет входящего и исходящего трафика
- Отображение активных соединений
- Блокирование пользователя при отрицательном балансе
- Возможность установки статической/динамической скорости для каждого тарифа
- Детальная почасовая,дневная и месячная статистика

Cкачать: http://subbilling.fatal.ru/downloads/...

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от hse

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

anonymous
()
Ответ на: комментарий от dmesg

>> А что тогда ? afair большая половина систем учета трафика работает

>> либо c ulog, либо с libpcap.

>Только ловить netflow. По-другому никак. Иначе это несерьезно.

Интересует такая конфигурация, если ловить трафик с помощью fprobe (libpcap) и отдавать по netflow на коллектор, то при объёме в несколько терабат я получу точные данные, или мне всё-же нужно использовать ipcad + iptables QUEUE с последующей отдачей по netflow на коллектор?

Deisler
()
Ответ на: комментарий от Deisler

> использовать ipcad + iptables QUEUE с последующей отдачей по netflow
а нафига тебе newtflow если у тебя программа в QUEUE всё может собирать и так ? (заодно и рубить если чо )

mumpster ★★★★★
()
Ответ на: комментарий от anonymous

> IP QUEUE тогда траф при любых нагрузках посчитается байт в байт это точно. тем более что модно тут же и рубить если чо. я делал такую фигню - для игрового клуба - осталось не доделанной - в принципе там несложно - можно любой алгоритм легко привернуть. http://d7.ru/~byg/ams/index.htm основная проблема - быстрый поиск если IP много - тут надо думать в сторону либо hash либо B-trees.

mumpster ★★★★★
()
Ответ на: комментарий от anonymous

> 3k VPN-клиентов с нормальной скоростью PC-маршрутизатор, пожалуй, ниасилит.
ну не знаю - смотря какой трафик - у нас машина с tinc держала около 15 точек, половина из них - на 10-ке в прямом сегменте (свичёванный радиоэзер провайдера) - загрузка CPU <0.1 стабильно даже в ЧНН (это с учётом multicast), а корневой сервер - на 100-ке был. Причём поврех этого работал NCP еслди кому-то это что-то гооврит.;)

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

>ну не знаю - смотря какой трафик - у нас машина с tinc держала около 15 точек, половина из них - на 10-ке в прямом сегменте

Для оценки предельной пропускной способности систем учёта трафика целесообразно указывать кол-во анализируемых пакетов в секунду, а не объём трафика, и тем более, полосу пропускания канала.

Могу поделиться парой полезных ссылок по теме: PF_RING patch к ядру: http://www.ntop.org/PF_RING.html Обзор программных методов подсчёта трафика в Linux: http://www.free-it.de/archiv/talks_2005/paper-11076/paper-11076.html

oghma
()
Ответ на: комментарий от oghma

> целесообразно указывать кол-во анализируемых пакетов в секунду
я же сказал что у нас бегали multicast и NCP по этому. похоже - Вы не в теме.:)

mumpster ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.