Vladimir Опубликовано 6 октября, 2004 · Жалоба доброе утро как сейчас организуют подсчет трафика на линуксах ? когда я это делал в последний раз, в 1999 г. .), это выглядело так - скрипт из базы генерил цепочки ipchains (по 4 записи на каждый ip адрес), раз в час эти цепочки дампил, обнулял и все по новой есть ли какой-то более прогрессивный способ сейчас ? например, аналог netflow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 6 октября, 2004 · Жалоба Во фрибсд точно есть. Сделано с помощью netgraph. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TОВАРИЩ Опубликовано 6 октября, 2004 · Жалоба доброе утро как сейчас организуют подсчет трафика на линуксах ? когда я это делал в последний раз, в 1999 г. .), это выглядело так - скрипт из базы генерил цепочки ipchains (по 4 записи на каждый ip адрес), раз в час эти цепочки дампил, обнулял и все по новой есть ли какой-то более прогрессивный способ сейчас ? например, аналог netflow ipcad - http://sourceforge.net/projects/ipcad/ (еще живет и весьма удобен) netacct-mysql - http://sourceforge.net/projects/netacct-mysql/ (похоже загнулся) ulogd - http://gnumonks.org/projects/project_details?p_id=1 (тоже похоже загнулся) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vladimir Опубликовано 7 октября, 2004 · Жалоба ipcad понравился, спасибо следующий вопрос: как действует netflow ? я видел только его логи как я представляю, NAS будет непрерывно лить подсчитанные потоки на какой-то сервер ? или его нужно как-то забирать оттуда ? чем это делается ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 7 октября, 2004 · Жалоба ipcad понравился, спасибоследующий вопрос: как действует netflow ? я видел только его логи как я представляю, NAS будет непрерывно лить подсчитанные потоки на какой-то сервер ? или его нужно как-то забирать оттуда ? чем это делается ? netflow шлет статистику о тарфике (с агрегацией) с маршрутизатора, принимает ее коллектор (коллектор может быть встроенным сразу в билинг), в зависимости от коллектора он может много чего делать и агрегацию и через парсеры пропустить и подсчитать что либо, потом это либо в билинг передается, или просто смотрится. NetFlow еще и использовать для мониторига сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Taras Опубликовано 7 октября, 2004 · Жалоба Коллектор (если нужен) http://netacad.kiev.ua/flowc/index_ru.php Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vladimir Опубликовано 7 октября, 2004 · Жалоба я тут уже копаюсь с flow-tools вопрос следующий - как я вижу, при построении грамотной системы желательно разделить механизм подсчета трафика таким образом: несколько NAS (только терминирование клиентов + netflow), отдельный радиус-сервер, отдельный биллинг-сервер, отдельный коллектор трафика flow потоки с NAS идут на коллектор трафика (вопрос - в каком виде их там хранить - в виде кучи файлов и ротировать или сразу лить в базу, если в базу, то не помрет ли она от того, что в нее непрерывно будут валиться INSERT INTO TABLE) Дальше, биллинговая машина забирает из коллектора нужные трафики и тарифицирует так ? а нельзя netflow сразу лить на биллинг, а netflow-клиент на биллинге будет отсекать ненужный трафик и лить в базу аггрегированный трафик насколько нужен коллектор - лишний элемент в цепочке ? только для разбора конфликтных ситуаций ? еще вопрос: аггрегирование трафика делается на NAS или уже на коллекторе ? грубо говоря, я хочу, чтобы скачка файла 1 гб была в виде одной записи а не в виде нескольких пакетов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raz Опубликовано 7 октября, 2004 · Жалоба 1. генератор netflow ng_netflow без вариантов. Все остальное работающее в user level теряет трафик при 100 загрузке процессора. ng_netflow работает в kernel level и регистрирует весь трафик. Меряли, сравнивали с циской. На 700Мб расхождение ~4000 байт. Герератор, подсчитываемый трафик не агрегирует. Если нужна фильтрация на этапе подсчета - ipacctd. Оно такое умеет. Оба варианта under freebsd only Для линукса ядерных решений нет. Варианты основаные на ipcains|iptables - не варианты. 2. коллектор Ну, тут что больше понравится. Мы юзаем flow-tools с похаченым flow-cat'ом. Внесенная модификация позволяет исключить конвертацию bin->plaintext. Трафик в соответствии с тарифами считается модифицированным flow-cat. Причесанные данные сливаются в оракл. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LKr Опубликовано 7 октября, 2004 · Жалоба Для линукса ядерных решений нет. Варианты основаные на ipcains|iptables - не варианты. Хм. Весьма категорично. iptables QUEUE - считает с точностью до байта, ничего не теряя как ULOG... На стендовом iP-200MMX с двумя realtek'ами дает до 75Мбит/с посчитанных и записанных в логи. Эта же машина без считалки дает до 83 Мбит/с. Считалось NetPIPE_3.5. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sultan Опубликовано 7 октября, 2004 · Жалоба 1. фильтровать трафик для подсчета можно ng_bpf. 2. в sql-базу лучше пихать данные виде timestamp, ip, rcv,snt за определенный интервал времени(например 10 минут). Т.е. не нужно пихать в базу первичные данные. Оракл тут нафиг не нужен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raz Опубликовано 7 октября, 2004 · Жалоба Для линукса ядерных решений нет. Варианты основаные на ipcains|iptables - не варианты. Хм. Весьма категорично. iptables QUEUE - считает с точностью до байта, ничего не теряя как Можно ли с помощью iptables QUEUE предоставить пациенту расшифровку потребления трафика за определенный период с точностью до сессии? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LKr Опубликовано 7 октября, 2004 · Жалоба iptables QUEUE - умеет netflow ? QUEUE дает любую инфу про пакет, см. название темы :) насчет netflow... не в курсе, есть ли приблуды для генерации netflow на основании данных QUEUE, но надо ли это... а если надо - мы например своё написали, в нужном нам формате выдает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vladimir Опубликовано 7 октября, 2004 · Жалоба от чего зависят потери при подсчете трафика ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vladimir Опубликовано 7 октября, 2004 · Жалоба 1. фильтровать трафик для подсчета можно ng_bpf.2. в sql-базу лучше пихать данные виде timestamp, ip, rcv,snt за определенный интервал времени(например 10 минут). Т.е. не нужно пихать в базу первичные данные. Оракл тут нафиг не нужен. в таком случае мы не отработаем претензию клинта "трафик не мой", так как у нас хранится не трафик, а число скачанных байт (непонятно откуда) и вообще вариант 2 очень похож на подсчет средствами ipchains ;) с дампом цепочки каждые 10 минут .) я хочу netflow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LKr Опубликовано 7 октября, 2004 · Жалоба от чего зависят потери при подсчете трафика ? от метода подсчета... либо считаются пролетающие мимо пакеты (libpcap, ULOG) - тогда при больших скоростях пакеты могут пролетать быстрее, чем ты их обработаешь. либо пакеты пропускаются "через себя" (iptables counters, QUEUE) - тогда пока на пакет ACCEPT не скажешь - дальше не полетит... итого скорости медленнее, нагрузка на проц больше, но потерь при подсчете нет. все про linux, хотя ИМХО и к остальному тоже применить можно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raz Опубликовано 7 октября, 2004 · Жалоба 2Lkr: я уточнил маленько свой предыдущий пост. Поглядите. Возможно есть таки решение, которое избавит нас от замены linux -> freebsd на 150 роутерах :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sultan Опубликовано 7 октября, 2004 · Жалоба 1. фильтровать трафик для подсчета можно ng_bpf.2. в sql-базу лучше пихать данные виде timestamp, ip, rcv,snt за определенный интервал времени(например 10 минут). Т.е. не нужно пихать в базу первичные данные. Оракл тут нафиг не нужен. в таком случае мы не отработаем претензию клинта "трафик не мой", так как у нас хранится не трафик, а число скачанных байт (непонятно откуда) и вообще вариант 2 очень похож на подсчет средствами ipchains ;) с дампом цепочки каждые 10 минут .) я хочу netflow Отработаете через flow-tools без доп. оверхэдов на sql. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vladimir Опубликовано 7 октября, 2004 · Жалоба я ipcad могу заставить считать "через себя" ? и вообще, насколько большие потери, учитывая, что я допускаю потерю до 1% трафика (на 1 терабайт могу подарить клиентам 10 гигабайт, лишь бы за остальные заплатили 990*25=25K ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LKr Опубликовано 7 октября, 2004 · Жалоба 2Lkr: я уточнил маленько свой предыдущий пост. Поглядите. Возможно есть таки решение, которое избавит нас от замены linux -> freebsd на 150 роутерах :) У нас считалка выдает логи вида (наследие nacctd): from_if to_if from_ip to_ip size type f_port t_port packets eth0 eth4 10.х.х.х 10.y.y.y 13865 17 27016 27005 103 С группировкой за минуту по всем параметрам кроме размера... Т.е. в данной строчке - 103 UDP пакета за минуту с 10.x.x.x:27016 на 10.y.y.y:27005 общим размером 13865 байт... Для детализации - по уши :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raz Опубликовано 7 октября, 2004 · Жалоба беру свое высказываение "iptables - не вариант" обратно :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vladimir Опубликовано 7 октября, 2004 · Жалоба iptables QUEUE - умеет netflow ? QUEUE дает любую инфу про пакет, см. название темы :) насчет netflow... не в курсе, есть ли приблуды для генерации netflow на основании данных QUEUE, но надо ли это... а если надо - мы например своё написали, в нужном нам формате выдает. но вы как я понял, дампите трафик периодически, причем без указания места назначения пакетов, просто дата, ip, пришло лок, ушло лок, пришло инет. ушло инет это то, что я делал тогда и коллектор нафиг не нужен, берем iptables, считаем, аггрегируем, льем в базу и ждем, что клиент раскричится, а мы ему если что, этот трафик простим получается, самое простое - вернуться к подсчету цепочками ? меньше железок -меньше потерь трафика ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LKr Опубликовано 7 октября, 2004 · Жалоба но вы как я понял, дампите трафик периодически, причем без указания места назначения пакетов, просто дата, ip, пришло лок, ушло лок, пришло инет. ушло инет Есть там ip назначения, см. чуть выше: http://forum.nag.ru/viewtopic.php?p=65159#65159 ;) Разделение лок/инет делается уже приблудой, что в базу заносит, не дело это считалки... А вот дело считалки еще и дропнуть пакеты клиентов, у которых денежка кончилась :) Ведь рез-том QUEUE может быть как ACCEPT, так и DROP ;) Chain FORWARD (policy DROP) target prot opt source destination QUEUE all -- anywhere anywhere Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LKr Опубликовано 7 октября, 2004 · Жалоба тогда и коллектор нафиг не нужен, берем iptables, считаем, аггрегируем, льем в базу и ждем, что клиент раскричится, а мы ему если что, этот трафик простим Кста, эксперименты с iptables показали, что при 6-7 тысячах правил и приличном трафике загрузка проца на 2 ГГц P4 уже непотребная... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Опубликовано 7 октября, 2004 · Жалоба непотребная... это большая или маленькая? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vladimir Опубликовано 7 октября, 2004 · Жалоба параллельный вопрос: играюсь netflow-tools и ipcad такое чувство, что на машине с ipcad трафик собирается в цепочки (видны группы цепочек с большим трафиком), но они там и остаются, а на коллектор приходят какие-то маленькие цепочки (до 1000 байт, по 3-5 пакетов), причем они дублируются, хотя по идее, должны были прийти одной цепочкой: 10.128.1.128 10.1.81.75 6 6667 1076 167 1 10.128.1.128 10.1.81.75 6 6667 1076 167 1 - разве так должно приходить, а не в виде одной записи ? через минуту - снова эти адреса, видно, что поток один, а приходят куски от потока Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...