Та я не спорю... Тока я уже столько всяких платформ и осей переюзал - мама не горюй. Начинал-то ещё програмить в начале 80-х прошлого векаА предпочтения меняются, если расширять рамки своих знаний.
Кстати это полезно ещё и с той точки зрения, что позволяет сравнивать разные платформы на собственном опыте.
А потом присел на линух и уже наверно не слезу... Старый стал мабуть 
На линух пересесть не получилось из-за своей разности в дистрибах, отсутствия единой документации как таковой (за исключением манов), хотя на сегодня это уже не важно - достаточно знать философию работы юникс. Напротив фрибсд покарила своей организованностью дистрибутива, полной документацией, логичностью работы и, какбы это точнее выразить? Изящностью чтоли... Вобщем для меня Freebsd это любимая ось для работы. Насчет УМНЫХ шейперов линукса - мне это не нужно. Пока в почете обычный безлимит. IPFW + NGNAT работают на ура. Мне почемуто ближе логика именно IPFW. Если нехватит производительности - поставлю еще пару насов pppoe на Sun Fire V100 или netra - благо стоят копейки. И отказоустойчивость на уровнет.е. для серверов в моём понимании. Они ведь и есть рабочие лошадки.sopov писал(а):Freebsd это любимая ось для работы
Насчёт бага - это не баг биллинга, если кто-то ещё до сих пор не понял.chtito писал(а):Если коротко: баг с возможностью подсчета чужого трафика как своего, который автор не стремится решать. Подробней можно узнать в специально посвященной этому багу теме.
Возможные пути решения я где-то приводил и к радиусу решение проблемы имеет разве что касательное отношение. Мы просто о разных вещах говорим.вот скажем traffic2sql у тебя выполняется каждые 5 минут
вот скажем в 12:00 он посчитал
в 12:02 юзер висевший с ип x.x.99.1 отключился
в 12:03 новый юзер подключившийся получил тот же ИП
в 12:05 ./traffic2sql засчитает весь траф этого ИП новому юзеру за последние 5 минут
Поддерживаю, к тому же таймауты выставляются и на цысках и в ng_netflow и т.п.ran писал(а):во-во... и если ipcad, ещё и параметры netflow timeout active и netflow timeout inactive выставить как положено...А задержка в поступлении данных от источника NETFLOW обусловлена именно таймаутами накопления данных в источнике, и ЭТО не имеет ничего общего с механизмом работы биллинга!
./traffic2sql будет считать только тот трафик, который УЖЕ передан источником netflow приёмнику (коллектору) и который коллектором уже был слит в файл (и здесь тоже есть задержка!)chtito писал(а):Специально для тех, кто поленился открыть тему, на которую я ссылался и почитать про недоработку:Возможные пути решения я где-то приводил и к радиусу решение проблемы имеет разве что касательное отношение. Мы просто о разных вещах говорим.вот скажем traffic2sql у тебя выполняется каждые 5 минут
вот скажем в 12:00 он посчитал
в 12:02 юзер висевший с ип x.x.99.1 отключился
в 12:03 новый юзер подключившийся получил тот же ИП
в 12:05 ./traffic2sql засчитает весь траф этого ИП новому юзеру за последние 5 минут
а для этого агрегацию в traffic2sql не кисло б делать. Я уже Асмодеусу грил об этом... В дефолтовом конфиге ипкада netflow timeout active 30 стоит. Это означает, что ипкад отдаст активный поток в нетфлоу только через 30! минут. А за полчаса на хорошей скорости...Но уменьшение таймаутов в итоге увеличивает объёмы данных в таблицах - это в определённом смысле недостаток.
поэтому у меня там 1 стоит. И capture и traffic2sql соответственно раз в минуту дёргаются... Ну а то что база пухнет... нехорошо канешна... но переживабельно...
меня вполне устраивает статика