On Tue, Oct 10, 2006 at 11:18:05AM +0300, Vladimir Litovka wrote:

2) Radius. Тот же интерфейс к SQL, но уже mandatory.

freeradius Есть одно "но" применительно к твоим запросам - не помню, есть ли в нем поддержка oracle. -- VP992-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Hi! On Tue, Oct 10, 2006 at 11:18:05AM +0300, Vladimir Litovka writes: VL> посоветуйте open source софт (список - ниже), который практически VL> зарекомендовал себя по следующим критериям: VL> VL> 1) надежность VL> 2) высокая производительность для работы в операторской среде с VL> большим количеством клиентов (до N Kusers) VL> 3) наличие вменяемой истории развития (то есть - исправление ошибок, VL> добавление новых фич во вменяемо скором времени от момента VL> возникновения необходимости, инсталлированная база пользователей, VL> которым можно задавать вопросы, etc) VL> 4) открытый доступ ко всем ресурсам (обновлениям, поддержке, etc), что VL> не исключает наличие опции платного саппорта. VL> VL> Софт нужен следующий (surprise! :) ): VL> VL> 1) Netflow Collector. Специфические пожелания - интерфейс к SQL VL> (отправка Netflow-записей непосредственно в SQL сервер), но это хоть и VL> большой плюс, но не принципиальный; VL> 2) Radius. Тот же интерфейс к SQL, но уже mandatory. VL> VL> Комментарии: VL> VL> - я не знаю, как выглядит API к SQL :) У оператора установлен Oracle - VL> что это значит в практическом смысле? Конечно, идеальная картина мира VL> - это если каждый вендор поставляет свои библиотеки, в который API VL> соответствует стандарту, а интерфейс к SQL-серверу - свой собственный, VL> но насколько реальная картина соответствует идеалу? Я считаю, что в данном случае наиболее разумная поддержка SQL - это через perl. То есть, в netflow collecter или в radius делается perl hook, из которого уже происходит запись куда угодно в каком угодно формате с использованием любых перловых модулей. И производительность от этого не снизится, потому что, во-первых, она важнее для обработки трафика, а не для записи результатов, а во-вторых, собственно интерпретации перлового кода получается минимум. А гибкость сразу повышается очень сильно. VL> - интересуют комментарии в таком формате - "пробовали (1), (2) и (3); VL> остановились на (3) потому что в (1) были такие-то проблемы, в (2) - VL> такие-то, а в (3) есть такие-то проблемы, но это наименьшее из всех VL> зол" :) Я использую flowd. cvs -d :pserver:cvs@happy.kiev.ua:/cvs co flowd Причина одна - зачем использовать чужое, если можно написать свое ненамного хуже? ;-) Соответственно, там есть то, что мне нужно (snmp, perl hooks и т.п.), в остальном - простой как угол дома (что, btw, положительно сказывается на эффективности и надежности). Недостатков гораздо больше, главный из которых - практически полное отсутствие документации. Другой существенный недостаток - поддерживаются только netflow версий 1 и 5. В общем, глянуть можешь, советовать использовать в production не рискну. :) -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Tue, Oct 10, 2006 at 12:13:13PM +0300, Vladimir Litovka wrote:

On 10/10/06, Pavel Gulchouck wrote:

...

Я считаю, что в данном случае наиболее разумная поддержка SQL - это через perl. [ ... ] производительность от этого не снизится, потому что, во-первых, она важнее для обработки трафика, а не для записи результатов,

а как оно будет работать, если объем netflow-трафика - до 10Mbps?

А тут главное, что бы база не тормозила :) Особенно, если надо туда писать каждый пакет. Но такую глупость я даже предположить не рискну. Надо бы делать обработку, скажем, за 5 минут траффика. Группировать, суммировать байты и уже после этого кидать в базу. Я в своё время так и поступал, но учитывая, что у меня был линуховый роутер, то быстрее всего там трафик снимался через libpcap. И netflow работал в качестве бэкапного источника информации о траффике. -- RAD-UANIC AR2657-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Tue, Oct 10, 2006 at 12:37:26PM +0300, Vladimir Litovka wrote:

