[Vladimir]

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

 

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

 

а если так ...

 

2000 клиентов обслуживаются на 15 маршрутизаторах

соответственно, на каждом - максимум 300 клиентов

на каждого из 300 клиентов на каждом маршрутизаторе стратегия такая:

 

изначально закрыто все всем кроме icmp, кроме внутреннего веб-сервера и пптп-порта на маршрутизаторе

клиент идет на пптп

авторизуется

если все ок:

1. включаем локалку

2. включаем правило подсчета на лок. сеть (одна цепочка - вход, другая - выход)

3. включаем шейпер на его ip адрес

 

периодически дампим его лок трафик

 

клиент отвалился по таймауту или прервал работу:

1. выключаем ему локалку

2. выключаем правила для подсчета лок трафика

3. выключаем шейпер

4. дампим его интернет-трафик (одной записью)

 

 

значит:

1. правил еще меньше, так как они создаются/закрываются динамически в зависимости от работающих одновременно клиентов, и нагрузка на терминатор еще меньше

 

НО - не слишком сложная схема ?

 

тогда нафиг нетфлоу - интернет-трафик считаем по сессиям, а локальный - дампами цепочек

[Sultan]

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

 

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

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

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

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

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

pps хотя бы при 64-байтных пакетах?

[Гость]

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

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

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

Только что закончил востановления системы подсчета тарфика.

умер винт на коллекторе онже и систмеа посчета с вебной мордой, в общем все поломалось

 

Мои соображения

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

Файлики лучьше сохранять так что потом их млжно было в билинговую систему засунуть.

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

 

А остальное по вкусу, радиусов тоже бы рекомедовал несколько, защита не только от падения радиуса он и время авторизации можно уменьшить, если первый радус очень занят то на следующий запрос уйдет

 

в принципе все можно задублировать вопрос только в цене

[Гость]

pps хотя бы при 64-байтных пакетах?

 

Стенд сейчас под другое задействован, попробовал на живом участке...

В общей сложности получилось 400 Kpps, из них 70 Кpps - ftp, остальное мои издевательства 64-байтными пакетами. Старый участок на rtl8139, никакого polling'а ессно.

[Kaiser]

Гость,

 

получилось 400 Kpps, из них 70 Кpps - ftp

 

ну не верю, и все тут. даже если на порядок уменьшить - все-равно не верю.

[LKr]

ну не верю, и все тут. даже если на порядок уменьшить - все-равно не верю.

 

И правильно... Ночью спать надо, а не сетку пакетами мучить... это не Kpps, а Kppm ;)

На 60 делить надо :)

Сорри...