В детальной статистике ничего подобного нет, да и быть не может, т.к. собираю при помощи IPCAD (с конвертированием в NetFlow 5) через IPQ путем заворачивания FORWARD пакетов в очередь (IP 0.0.0.0 является не маршрутизируемым).
Т.е. примерно вот такие правила в IPTABLES
iptables -A FORWARD -s <USER_IP> -j QUEUE
iptables -A FORWARD -i <EXTERNAL_INTERFACE> -j QUEUE
Глюки подтверждаю. В глобальном отчете с группировкой по ip почти у каждого клиента есть строка с ip = 0.0.0.0. А в отчете по диалапу встречаются строки с абсолютно левыми ip, которых нет нигде в базе, а ip выдается через радиус. Глюк на глюке
ipcad видимо не причем юзаю ndsad+netflow тоже самое выборочно у некоторых локальный класс трафика имеет две записи с ip 00.0.0 и с ip юзера, причем есть "ndsadные" юзеры а есть и "netflowные"
То же самое. В отчете с группировкой по IP есть записи с 0.0.0.0
Соответственно, в детальном отчете такие записи отсутствуют.
Использую собственную разработку, посылающую поток NFv5 в ядро в том же формате, что и get_xyz.
Если трафик был между IP-A и IP-B, причем и IP-A и IP-B являются привязаными к пользователям (услуге IP-трафик) IP-адресами (типично для локального трафика), то система сохраняет в таблице discount_transactions_iptraffic_all ipid=0
есть такое. ipcad-ы в режиме netflow5
проявляется в виде "локального" трафика в своей подсетке.
т.е. у большинства пользователей помимо своего ip-a присутствует трафик с\на 0.0.0.0 и тарифицируется как внутренний. причем малое количество. хотя внутренний трафик запрещен.
А трафик нормально считает?
У меня была такая проблема, но для всех ползоватьелей.
Я решил проблему так.
Тарификация -> Временные диапазоны, я изменил День начала на "Понеделник" а День Окончания на "Воскресение" и тогда появилас проблема.
День начала должен бит "Воскресение" а День Окончания "Суббота" тогда должен заработать[/quote][/url][/code]
