видимо надеются, что им помогут довести их глючную поделку до ума....

а что дает этот коллектор?

http://www.netup.ru/phpbb/viewtopic.php?t=756 судя по отзывам весчь стоящая ... да даже если что-то и допишут - что в этом плохого ? Не в этом ли смысл открытых исходников ? В итоге-то доработки получат все.

Ну и правильно сделали, может их клиенты и сами смогут подправить то что надо. А может уже давно подправили, но выложить для всех - не могли. Вот хорошо-бы, что бы они весь свой билинг выложили ...

>да даже если что-то и допишут - что в этом плохого ? Не в этом ли смысл открытых исходников ? В итоге-то доработки получат все.

Сами не могут, ни продать за 1000 баксов, ни до ума довести, а как, если они кодера за 800у.е сватают, вот и "щедрый" жест - миру отдадим, под GPL. Может что и выйдет, а сами на тех.поддерки и установке деньгу срубим, или пиар устроим.

С 2001 года под масдай писали, а теперь линукс.

> С 2001 года под масдай писали, а теперь линукс.
бред сивой кобылы, по-другому не назовешь
для справки:
изначально UTM 3.0 разрабатывался под FreeBSD, потом компиллировался под Linux
Windows-версия появилась значительно позже, исключительно из-за ненулевого спроса на этот дистрибутив (новость о выходе Windows-версии UTM 3.0 http://old.netup.ru/?mode=news&mode2=view&id=21 )

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

По поводу NETUP -- более нелогичной системы не видел. Документация никакая, постоянно обнаруживаются расхождения с тем, что написано в документации и с тем, что оказывается на самом деле. А рекламу они себе делают хорошо. Молодцы. Защитнику этого биллинга - если вы работаете в компании, то ответьте, почему на тикеты (хваленая хотлайн) 2005042810000065 и 2005042810000074 так и не поступила нормального ответа? Это что, достойная компания разводит клиентов на бабки, -- все живут с саппорта, но не таким же сопособом, когда доументации просто верить нельзя, а если действовать по документации, то ничего не работает.

центральный городской коллектор

>...- если вы работаете в компании, то ответьте, почему на тикеты >(хваленая хотлайн) 2005042810000065 и 2005042810000074 так и не >поступила нормального ответа? Это что, достойная компания разводит > клиентов на бабки, -- все живут с саппорта, н....

Перед тем как писать ЭТО, предлагаю заглянуть в тот самый хотлайн. На ВСЕ Ваши заявки был дан ответ еще 3.05.2005. Продолжать диалог со специалистами службы технической поддержки, видимо Вы не посчитали нужным, таким образом, данные тикеты могут считаться закрытыми, а проблемы разрешенными. Так же хочу напомнить, вы можете вновь открыть уже ЗАКРЫТЫЙ тикет, если проблема, описанная в нем, не решилась или возникает вновь.

>> С 2001 года под масдай писали, а теперь линукс.
>бред сивой кобылы, по-другому не назовешь
>для справки:
>изначально UTM 3.0 разрабатывался под FreeBSD, потом компиллировался под >Linux

LOL. osobenno eto "изначально UTM 3.0"

u nih iznachalno byla 3.0? a chto zh oni tak 1.0 i 2.0 propustili???

Версия 1.0 была некоммерческой.
2.0 - не существовала под Windows вообще, вот и было сказано про 3-ю версию, так как, видимо, речь шла о ней, когда некто Anonymous решил высказаться насчет "мастдая"

такая штука пишеться за парудесятков минут используя libpcap. Кто не согласен - man pcap

>такая штука пишеться за парудесятков минут используя libpcap. Кто не согласен - man pcap

offtopic: может посоветуете хорошую прогу для сбора статистики по трафику на интерфейсах?
мне тут посоветовали ipcad

спасибо.

Re>"может посоветуете хорошую прогу для сбора статистики по трафику на интерфейсах?"

пользуюсь ipa(+mysql patch) - снимает со счётчиков ipfw/ipf

> такая штука пишеться за парудесятков минут используя libpcap. Кто не согласен - man pcap

:) Да уж. Прочитал это сообщение и сразу понял. Перед нами матёрый кодер. Вот только этот кодер видимо забыл прочитать man pcap... Ибо я там не нашел, что эта либа умеет, например, экспортировать трафик в NetFlow.

