непонятная пробема в подсчёте трафика между пользователями (зепляются по pppoe)
есть два пользователя с ip-адресами, скажем, 10.0.0.1 и 10.0.0.2
если первый со второго тянет файл, скажем, в 5м, то обоим насчитывается, что стянуто 5м.
сейчас версия 5.10.11, проблема так и не решена.
ранее подобная проблема была решена путём маркировки уходящего трафика первому пользователю (tos=0x2). и были подкорректированы калссы трафика: от 10.0.0.0/24 к 10.0.0.0/24, tos=0x2
теперь у каждого пользователя отображается этот трафик.
причём, у первого как трафик от 10.0.0.2 к 10.0.0.1, tos=0x2
а у второго от 10.0.0.1 к 10.0.0.2, tos=0x2
чего, по идее, не должно было быть., трафик должен был посчитаться лишь первому пользователю как входящий.
з.ы. сие наблюдается как с ndsad так и c ipcad
как решить данную проблему?
подсчёт трафика между пользователями
трафик считается как локальный, но вот опять же перестарались немнога.
ситуация следущая:
первый пользователь - 10.0.0.1
второй пользователь - 10.0.0.2
ежели был скачан файл с 10.0.0.1 на 10.0.0.2 размером, например, 5м.
то в детальных отчётах юзверей видим следущую картинку:
у второго пользователя появится что поток шёл с 10.0.0.1 на 10.0.0.2 (так и должно быть)
а вот у первого пользователя появится, что поток шёл с 10.0.0.2 на 10.0.0.1, причём, это тот же самый потоук.. ибо время, размер и количество пакетов совпадают полностью.
получается, что первому пользователю просто дублируют данный, с интерфейса второго пользователя (меняя местами src и dst)
вот с этим и нужно как-то бороться
ситуация следущая:
первый пользователь - 10.0.0.1
второй пользователь - 10.0.0.2
ежели был скачан файл с 10.0.0.1 на 10.0.0.2 размером, например, 5м.
то в детальных отчётах юзверей видим следущую картинку:
у второго пользователя появится что поток шёл с 10.0.0.1 на 10.0.0.2 (так и должно быть)
а вот у первого пользователя появится, что поток шёл с 10.0.0.2 на 10.0.0.1, причём, это тот же самый потоук.. ибо время, размер и количество пакетов совпадают полностью.
получается, что первому пользователю просто дублируют данный, с интерфейса второго пользователя (меняя местами src и dst)
вот с этим и нужно как-то бороться
Чтобы обойти данную ситуацию необходимо чтобы в коллектор (ipcad или другой) информация о каждом переданном пакете попадала только 1 раз. У вас же получается что пакет считается дважды, сначала на интерфейсе одного пользователя, потом на другом.
В ipcad можно решить данную проблему, используюя фичу input-only (подсчет только входящего трафика на интерфейсе, но она не работает практически на всех типах интерфейсов), либо используя опцию filter (в фильтре нужно указать направление трафика, например только исходящий в сторону абонента - interface tun0 filter "dst host 10.0.0.2").
В ipcad можно решить данную проблему, используюя фичу input-only (подсчет только входящего трафика на интерфейсе, но она не работает практически на всех типах интерфейсов), либо используя опцию filter (в фильтре нужно указать направление трафика, например только исходящий в сторону абонента - interface tun0 filter "dst host 10.0.0.2").
2gravis, на сервере проводится маркировка пакетов. выставляется tos=0x2
в итоге - на интерфейсе первого пользователя - немаркированный трафик, а на интерфейсе второго - маркированный.
вот маркированный трафик и появляется в статистике обоих пользователей.
немаркированный просто не учитывается (если учитывать, то он также появляется у обоих пользователей)
з.ы. идея с фильтром - интересно!
возникает глупый вопрос - что есть tun0? пользователи цепляются на pppoe-сервер, на интерфейся pppX.
з.ы.ы. задумался над фильтром для ipcad типа dst=10.10.10.0/16, и чтоп этот трафик был исходящим с данного интерфейса (учёт только того трафика, который передаётся в сторону пользователя). как такое реализовать? не укажете нужное направление?
в итоге - на интерфейсе первого пользователя - немаркированный трафик, а на интерфейсе второго - маркированный.
вот маркированный трафик и появляется в статистике обоих пользователей.
немаркированный просто не учитывается (если учитывать, то он также появляется у обоих пользователей)
з.ы. идея с фильтром - интересно!
возникает глупый вопрос - что есть tun0? пользователи цепляются на pppoe-сервер, на интерфейся pppX.
з.ы.ы. задумался над фильтром для ipcad типа dst=10.10.10.0/16, и чтоп этот трафик был исходящим с данного интерфейса (учёт только того трафика, который передаётся в сторону пользователя). как такое реализовать? не укажете нужное направление?
tun0 это туннельный интерфейс в BSD-системах, в линуксе он будет выглядеть как ppp0.возникает глупый вопрос - что есть tun0? пользователи цепляются на pppoe-сервер, на интерфейся pppX.
При динамическом распределении IP адресов и интерфейсов врят ли получится реализовать затею с ipcad filter'ом. Опция input-only (учитывать только входящие пакеты) на подобных интерфейсах не работает (проверялось на FreeBSD). Тут нужна четкая привязка имени интерфейса и адресов, которые используются на этом интерфейсе. Для статических интерфейсов можно прописать к примеру так:з.ы.ы. задумался над фильтром для ipcad типа dst=10.10.10.0/16, и чтоп этот трафик был исходящим с данного интерфейса (учёт только того трафика, который передаётся в сторону пользователя). как такое реализовать? не укажете нужное направление?
interface vlan1 filter "dst net 10.1.1.0/24"
interface vlan2 filter "dst net 10.1.2.0/25 or dst net 10.1.2.128/25"
При учете того, что на интерфейсе vlan1 используется сеть 10.1.1.0/24, а на vlan2 сети 10.1.2.0/25 и 10.1.2.128/25.
печально, конечно.... но, пусть не ip.... что-нить другое, наверное, можно придумать....gravis писал(а): При динамическом распределении IP адресов и интерфейсов врят ли получится реализовать затею с ipcad filter'ом.
на практике сам в этом убедилсяОпция input-only (учитывать только входящие пакеты) на подобных интерфейсах не работает (проверялось на FreeBSD).
статичиских нет. лишь динамически появляющиеся.Для статических интерфейсов можно прописать к примеру так:
так-то не в коллекторах ведь дело-то, вроди, а в самом биллинге...
в его новой хитрой логике работы (дублирует трафик обоим пользователям)
Из переписки в хотлайне:
> Необходимо чтобы трафик, переданный между абонентами, тарифицировался только
> для абонента-получателя, а не обоим как в настоящее время. Если абонент
> отправил к примеру 10Мб другому абоненту, ему эти же 10Мб тарифицируются как
> входящий к нему же. ФАКТИЧЕСКИ такого трафика нет. Почему же UTM выдает
> заведомо ложную информацию? Меня интересует как скоро и в каком порядке вы
> можете исправить данную проблему. Прошу дать как можно полный ответ.
>
В настоящий момент если трафик принадлежит двум абонентам в системе
одновременно, то данный трафик записывается двум абонентам.
Возможно в следующих версиях появится параметр ядра, который будет
определять на какого из абонентов будет записываться трафик.
...
Возможно в следующих версиях (скорее всего ближе к 13-й станет
понятно), появится отдельный параметр, с помощью которого можно будет
указывать каким образом записывать трафик на абонента.
С уважением, группа технической поддержки Компании НетАП.
> Необходимо чтобы трафик, переданный между абонентами, тарифицировался только
> для абонента-получателя, а не обоим как в настоящее время. Если абонент
> отправил к примеру 10Мб другому абоненту, ему эти же 10Мб тарифицируются как
> входящий к нему же. ФАКТИЧЕСКИ такого трафика нет. Почему же UTM выдает
> заведомо ложную информацию? Меня интересует как скоро и в каком порядке вы
> можете исправить данную проблему. Прошу дать как можно полный ответ.
>
В настоящий момент если трафик принадлежит двум абонентам в системе
одновременно, то данный трафик записывается двум абонентам.
Возможно в следующих версиях появится параметр ядра, который будет
определять на какого из абонентов будет записываться трафик.
...
Возможно в следующих версиях (скорее всего ближе к 13-й станет
понятно), появится отдельный параметр, с помощью которого можно будет
указывать каким образом записывать трафик на абонента.
С уважением, группа технической поддержки Компании НетАП.
2gravis, пасип.
как я понимаю, оно так и будет продолжать ошибочно начислять трафик пользователям? -((
или, всё-таки, что-то можно будет выжать из
как я понимаю, оно так и будет продолжать ошибочно начислять трафик пользователям? -((
или, всё-таки, что-то можно будет выжать из
12. Расширены возможности здания классов трафика. В частности добавлено условие позволяющее исключить определенный трафик из данного класса трафика. Более подробно этот функционал опцисан в обновленной документации.
Боюсь что нет. Межабонентский трафик разносится обоим абонентом уже после того, как он был классифицирован в соответствии с настройками класса трафика.
Изменения, описанные в п.12, в первую очередь позволяют убрать лишний геморрой, к примеру при описании класса трафика, где в определенной большой подсети (допустим класса C) нужно получить 1 адрес, трафик с которого не должен попадать под данный класс. Раньше этого можно было достичь только разбив подсеть на несколько подсетей поменьше и исключить необходимый адрес. В итоге вместо двух записей (одной на всю подсеть и второй исключающей нужный IP) имеем в несколько раз больше, что в свою очередь вызывает неудобство в настройке класса трафика и потребляет лишние ресурсы системы при классификации трафика ядром. Теперь этого можно избежать используя исключения. Полезно и удобно, но к нашей с вами проблеме отношения не имеет.
Чтобы решить этот трабл, необходимы изменения в ядре UTM. Кое какие соображения по этому поводу я высказал тут:
viewtopic.php?t=836
Изменения, описанные в п.12, в первую очередь позволяют убрать лишний геморрой, к примеру при описании класса трафика, где в определенной большой подсети (допустим класса C) нужно получить 1 адрес, трафик с которого не должен попадать под данный класс. Раньше этого можно было достичь только разбив подсеть на несколько подсетей поменьше и исключить необходимый адрес. В итоге вместо двух записей (одной на всю подсеть и второй исключающей нужный IP) имеем в несколько раз больше, что в свою очередь вызывает неудобство в настройке класса трафика и потребляет лишние ресурсы системы при классификации трафика ядром. Теперь этого можно избежать используя исключения. Полезно и удобно, но к нашей с вами проблеме отношения не имеет.
Чтобы решить этот трабл, необходимы изменения в ядре UTM. Кое какие соображения по этому поводу я высказал тут:
viewtopic.php?t=836