On 10/10/06, Alexey Radetsky wrote:

...

...

а как оно будет работать, если объем netflow-трафика - до 10Mbps? А тут главное, что бы база не тормозила :) Особенно, если надо туда писать каждый пакет. Но такую глупость я даже предположить не рискну. Надо бы делать обработку, скажем, за 5 минут траффика. в условиях, если подключение пользователей не статическое

Конечно, если пользователь не статичен, тогда проще делать обработку онлайн, но при NKusers , могут возникнуть хорошие требования к железу, которое это будет считать :) Хотя, опять-таки, смотря к чему делать привязку. Если считаем диалаперов, тогда проще взять из радиуса его текущий адрес, в памяти держать счетчик in/out. Это очень просто. А если нужна будет детализация до байтов, отосланных на ХХХ по протоколу УУУ во время периода N-K, тогда можешь себе представить размеры базы? :) Я пока не могу :) -- RAD-UANIC AR2657-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On 10/10/06, Alexey Radetsky wrote:

Конечно, если пользователь не статичен, тогда проще делать обработку онлайн, но при NKusers , могут возникнуть хорошие требования к железу, которое это будет считать :)

ну железо нынче не проблема :)

А если нужна будет детализация до байтов, отосланных на ХХХ по протоколу УУУ во время периода N-K, тогда можешь себе представить размеры базы? :)

обычно данные хранятся в двух видах - 1) обработанная аггрегированная статистика в соответствии с user profile. Это то, что включается в счет, выводится на Web для пользователя, занимает немного места и храниться может вечно; 2) необработанная статистика - на случай, если клиент будет несогласен с выставленным счетом. Как правило, хранится от 3 до 6 месяцев raw netflow records. Не в SQL-базе, а в gzipped файлах и потому - тоже не представляет сложности. -- /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

According to Vladimir Litovka: Hi!

On 10/10/06, Alexey Radetsky wrote:

...

...

а как оно будет работать, если объем netflow-трафика - до 10Mbps?

А тут главное, что бы база не тормозила :) Особенно, если надо туда писать каждый пакет. Но такую глупость я даже предположить не рискну. Надо бы делать обработку, скажем, за 5 минут траффика.

в условиях, если подключение пользователей не статическое (подключился-отключился-подключился к другому NAS-etc), online обработка проще, чем offline. Просто потому, что в SQL-сервере в каждый конкретный момент находится актуальная конфигурация подключений пользователей, полученная из Радиуса. А если работать в offline, то нужно хранить и историю подключений пользователей, и историю трафика и я не уверен, что процесс сопоставления этих двух статистик будет тривиален.

Но понятное дело, что с какой-то степенью вероятности я ошибаюсь :)

В свое время пытаясь подружить такакс (который писал всю статитстику в текстовый файл) с sql базой пришел к тому, что нужно не трогать такакс, позволяя ему писать в текстовый файл, а ставить рядом обработчик этого файла, который просто тупо по нему идет и складирует все в базу. С базой уже может работать расчетка, или какие другие программы, которые ориентируются на статистику. Однако есть всегда некий файл, по которому можно проверить все остальное. С такаксом, который умел терять стартовые и стоповые пакеты это было достаточно актуально.

--

/doka

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

-- Taras Heychenko =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On 10/10/06, Dmitry Kiselev wrote:

Готовое решение вряд ли найдешь. Один нормальный програмист пишет такое на "c" за пару месяцев максимум. Со всеми шашечками и рюшечками конкретного случая.

а я и не ищу готовое решение :) я ищу два модуля в это решение - Radius и NFC, которые работают с третьим модулем - SQL. То есть получить флакон совместимых по интерфейсам блоков. А уж как обрабатывать информацию, которая передается через эти интерфейсы - это не моя проблема :) -- /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On 10/10/06, Dmitry Kiselev wrote:

не убивая наповал sql сервер бесполезной offline работой. Не, ну если уже есть супер-пупур-мега-сервер(кластер?) oracle которому ну совершенно нечего делать, то конечно :)