То что было дано, это не ответ, а очередной вопрос, учитывая, что вся нужная информация была дана, а ответа пришлось ждать, веренее нового вопроса с подачи 29 апреля аж до 3 мая, то хорош ваш хотлайн ;) нечего сказать. Пользуйтесь нетапом, если у вас возникнет вопрос -- то ответ в хотлайне через неделю получите. Ну или сразу -- если вызрвите их спеца, зп деньги конечно.

>экспортировать трафик в NetFlow

Чем не устраивает fprobe? (fprobe - libpcap-based tool that collect network traffic data and emit it as NetFlow flows towards the specified collector)

А ndsad уже опоздал. fprobe им не вытеснить.

nProbe + PF_RING патч для ядра

> offtopic: может посоветуете хорошую прогу для сбора статистики по трафику на интерфейсах? мне тут посоветовали ipcad

Если устраивает linux-only, то самый ненапряжный в плане влияния на производительность способ - ulogd.

Правда, оно аггрегировать само не умеет.

А зачем она нужна? Fprobe работает уже почти год на нат-ном сервере, прогрузка 80 МБит <br> [cody@nat-msk-02 cody]$ uptime 17:31:22 up 40 days, 1:55, 1 user, load average: 0.50, 0.44, 0.45

> мне тут посоветовали ipcad
хорошая штука но смотря для чего (btw, netup изначально на ней построен), хорошо подходит тем кто хочет перелезть с cisco на писюк на стат-ка собиралась через ip-accounting. есть проблемки из-за pcap.
если взять посвежее на лине можно зацепиться на IPQ/QUEUE, будет получше
netams - навороченная и сложная, без бутылки не разберёшься но мождет почти всё что в голову взбредёт
ipac-ng - неплоха (как никак родной для линя IPQ API) и в общем-то с минимальными задачами (как-то - обсчитать суммовой трафик конторы или мелкого подпольного провайдера) справляется неплохо но есть 1 гнусный косяк - развал данных в GDBM базе (при применении постгреса этого не наблюдал)
вообще - в принципе в лине 2.4+ можно повесить на QUEUE свой обработчик и сливать инфу про пакеты любой другой проге (хоть через UNIX socket хоть как) - так можно сделать не только суммовую стат-ку
ещё варианты:
SNMP
mrtg+небольшенькие скрипты (пишутся за 10 минут левой ногой - например можно тупо снимать стат-ку через ssh user@router "./mrtg.ifaceX")

А умеет ли вышеупомянутая софтина работать
1. с несколькими интерфейсами одновременно
2. с динамически появляющимися/исчезающими интерфейсами (при использовании VPN, например)

ndsad работает не только на Unix-системах (а работает он на совершенно различных архитектурах, например в марштуризаторах NSG на процессоре Motorola MPC860), но и на Windows.

