подсчет трафика на линукс

Vladimir · October 6, 2004

доброе утро

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

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

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

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

October 6, 2004

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

TОВАРИЩ · October 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 (тоже похоже загнулся)

Vladimir · October 7, 2004

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

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

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

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

October 7, 2004

ipcad понравился, спасибо
следующий вопрос: как действует netflow ?

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

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

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

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

Taras · October 7, 2004

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

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

Vladimir · October 7, 2004

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

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

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

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

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

так ?

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

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

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

raz · October 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.

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

LKr · October 7, 2004

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

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

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

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

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

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

Sultan · October 7, 2004

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

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

raz · October 7, 2004

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

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

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

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

LKr · October 7, 2004

iptables QUEUE - умеет netflow ?

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

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

Vladimir · October 7, 2004

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

Vladimir · October 7, 2004

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

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

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

я хочу netflow

LKr · October 7, 2004

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

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

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

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

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

raz · October 7, 2004

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

Sultan · October 7, 2004

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

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

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

я хочу netflow

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

Vladimir · October 7, 2004

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

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

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

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

raz · October 7, 2004

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

Vladimir · October 7, 2004

iptables QUEUE - умеет netflow ?

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

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

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

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

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

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

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

LKr · October 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

LKr · October 7, 2004

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

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

October 7, 2004

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

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

Vladimir · October 7, 2004

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

играюсь netflow-tools и ipcad

такое чувство, что на машине с ipcad трафик собирается в цепочки (видны группы цепочек с большим трафиком), но они там и остаются, а на коллектор приходят какие-то маленькие цепочки (до 1000 байт, по 3-5 пакетов), причем они дублируются, хотя по идее, должны были прийти одной цепочкой:

10.128.1.128 10.1.81.75 6 6667 1076 167 1

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

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

Sign In

подсчет трафика на линукс

Recommended Posts

Vladimir

Guest

TОВАРИЩ

Vladimir

Guest

Taras

Vladimir

raz

LKr

Sultan

raz

LKr

Vladimir

Vladimir

LKr

raz

Sultan

Vladimir

LKr

raz

Vladimir

LKr

LKr

Guest

Vladimir

Join the conversation