Вопрос состоит в том, кто будет обрабатывать информацию :) Есть два варианта - 1) offline-программой, еще перед передачей в SQL. Плюс - не требуется реалтаймовость, т.е. требования к процессору и диску сервера не самые жесткие. Минус - в общем случае у программы нет критериев, по которым трафик должен быть либо отброшен, либо соответствующим образом учтен. Если такие критерии есть - то достаточно нетривиальный алгоритм по сопоставлению "несвежей" информации с вполне вероятными ошибками в идентификации трафика. 2) в online-режиме - жесткие требования к аппаратной части - она должна быть достаточно мощной. Даже не знаю, насколько, если честно :) Зато обработка данных значительно более простая и, соответственно, более надежная. В принципе, я исхожу из того, что стоимость железа нынче вполне адекватна производительности и раскошелиться на пару Intel/AMD-based 8-процессорных систем с каким-нибудь storage - ну в рамках оператора, у которого _столько_ абонентов, это, наверное, уже некритичные деньги. Зато уменьшение количества ошибок биллинга при таком количестве абонентов - это заметная экономия на операционных и имиджевых потерях :) -- /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

According to Vladimir Litovka: Hi!

On 10/10/06, Dmitry Kiselev wrote:

...

не убивая наповал sql сервер бесполезной offline работой. Не, ну если уже есть супер-пупур-мега-сервер(кластер?) oracle которому ну совершенно нечего делать, то конечно :)

Вопрос состоит в том, кто будет обрабатывать информацию :) Есть два варианта -

1) offline-программой, еще перед передачей в SQL. Плюс - не требуется реалтаймовость, т.е. требования к процессору и диску сервера не самые жесткие. Минус - в общем случае у программы нет критериев, по которым трафик должен быть либо отброшен, либо соответствующим образом учтен. Если такие критерии есть - то достаточно нетривиальный алгоритм по сопоставлению "несвежей" информации с вполне вероятными ошибками в идентификации трафика.

2) в online-режиме - жесткие требования к аппаратной части - она должна быть достаточно мощной. Даже не знаю, насколько, если честно :) Зато обработка данных значительно более простая и, соответственно, более надежная. В принципе, я исхожу из того, что стоимость железа нынче вполне адекватна производительности и раскошелиться на пару Intel/AMD-based 8-процессорных систем с каким-нибудь storage - ну в рамках оператора, у которого _столько_ абонентов, это, наверное, уже некритичные деньги. Зато уменьшение количества ошибок биллинга при таком количестве абонентов - это заметная экономия на операционных и имиджевых потерях :)

Если у тебя по каким-либо причинам не успеет в on-line режиме отработать (это же не только собственно машина, а еще и сетевой интерфейс и то, что на нем принимает информацию), то информация будет безвозвратно утеряна.

--

/doka

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

-- Taras Heychenko =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On 10/10/06, Dmitry Pryanishnikov wrote:

Привет!

On Tue, 10 Oct 2006, Taras Heychenko wrote:

...

Если у тебя по каким-либо причинам не успеет в on-line режиме отработать (это же не только собственно машина, а еще и сетевой интерфейс и то, что на нем принимает информацию), то информация будет безвозвратно утеряна.

IMHO самый корректный подсчет количества (разнопланового) трафика - снятие показаний со счетчиков, ведущихся ядром (те же правила ipfw во FreeBSD давно имеют 64-разрядные счетчики - переполнения крайне редки) и, следовательно, могущие не посчитать только те пакеты, которые не прошли полностью через ip-стэк (e.g. bad checksum), а следовательно, и не доставлены клиенту. При этом детализация трафика (внешний/городской/локальный/буро/малиновый ;) соответствует конфигурации правил ipfw в реальном времени. Правда, "задним числом" уже ничего не посчитаешь - но это IMHO единственный недостаток. А так детализация по всем доступным для ipfw полям делается тривиально - знай сбрасывай дельты счетчиков с нужных правил с нужной дискретностью.

И как FreeBSD вяжется с начальными условиями задачи?

On Tue, Oct 10, 2006 at 03:59:57PM +0300, Taras Heychenko wrote:

...