Это всё может IPCAD - IP accounting daemon (http://ipcad.sourceforge.net/), как раз экспорт в NetFlow...

Хватит пиарить этот негатив !

Я с вас фигею

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

Долбанутый народ.

> Ибо я там не нашел, что эта либа умеет, например, экспортировать трафик в NetFlow.

NetFlow -- формат простой, вся документация на него доступна. Не нужно быть матёрым кодером чтобы сделать в него экспорт

Хочешь узнать, как ПРАВИЛЬНО делать netflow экспорт? Посмотри на модуль ng_netflow.ko в ядре FreeBSD. "Российский продукт", между прочим.

UTM хорош ЛИШЬ одним. Это САМЫЙ дешёвый биллинг, сертифицированный Госкомсвязью. Поддержка - никакая, форум всё время норовит перелезть на новые версии (в данный момент - 5), коии стоят дополнительных денег. Блокирование юзверей работает через то самое место, на котором вы сидите (написано одно в мануале, но оно хрен работает). Хвалёная поддержка (которая тут себя отстаивает под аналогичным мне ником) молчит, аки партизан (письмо послал им с вопросом ещё в конце апреля - в ответ х..й!). А больше всего меня порадовала в их форумах отмазка при вполне обоснованных наездах пользователей: "А хренли вы хотите всего лишь за 700 енотов? Покупайте CBOSS - это 10К! Вот и получите поддержку!". Радостные пингвины хлопают плавниками и хавают гнилую рыбу!

Вдогон самому себе. Про САМУЮ дешёвую сертифицированную систему я незря заговорил. При проверке конторы, предоставляющей платный выход в Инет (биллинг, да) - система обсчёта трафика должна быть сертифицирована этим самым Госкомсвязем. У нас проверяли чуть ли не вплоть до переданного-полученного байта, прежде чем выдать лицензию. Так что тут опенсорс не прокатит, коллеги. Вернее, прокатит, но до первого серьёзного судебного дела.

Нэтап рулит - не надо гнать. Кривые руки - ваши проблемы. Молкат в хотлайне - не поленись позвони и тебе ответят. ndsad работает систему не грузит и не вылетает. ЗЫ Кто-то упоминал ULOGD - действительно гибчайшая конфигурация (крути верти iptables-ами как хочешь), складирование в БД. НО - если использовать ее как коллектор траффика - база стремительно растёт и надо агрегировать. Кто писал скрипт для агрегации - поделитесь!

Вы форумом ошиблись, уважаемый. Про агрегацию. Пишите на свой любимый нетап. Возможно, вам там помогут. Или лучше по телефону позвоните. То есть сделайте ТО, что Вы советуете остальным. Попутно узнайте - сколько стоит ежемесячная поддержка.

интересно, а сколько стоит сертификация?
а то может сертифицировать какой-нибудь ГПЛ биллинг?

LOL, г-н анонимус еще не научился читать. Я писал "ЗЫ Кто-то упоминал ULOGD"... Т.е. ulogd - НИКАКИМ БОКОМ не впёрся в нетап.

Добавлю про софт для подсчёта трафика. Задача стояла так: по ip-шникам и портам, которые заранее не заданы (т.е. каждую софтину смотреть, по каким портам она лазит, лень, но для статистики нужно). Желательно с агрегированная и в БД. В итоге нашёл pmacct, который это всё и делает: простая и гибкая настройка, работает через libpcap, агрегирует и кладёт в mysql или pgsql.

>То орете что нет мол российских продуктов, что серость мы и никчемность. А когда что-то проклевывается начинаете обсирать и мешать с дерьмом. Долбанутый народ.

ты не шаришь. это удобрение

>А умеет ли вышеупомянутая софтина работать >1. с несколькими интерфейсами одновременно

Да >2. с динамически появляющимися/исчезающими интерфейсами (при использовании VPN, например)

Да, хотя считать трафик непосредственно на ВПН сервере - извращение из извращений.

>ndsad работает не только на Unix-системах (а работает он на совершенно различных архитектурах, например в марштуризаторах NSG на процессоре Motorola MPC860), но и на Windows

А зачем? Совершенно очевидно, что в жертву совместимости будет положена производительность.

По поводу сертифицированного биллинга. Биллинг должен быть сертифицированный, хотя не так давно на форуме минсвязи этот вопрос обсуждался и никто так и не смог объяснить "почему" :) Но это не главное, в любом случае, ни один оператор в здравом рассудке не станет показывать, что трафик у него считается на линуксе/фряхе. Трафик считает цицка, а дальше сертифицированный биллинг его собирает и в сертифицированную базу кладёт. А иначе, начинается подлинный кошмар, линукс должен стоять на сертифицированном железе и сама ось должна быть сертифицирована, если кто не верит - поищите в инете по словам: "ios", "сертификат минсвязи".

2 Tico

Сертифицированного железа сейчас валом (тот же inpro). Сама ось, имхо, сертифицирована не должна быть. Достаточно того, что соблюдены условия производителя биллинга. И после этого можно идти за разрешением.

> Кто писал скрипт для агрегации - поделитесь!

Готовые есть: ulogd, ulog-acctd, ulogipac. Я перепробовал практически
все возможные решения, и тоже считаю, что решения на основе ULOG
наиболее оптимальные. Для любителей pcap могу лишь заметить, что с
ним вы получаете проблему потери пакетов при высокой нагрузке. И она
в принципе не решаема. ULOG не теряет пакеты.

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

