[Vladimir]

доброе утро

 

как сейчас организуют подсчет трафика на линуксах ?

когда я это делал в последний раз, в 1999 г. .), это выглядело так - скрипт из базы генерил цепочки ipchains (по 4 записи на каждый ip адрес), раз в час эти цепочки дампил, обнулял и все по новой

есть ли какой-то более прогрессивный способ сейчас ?

например, аналог netflow

[Гость]

Во фрибсд точно есть. Сделано с помощью netgraph.

[TОВАРИЩ]

доброе утро

 

как сейчас организуют подсчет трафика на линуксах ?

когда я это делал в последний раз, в 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 (тоже похоже загнулся)

[Vladimir]

ipcad понравился, спасибо

следующий вопрос: как действует netflow ?

я видел только его логи

как я представляю, NAS будет непрерывно лить подсчитанные потоки на какой-то сервер ? или его нужно как-то забирать оттуда ? чем это делается ?

[Гость]

ipcad понравился, спасибо

следующий вопрос: как действует netflow ?

я видел только его логи

как я представляю, NAS будет непрерывно лить подсчитанные потоки на какой-то сервер ? или его нужно как-то забирать оттуда ? чем это делается ?

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

NetFlow еще и использовать для мониторига сети.

[Taras]

Коллектор (если нужен)

http://netacad.kiev.ua/flowc/index_ru.php

[Vladimir]

я тут уже копаюсь с flow-tools

вопрос следующий - как я вижу, при построении грамотной системы желательно разделить механизм подсчета трафика таким образом:

несколько NAS (только терминирование клиентов + netflow), отдельный радиус-сервер, отдельный биллинг-сервер, отдельный коллектор трафика

 

flow потоки с NAS идут на коллектор трафика (вопрос - в каком виде их там хранить - в виде кучи файлов и ротировать или сразу лить в базу, если в базу, то не помрет ли она от того, что в нее непрерывно будут валиться INSERT INTO TABLE)

 

Дальше, биллинговая машина забирает из коллектора нужные трафики и тарифицирует

так ?

 

а нельзя netflow сразу лить на биллинг, а netflow-клиент на биллинге будет отсекать ненужный трафик и лить в базу аггрегированный трафик

насколько нужен коллектор - лишний элемент в цепочке ? только для разбора конфликтных ситуаций ?

 

еще вопрос: аггрегирование трафика делается на NAS или уже на коллекторе ? грубо говоря, я хочу, чтобы скачка файла 1 гб была в виде одной записи а не в виде нескольких пакетов

[raz]

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.

 

Причесанные данные сливаются в оракл.

[LKr]

Для линукса ядерных решений нет. Варианты основаные на ipcains|iptables - не варианты.

 

Хм. Весьма категорично.

iptables QUEUE - считает с точностью до байта, ничего не теряя как ULOG...

На стендовом iP-200MMX с двумя realtek'ами дает до 75Мбит/с посчитанных и записанных в логи.

Эта же машина без считалки дает до 83 Мбит/с.

Считалось NetPIPE_3.5.

[Sultan]

1. фильтровать трафик для подсчета можно ng_bpf.

2. в sql-базу лучше пихать данные виде timestamp, ip, rcv,snt за определенный интервал времени(например 10 минут). Т.е. не нужно пихать в базу первичные данные. Оракл тут нафиг не нужен.

[raz]

Для линукса ядерных решений нет. Варианты основаные на ipcains|iptables - не варианты.

 

Хм. Весьма категорично.

iptables QUEUE - считает с точностью до байта, ничего не теряя как

 

Можно ли с помощью iptables QUEUE предоставить пациенту расшифровку потребления трафика за определенный период с точностью до сессии?

[LKr]

iptables QUEUE - умеет netflow ?

 

QUEUE дает любую инфу про пакет, см. название темы :)

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

[Vladimir]

от чего зависят потери при подсчете трафика ?

[Vladimir]

1. фильтровать трафик для подсчета можно ng_bpf.

2. в sql-базу лучше пихать данные виде timestamp, ip, rcv,snt за определенный интервал времени(например 10 минут). Т.е. не нужно пихать в базу первичные данные. Оракл тут нафиг не нужен.

 

в таком случае мы не отработаем претензию клинта "трафик не мой", так как у нас хранится не трафик, а число скачанных байт (непонятно откуда)

и вообще вариант 2 очень похож на подсчет средствами ipchains ;) с дампом цепочки каждые 10 минут .)

я хочу netflow

[LKr]

от чего зависят потери при подсчете трафика ?

 

от метода подсчета...

 

либо считаются пролетающие мимо пакеты (libpcap, ULOG) - тогда при больших скоростях пакеты могут пролетать быстрее, чем ты их обработаешь.

либо пакеты пропускаются "через себя" (iptables counters, QUEUE) - тогда пока на пакет ACCEPT не скажешь - дальше не полетит... итого скорости медленнее, нагрузка на проц больше, но потерь при подсчете нет.

 

все про linux, хотя ИМХО и к остальному тоже применить можно

[raz]

2Lkr: я уточнил маленько свой предыдущий пост. Поглядите. Возможно есть таки решение, которое избавит нас от замены linux -> freebsd на 150 роутерах :)

[Sultan]

1. фильтровать трафик для подсчета можно ng_bpf.

2. в sql-базу лучше пихать данные виде timestamp, ip, rcv,snt за определенный интервал времени(например 10 минут). Т.е. не нужно пихать в базу первичные данные. Оракл тут нафиг не нужен.

 

в таком случае мы не отработаем претензию клинта "трафик не мой", так как у нас хранится не трафик, а число скачанных байт (непонятно откуда)

и вообще вариант 2 очень похож на подсчет средствами ipchains ;) с дампом цепочки каждые 10 минут .)

я хочу netflow

Отработаете через flow-tools без доп. оверхэдов на sql.

[Vladimir]

я ipcad могу заставить считать "через себя" ?

и вообще, насколько большие потери, учитывая, что я допускаю потерю до 1% трафика (на 1 терабайт могу подарить клиентам 10 гигабайт, лишь бы за остальные заплатили 990*25=25K ;)

[LKr]

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 байт...

Для детализации - по уши :)

[raz]

беру свое высказываение "iptables - не вариант" обратно :)

[Vladimir]

iptables QUEUE - умеет netflow ?

 

QUEUE дает любую инфу про пакет, см. название темы :)

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

 

но вы как я понял, дампите трафик периодически, причем без указания места назначения пакетов, просто дата, ip, пришло лок, ушло лок, пришло инет. ушло инет

 

это то, что я делал

тогда и коллектор нафиг не нужен, берем iptables, считаем, аггрегируем, льем в базу и ждем, что клиент раскричится, а мы ему если что, этот трафик простим

 

получается, самое простое - вернуться к подсчету цепочками ?

меньше железок -меньше потерь трафика ?

[LKr]

но вы как я понял, дампите трафик периодически, причем без указания места назначения пакетов, просто дата, 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

[LKr]

тогда и коллектор нафиг не нужен, берем iptables, считаем, аггрегируем, льем в базу и ждем, что клиент раскричится, а мы ему если что, этот трафик простим

 

Кста, эксперименты с iptables показали, что при 6-7 тысячах правил и приличном трафике загрузка проца на 2 ГГц P4 уже непотребная...

[Гость]

непотребная...

 

это большая или маленькая?

[Vladimir]

параллельный вопрос:

играюсь 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

- разве так должно приходить, а не в виде одной записи ?

через минуту - снова эти адреса, видно, что поток один, а приходят куски от потока