2) в online-режиме - жесткие требования к аппаратной части - она должна быть достаточно мощной. Даже не знаю, насколько, если честно :) Зато обработка данных значительно более простая и, соответственно, более надежная. В принципе, я исхожу из того, что стоимость железа нынче вполне адекватна производительности и раскошелиться на пару Intel/AMD-based 8-процессорных систем с каким-нибудь storage - ну в рамках оператора, у которого _столько_ абонентов, это, наверное, уже некритичные деньги. Зато уменьшение количества ошибок биллинга при таком количестве абонентов - это заметная экономия на операционных и имиджевых потерях :)

Если у тебя по каким-либо причинам не успеет в on-line режиме отработать (это же не только собственно машина, а еще и сетевой интерфейс и то, что на нем принимает информацию), то информация будет безвозвратно утеряна.

Абсолютно верно. Именно по-этому все netflow потоки должны аггрегироваться где-то в одном не нагруженном месте. Там же архивироваться и очищаться от всяких DDoS, а в realtime молотилку доставляться уже по tcp. -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

10.10.06, Dmitry Kiselev написал(а):

аггрегироваться где-то в одном не нагруженном месте. Там же архивироваться и очищаться от всяких DDoS,

а данные по DDoS что, неинтересны? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On 10/10/06, Dmitry Pryanishnikov wrote:

IMHO самый корректный подсчет количества (разнопланового) трафика - снятие показаний со счетчиков, ведущихся ядром (те же правила ipfw во FreeBSD давно

а что такое FreeBSD? ;-) -- /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Wed, Oct 11, 2006 at 01:37:57AM +0300, Vladimir Litovka wrote:

...

IMHO самый корректный подсчет количества (разнопланового) трафика - снятие показаний со счетчиков, ведущихся ядром (те же правила ipfw во FreeBSD давно

а что такое FreeBSD? ;-)

Это такой train IOS'ов для x86, amd64, ARM, IA-64, PC-98 и UltraSPARC архитектур. Там даже есть bgpd и ldpd. Ждем вменяемый rsvpd с ospfd и isisd. А то как-то базовые приложения TE исполнять не очень удобно.

-- /doka

-- ZA-RIPE||ZA1-UANIC =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

----- Original Message ----- From: "Vasiliy P. Melnik" To: Cc: "Taras Heychenko" Sent: Wednesday, October 11, 2006 12:13 AM Subject: [uanog] Re: [uanog] Re: высокопроизводительное, абсолютно надежное, бесплатное программное обеспечение с открытым кодом, с идеальной поддержкой :)

On Tue, Oct 10, 2006 at 04:51:06PM +0300, Dmitry Kiselev wrote:

...

Абсолютно верно. Именно по-этому все netflow потоки должны аггрегироваться где-то в одном не нагруженном месте. Там же архивироваться и очищаться от всяких DDoS, а в realtime молотилку доставляться уже по tcp.

netflow должен експортироваться на другую машину, которая уже должен агрерировать и писать в базу. И доставляется оне не по tcp , а по udp.

во фре есть ng_netflow. Производительность должна быть достаточная. В любом случае надо пробовать. Ну и как не крути netgraph это все-таки kernel-level, что положительно должно сказываться на производительности.

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

Из коллекторов - имелся опыт общение c flowc нашей универовской разработки, 40 мегабит несильная машинка обрабатывала не поперхнувшись. Поток был с кошки.

40 Мбит реального трафика или это поток NF ? Если реального трафика - то это сейчас не _операторская_ емкость. Если это поток NF - то каков же реальный трафик ? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Привет! On Wed, 11 Oct 2006, Andrey Zarechansky wrote:

...

а что такое FreeBSD? ;-) Это такой train IOS'ов для x86, amd64, ARM, IA-64, PC-98 и UltraSPARC архитектур. Там даже есть bgpd и ldpd. Ждем вменяемый rsvpd с ospfd и isisd. А то как-то базовые приложения TE исполнять не очень удобно.

Mykola Dzham wrote:

Это такой IOS для i386 (ну и не только) железа, который, в отличие от цисок, может снимать netflow с одного интерфейса в обоих на правлениях

Alexandre Snarskii wrote:

То, из чего ваши конкуренты JunOS сделали :)

Спасибо, коллеги, день удался. Вмемориз, однозначно! Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message