так что детки, идите ка нахуй со своими поделиями.

Про ulog и все связанные разработки не согласен.

Трафик ulog теряет при большой нагрузке на сети.

iptables -A INPUT -j ULOG iptables -A OUTPUT -j ULOG

Например на 100 мбитной сетке, при копировании файлов по SAMBe, ulogd и ulogd-mysql выдаёт ошибку:

ulogd.c:707 ipulog_read == -1! ipulog_errno == 6, errno = 105 ulogd.c:707 ipulog_read == -1! ipulog_errno == 6, errno = 105

если потом посчитать трафик sum(ip_totlen) - то результат плачевный - до 50% не попадает!

Пробовал менять настройки ядра, параметров --ulog... в iptables... ни помогает! (точнее помогает, но проблема не решается до конца)

Насчёт ulog-acct - те же яйца: tail /var/log/ulog-acctd/debug.log ... Jun 21 12:24:40 [STATISTICS] IPv4: 46523 (UDP: 0 TCP: 46521 ICMP: 2 other: 0) short: 0 Jun 21 12:24:40 [STATISTICS] min cprange: 24 drop: 0 nlmsg trunc: 0 recv err: 5 Jun 21 12:24:40 [STATISTICS] lookups: 46523, compares: 46521, c/l: 0.999957 Jun 21 12:24:40 [MISC] Total of 11 entries Jun 21 12:24:41 [MISC] Split into 4 [hold] and 7 [write] = 11 [total] entries Jun 21 12:24:41 [ERROR] recvfrom(): No buffer space available Jun 21 12:24:48 [ERROR] recvfrom(): No buffer space available Jun 21 12:24:53 [ERROR] recvfrom(): No buffer space available Jun 21 12:24:57 [ERROR] recvfrom(): No buffer space available Jun 21 12:24:58 [STATISTICS] IPv4: 37566 (UDP: 1 TCP: 37565 ICMP: 0 other: 0) short: 0 Jun 21 12:25:03 [STATISTICS] min cprange: 24 drop: 0 nlmsg trunc: 0 recv err: 4 Jun 21 12:25:03 [STATISTICS] lookups: 37566, compares: 37565, c/l: 0.999973 Jun 21 12:25:03 [MISC] Total of 5 entries Jun 21 12:25:04 [MISC] Split into 4 [hold] and 1 [write] = 5 [total] entries Jun 21 12:25:04 [ERROR] recvfrom(): No buffer space available Jun 21 12:25:09 [ERROR] recvfrom(): No buffer space available Jun 21 12:25:14 [ERROR] recvfrom(): No buffer space available Jun 21 12:25:16 [ERROR] recvfrom(): No buffer space available Jun 21 12:25:20 [ERROR] recvfrom(): No buffer space available --- Но ситуация здесь лучше. В худшем случае теряется 10% трафика. Причём на этой же машине ipcad считает всё без потерь.

Не первый день голову ломаю. Эксперимент специально провожу на "долхой" тачке - Пень 1 - 80 мегов памяти.

Выводы: или в userspace не успевает происходит обработка трафика, или нужно "под/над/конфигурить" ядро. или ulog вообще не подходит для подсчёта трафика, там где возможнен большой поток данных (даже не значительное время: - файл может отдаться не через инет, а через transparent-proxy (тут уже на полной скорости)).

PS: Ещё раз повторую, что вся эта "проблематика" имеет место на большом ethernet канале. У многих провайдеров магистральные каналы - 8 мбит, ulog здесь всё будет считать без пропусков. Я же к этой проблеме "в общем виде" подошёл.

Вот такие выводы...

А как быть если необходимо делать рассчеты стоимости траффика в зависимости от времени суток, htb приоритетов и направлений + возможность близкого к real time отключения клиентов? Экспорт в Netflow для такого видимо не подойдет. У меня в голове пока только мысли насчет ulogd + агрегирующий plugin, который корбой может отдавать ядру биллинга нужную статистику по запросу. Может есть что подобное?