IPN: кто как решает неправильный подсчет?
Компот получился. Давайте по порядку.
Любое количество Cisco будет терминировать клиентов PPPoE с авторизацией с RADIUS сервера, находящегося на одной машине с abills. Cisco будут настроены так, чтобы весь клиентский трафик пропускать через машину с абиллс для подсчета и шейпинга по направлениям и в зависимости от времени суток. На этой машине flowtools будет слушать интерфейс и генерить необходимую абиллсу netflow статистику.
Возможно такое и можно все это организовать под FreeBSD 7.0 не привлекая IPN?
Любое количество Cisco будет терминировать клиентов PPPoE с авторизацией с RADIUS сервера, находящегося на одной машине с abills. Cisco будут настроены так, чтобы весь клиентский трафик пропускать через машину с абиллс для подсчета и шейпинга по направлениям и в зависимости от времени суток. На этой машине flowtools будет слушать интерфейс и генерить необходимую абиллсу netflow статистику.
Возможно такое и можно все это организовать под FreeBSD 7.0 не привлекая IPN?
Так что тема фиксинга багов в IPN все еще актуальна. К сожалению у меня недостаточно времени чтобы этим заняться, но точно знаю, что у других попытки изменить ситуацию были и возможно скоро эти изменения увидим.Re: IPN: кто как решает неправильный подсчет?
Это не баги, это описано в манах. Тебе ж Асмодеус сказал - адреса усеров не должны меняться и будет тебе щастье. что тебе мешает назначать адреса через ппп но всегда одни и те же? а насчёт 5 минут... а кто тебе мешает раз в минуту дёргать? у меня лично так.chtito писал(а):Приятель, использующий abills сказал мне, что с IPN есть такая грабля:
Как видно выше, новому юзеру посчитается также и трафик с 12:00 по 12:02 прежнего юзера. Кроме того, получается, что настойчивые пользователи могут злопотреблять этим и сидеть на халяву: просто отключаться каждую 4-ю, 9-ю, 14-ю минуту и подключаться на следующую чтобы трафик им не был засчитан. Он сказал, что четкого решения этого досадного бага пока нет. Хотелось бы узнать что автор или другие люди могут порекомендовать чтобы этого не было? Спасибовот скажем traffic2sql у тебя выполняется каждые 5 минут
вот скажем в 12:00 он посчитал
в 12:02 юзер висевший с ип x.x.99.1 отключился
в 12:03 новый юзер подключившийся получил тот же ИП
в 12:05 ./traffic2sql засчитает весь траф этого ИП новому юзеру за последние 5 минут
Спасибо, но я же ответил: это отпадает по коммерческим соображениям: не все сидят круглые сутки и как минимум одна треть статичных адресов простаивала бы. Статичные адреса выдаются всем желающим за отдельную плату.Тебе ж Асмодеус сказал - адреса усеров не должны меняться и будет тебе щастье.
Неважно 5 минут, одна или 10, баг в разной степени себя проявляет.а насчёт 5 минут... а кто тебе мешает раз в минуту дёргать? у меня лично так.
а ты что всем публичные адреса выдаёшь?chtito писал(а):Спасибо, но я же ответил: это отпадает по коммерческим соображениям: не все сидят круглые сутки и как минимум одна треть статичных адресов простаивала бы. Статичные адреса выдаются всем желающим за отдельную плату.
ню-ню... а зачем? они так ВСЕМ нужны? а если нет - адресов 10/8 172.16/12 192.168/16 тебе мало??? 
и что значит "простаивала бы"? адресов-то в пуле всё равно должно быть не меньше, чем количество усеров... и какая разница "простаивают" они в пуле или привязаны статически?да не баг это гврю ж... привязка трафика идёт к ип! а как по-другому сделать???Неважно 5 минут, одна или 10, баг в разной степени себя проявляет.
Ну извиниа ты что всем публичные адреса выдаёшь?
ISP с rfc-ишными адресами яблоками забросают.
Просто мысль: при возвращении юзером адреса в общий пул отмечать айпишник как "грязный" и не выдавать никому до следующего запуска traffic2sql, который в конце работы снимет метку со всех грязных адресов. Наверняка можно лучше, но это просто мысли вслух.да не баг это гврю ж... привязка трафика идёт к ип! а как по-другому сделать???