[JMan]

При очередной необходимости ставить новый шлюз доступа для пользователей решил проанализировать, что же так грузит систему, оказалось, что основное время цпу выгрызает ipcad. Решил перенести генератор netflow в ядро, обратил внимание на ipt_netflow-1.6 все в нем хорошо. Но вот у меня биллинг еще использовал команды ipcad для поминутного подсчета трафика, а netflow хранились просто как лог куда ходил пользователь и за что считалось, для "разбора полета если что". Можно реализовать такой же функционал на стороне приема netflow, агрегировать по айпишкам и суммировать пакетов байт, но задержка данных особенно для активных netflow будет давать не совсем поминутный подсчет. Можно конечно уменьшить лимит времени для активных netflow до минуты, но тогда больше будет писаться подробной статистики на пользователя.

Решил добавить подобный функционал ipcad в сам модуль.

Задачу сделал так:

1. Добавил в модуль дополнительный define IPCAD_SUPPORT который включает дополнительный функционал при компиляции, что-бы можно было исключить при сборке такой функционал.

2. Добавил параметры к модулю

ipcad_support - вкл/выкл обработку пакетов части кода что агрегирует трафик как ipcad

ipcad_maxflows - максимальное количество записей в хеше агрегации трафика абы была возможность предотвратить дос атаки.

ipcad_hashsize -размер хеш таблицы агрегации

3. Эти же переменные доступны в /proc/sys/net/netflow. можно менять посреди работы модуля.

4. В /proc/sys/net/netflow. добавлена ipcad_checkpoint_control переменная через которую можно управлять checkpoint записями.

Если вписать в переменную 1 - то модуль запомнить текущие накопленные значения в checkpoint таблице, а текущую таблицу очистит.

Если вписать в переменную 2 - то модуль очистит таблицу checkpoint.

Если вписать в переменную 0 или прочие значения то ничего не произойдет

5. В /proc/net/stat/ добавлен файл ipt_ipcad_flow_checkpoint где и можно получить текущую таблицу checkpoint. Также через этот файл и ioctl функцию можно выполнять манипуляции с checkpoint таблицей.

поддерживаются сейчас вызовы ioctl

NF_IPCAD_SAVE_CHECK_POINT - запомнить текущие накопленные значения в checkpoint таблице, а текущую таблицу очистить

NF_IPCAD_CLEAR_CHECK_POINT - очистить таблицу checkpoint

NF_IPCAD_GET_SIZE_CHECK_POINT - получить количество записей в checkpoint таблице

также в планах добавить NF_IPCAD_GET_RECORDS_CHECK_POINT который даст возможность за один запрос получить в бинарном виде таблицу checkpoint, что бы не парсить ipt_ipcad_flow_checkpoint,

а также можно реализовать прочие функции управления.

 

Теперь можно либо реализовать демон который будет имитировать работу ipcad команд clear ip accounting show ip accounting checkpoint clear ip accounting checkpoint или адаптировать биллинг к прямой работе с модулем.

 

Жду результатов тестирования, комментариев, вопросов, предложений.

ipt_netflow_1.6.ipcad_support.patched.zip

ipcad_support.zip

[JMan]

Уже работает более суток на 2 боевых шлюзах, найдено несколько легких оплошностей при загрузке модуля при обработке, начальных параметров что передаются ему (не критичны вовсе). Уже исправлено эти баги, еще посмотрим что да как. Ели ничего не будет то выложу окончательный вариант. Из наблюдений загрузка ядер сильно упала сейчас по сравнению с вчера вечером когда работал еще ipcad (не забывайте задать нужные размеры хеш таблиц фловов и ipcad записей, держите размер в 2 раза больше ожидаемого количества). Билинг адаптировал напрямую рулить модулем через /proc все считает чесно :).

[nuclearcat]

Может стоит на sourceforge выложить? Или еще куда-нить

Дельная штука.

[JMan]

Может стоит на sourceforge выложить? Или еще куда-нить

Дельная штука.

Я с автором ipt_netflow-1.6 на sourceforge списывался ибо нашел пару ляпов в самом ipt_netflow-1.6, уже там он исправил теперь реально это ipt_netflow-1.6.3 какой то получается. Он посоветовал сюда выложить абы народ протестировал. А так я думаю будет вполне резонно включить в драйвер ipt_netflow, ибо все равно можно функционал если что отключать тем кому он не нужен при компиляции даже.

[usachaa]

Реальная штука. Протестировано на потоке больше 2Gb/s. Посчитанный ipt_NETFLOW трафик практически равен трафику связки ipcad+libpcap+PF_RING что радует, разница всего 0.05% причем в большую сторону. В данный момент работают обе схемы для сравнения за длительный период. Предлагаю еще в ipacct формат добавить два поля sif dif , что позволит оперативно считать и здесь направления трафика не по сетям (при подлючении к точкам обмена трафиком, их количество достигает многих тысяч и постоянно динамически меняется) а по интерфейсам что правильнее и удобнее.

[[anp/hsw]]

Жду результатов тестирования, комментариев, вопросов, предложений.

а под ядро 2.4 можете модуль портировать? я бы тоже потестировал :)

кстати, заметил, что жрет CPU не столько ipcad, сколько функции libpcap.

при замене ipcad, например, на fprobe - ситуация повторяется.

некоторое время вполне нормальная загрузка 10-15% CPU. но стоит прилететь какому-нибудь кривому пакету - и что ipcad, что fprobe - уже жрут 99% :)

 

[JMan]

Реальная штука. Протестировано на потоке больше 2Gb/s. Посчитанный ipt_NETFLOW трафик практически равен трафику связки ipcad+libpcap+PF_RING что радует, разница всего 0.05% причем в большую сторону. В данный момент работают обе схемы для сравнения за длительный период. Предлагаю еще в ipacct формат добавить два поля sif dif , что позволит оперативно считать и здесь направления трафика не по сетям (при подлючении к точкам обмена трафиком, их количество достигает многих тысяч и постоянно динамически меняется) а по интерфейсам что правильнее и удобнее.

Да данные то есть откуда куда идет пакет :). Эти поля куда добавить? Я так понимаю в ipt_ipcad_flow_checkpoint абы еще поля просто были типа откуда пришел пакет и куда ушел? А также вопрос: а если пакет сначала шел в одну сетевую, а потом в другую сетевуху побежал то 2 записи создавать? Опишите более подробно необходимый алгоритм абы понимать какое поведение необходимо реализовать.

 

Жду результатов тестирования, комментариев, вопросов, предложений.

а под ядро 2.4 можете модуль портировать? я бы тоже потестировал :)

кстати, заметил, что жрет CPU не столько ipcad, сколько функции libpcap.

при замене ipcad, например, на fprobe - ситуация повторяется.

некоторое время вполне нормальная загрузка 10-15% CPU. но стоит прилететь какому-нибудь кривому пакету - и что ipcad, что fprobe - уже жрут 99% :)

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

Очень давно не работал с 2.4 ядрами да и под руками для тестирования даже нема сервера :(. Кстати а оригинальный ipt_netflow компилируется под 2.4 если нет то тогда я уже точно не помогу ибо я дотачивал к нему необходимый функционал.

И вопрос а чего вы юзаете 2.4, или аппаратные какие то ограничения?

[[anp/hsw]]

нет, родной ipt_netflow тоже не собирается под 2.4 (хотя я год назад пробовал), сейчас еще попробую - вдруг что-то изменилось...

и еще вопрос - как ловить трафик после обратного NAT'а?

 

ну, т.е. у нас есть прозрачный squid, который работает в режиме transparent. средствами iptables трафик с уже подмененным адресом поймать не получается, во всех цепочках либо трафик еще не подменен, либо его уже нет вообще.

 

pcap, конечно, такой трафик ловит...

 

юзаем 2.4 по причине стабильности (сколько нынче изменений делается в 2.6 за месяц?), и кучи доморощеных патчей, которые непонятно как будут работать под 2.6 (та же mppc компрессия)

 

upd: так и не компилируется:

 

In file included from ipt_NETFLOW.c:18:
/usr/src/linux-2.4.37-anp18b4/include/linux/igmp.h:150: ошибка: поле 'multi' имеет неполный тип
/usr/src/linux-2.4.37-anp18b4/include/linux/igmp.h:202: предупреждение: декларация 'struct ip_mreq_source' внутри списка параметров
/usr/src/linux-2.4.37-anp18b4/include/linux/igmp.h:202: предупреждение: область действия типа - только данная декларация или определение, что может не соответствовать вашим намерениям
/usr/src/linux-2.4.37-anp18b4/include/linux/igmp.h:203: предупреждение: декларация 'struct ip_msfilter' внутри списка параметров
/usr/src/linux-2.4.37-anp18b4/include/linux/igmp.h:205: предупреждение: декларация 'struct ip_msfilter' внутри списка параметров
/usr/src/linux-2.4.37-anp18b4/include/linux/igmp.h:207: предупреждение: декларация 'struct group_filter' внутри списка параметров
In file included from ipt_NETFLOW.c:19:
/usr/src/linux-2.4.37-anp18b4/include/linux/inetdevice.h:89: ошибка: 'IFNAMSIZ' undeclared here (not in a function)
/usr/src/linux-2.4.37-anp18b4/include/linux/inetdevice.h: В функции 'in_dev_get'
/usr/src/linux-2.4.37-anp18b4/include/linux/inetdevice.h:143: ошибка: доступ по указателю на неполный тип
/usr/src/linux-2.4.37-anp18b4/include/linux/inetdevice.h: В функции '__in_dev_get'
/usr/src/linux-2.4.37-anp18b4/include/linux/inetdevice.h:153: ошибка: доступ по указателю на неполный тип
/usr/src/linux-2.4.37-anp18b4/include/linux/inetdevice.h:154: предупреждение: control reaches end of non-void function

 

и еще куча ошибок, видимо, связаных с изменение в хеадерах/структурах ядра

 

Edited August 15, 2009 by [anp/hsw]

[usachaa]

Да именно два поля в ipt_ipcad_flow_checkpoint. sif и dif что имеют место быть в netflow формате, и которые вот вы недавно фиксили для ядер 2.6.28 и выше. Просто

фактические интерфейсы откуда пакет пришел и через какой интерфейс покинул хост. Практической пользы от записи промежуточных интерфейсов типа IMQ наверное нет.

[JMan]

Да именно два поля в ipt_ipcad_flow_checkpoint. sif и dif что имеют место быть в netflow формате, и которые вот вы недавно фиксили для ядер 2.6.28 и выше. Просто

фактические интерфейсы откуда пакет пришел и через какой интерфейс покинул хост. Практической пользы от записи промежуточных интерфейсов типа IMQ наверное нет.

Более подробно надо описание, я же спрашивал считать разными записями если одна из сетевух уже другая? Опиши весь процесс плиз. Также по поводу IMQ если он юзается, то он буде светится ибо трафик либо в него идет либо из него, так что как не крути он он там светится будет, это же как виртуальная сетевуха.

Edited August 15, 2009 by JMan

[JMan]

нет, родной ipt_netflow тоже не собирается под 2.4 (хотя я год назад пробовал), сейчас еще попробую - вдруг что-то изменилось...

и еще вопрос - как ловить трафик после обратного NAT'а?

 

ну, т.е. у нас есть прозрачный squid, который работает в режиме transparent. средствами iptables трафик с уже подмененным адресом поймать не получается, во всех цепочках либо трафик еще не подменен, либо его уже нет вообще.

 

pcap, конечно, такой трафик ловит...

 

юзаем 2.4 по причине стабильности (сколько нынче изменений делается в 2.6 за месяц?), и кучи доморощеных патчей, которые непонятно как будут работать под 2.6 (та же mppc компрессия)

 

upd: так и не компилируется:

 

и еще куча ошибок, видимо, связаных с изменение в хеадерах/структурах ядра

Да, мне помнится, по сетевой части много чего отличается от 2.6. А также в 2.6 сразу делалось что сетевые пакеты в параллель могут обрабатывать много процов (с разных очередей). А в 2.4 помнится (могу ошибаться давно изучал) есть глобальный лок на эту часть кода посему обрабатывать сможет одновременно только одно из ядер :(. А по надёжности 2.6 стоит на многих реально на груженых шлюзах (под 4 гигабита трафика валит) и просто роутерах и отлично себя зарекомендовал, есть уже ап тамй больше 2 лет как настроили роутер так и жужыт без остановки.

[usachaa]

В netflow потоке экспортируемом ipt_NETFLOW есть поля sif dif (ifindex интерфейсов) в записях, вот их требуется продублировать в формате данных получаемых через /proc. Данные по абоненту считаются по направлениям. Направление Интернет, направление сетей соседних оперторов получаемых через точки обмена трафиком, и тд. Одна сеть может быть доступна через разные каналы в разные моменты времени, и агрерировать по сетям не получается, приходится списки сетей постоянно обновлять. Необходимо знать откуда пришел пакет, и через какой порт он покинул роутер. Использование IMQ не отражается никак на netflow данных собранный средствами ipt_NETFLOW, там sif = индексу физического интерфейса откуда пришел трафик, а dif = индексу через который он покинул роутер.

[JMan]

А ответь на: если трафик сначала шёл из одной сетевухи, а потом пришел с другой, то это к разным записям считать или в старой обновлять индекс интерфейса. Учитывать вообще номера интерфейса в сравнение записей?

[usachaa]

Понял наконец что вы имеете ввиду. Тоесть соединение открылось через одну пару sif<->dif и в процессе поменялись итнерфейсы. Да такое возможно. Надо разделять на две записи и больше, агрегировать и по этим полям надо.

[JMan]

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

[JMan]

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

Типа пример -m HASH_CLASSIFY --table 1 dst -j other_table

типа ищем таблице номер 1 по айпи из dst пакета или src можно задавать и если обнаружено и присвоен номер класса, то все гуд пригнуть в такую то цепочку или принять пакет кому что нужно.

Что скажут админы нужная вещь, или есть где-то такая штука? А то у нас я как посмотрел на тот ужас что творится при классификации сразу захотелось исправить, а так один быстрый поиск по хешу и сразу классификация в одной команде, а не куче правил.

 

[usachaa]

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

Типа пример -m HASH_CLASSIFY --table 1 dst -j other_table

типа ищем таблице номер 1 по айпи из dst пакета или src можно задавать и если обнаружено и присвоен номер класса, то все гуд пригнуть в такую то цепочку или принять пакет кому что нужно.

Что скажут админы нужная вещь, или есть где-то такая штука? А то у нас я как посмотрел на тот ужас что творится при классификации сразу захотелось исправить, а так один быстрый поиск по хешу и сразу классификация в одной команде, а не куче правил.

А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?.

Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него.

[JMan]

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

Типа пример -m HASH_CLASSIFY --table 1 dst -j other_table

типа ищем таблице номер 1 по айпи из dst пакета или src можно задавать и если обнаружено и присвоен номер класса, то все гуд пригнуть в такую то цепочку или принять пакет кому что нужно.

Что скажут админы нужная вещь, или есть где-то такая штука? А то у нас я как посмотрел на тот ужас что творится при классификации сразу захотелось исправить, а так один быстрый поиск по хешу и сразу классификация в одной команде, а не куче правил.

А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?.

Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него.

нет это как раз и есть вместо пробегания по иерархии, эта команда должна найти в хеше этот айпи, и в хеше сразу хранится вместе с айпи в какой класс его отправить. То есть так находим по хешу айпи с каждым айпи в хеше хранится в какой класс пометить пакеты которые попадают под этот айпи. Если находим айпи сразу класифай делаем на месте.

[usachaa]

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

Типа пример -m HASH_CLASSIFY --table 1 dst -j other_table

типа ищем таблице номер 1 по айпи из dst пакета или src можно задавать и если обнаружено и присвоен номер класса, то все гуд пригнуть в такую то цепочку или принять пакет кому что нужно.

Что скажут админы нужная вещь, или есть где-то такая штука? А то у нас я как посмотрел на тот ужас что творится при классификации сразу захотелось исправить, а так один быстрый поиск по хешу и сразу классификация в одной команде, а не куче правил.

А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?.

Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него.

нет это как раз и есть вместо пробегания по иерархии, эта команда должна найти в хеше этот айпи, и в хеше сразу хранится вместе с айпи в какой класс его отправить. То есть так находим по хешу айпи с каждым айпи в хеше хранится в какой класс пометить пакеты которые попадают под этот айпи. Если находим айпи сразу класифай делаем на месте.

Ну если это даст выиграш в производительности, то да нужная штука будет. Хотя "tc filter add dev ethX parent 1:0 protocol ip fw" очень шустро раскидывает пакеты по иерархии. При рейте в 400тыс пакетов/сек опрофайл показывает что классификатор потребляет ресурсов на уровне 0.5-0.7%

 

[JMan]

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

Типа пример -m HASH_CLASSIFY --table 1 dst -j other_table

типа ищем таблице номер 1 по айпи из dst пакета или src можно задавать и если обнаружено и присвоен номер класса, то все гуд пригнуть в такую то цепочку или принять пакет кому что нужно.

Что скажут админы нужная вещь, или есть где-то такая штука? А то у нас я как посмотрел на тот ужас что творится при классификации сразу захотелось исправить, а так один быстрый поиск по хешу и сразу классификация в одной команде, а не куче правил.

А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?.

Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него.

нет это как раз и есть вместо пробегания по иерархии, эта команда должна найти в хеше этот айпи, и в хеше сразу хранится вместе с айпи в какой класс его отправить. То есть так находим по хешу айпи с каждым айпи в хеше хранится в какой класс пометить пакеты которые попадают под этот айпи. Если находим айпи сразу класифай делаем на месте.

Ну если это даст выиграш в производительности, то да нужная штука будет. Хотя "tc filter add dev ethX parent 1:0 protocol ip fw" очень шустро раскидывает пакеты по иерархии. При рейте в 400тыс пакетов/сек опрофайл показывает что классификатор потребляет ресурсов на уровне 0.5-0.7%

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

[2c2i]

Видимо usachaa юзает IPMARK http://www.netfilter.org/projects/patch-o-...m-external.html, в iptables, а затем fw классификатор в tc.

IPMARK как я понимаю так и работает - ищет нужное правило по хешу от адреса и правило ставит марк. Вы, как я понимаю предлагаете реализовать любой таргет в таком правиле, и сделать в iptables что то похожее на хеш фильтры tc. Думаю это отличная идея.

[JMan]

Видимо usachaa юзает IPMARK http://www.netfilter.org/projects/patch-o-...m-external.html, в iptables, а затем fw классификатор в tc.

IPMARK как я понимаю так и работает - ищет нужное правило по хешу от адреса и правило ставит марк. Вы, как я понимаю предлагаете реализовать любой таргет в таком правиле, и сделать в iptables что то похожее на хеш фильтры tc. Думаю это отличная идея.

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

Работа уже ведется в этом направлении.

[usachaa]

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

Типа пример -m HASH_CLASSIFY --table 1 dst -j other_table

типа ищем таблице номер 1 по айпи из dst пакета или src можно задавать и если обнаружено и присвоен номер класса, то все гуд пригнуть в такую то цепочку или принять пакет кому что нужно.

Что скажут админы нужная вещь, или есть где-то такая штука? А то у нас я как посмотрел на тот ужас что творится при классификации сразу захотелось исправить, а так один быстрый поиск по хешу и сразу классификация в одной команде, а не куче правил.

А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?.

Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него.

нет это как раз и есть вместо пробегания по иерархии, эта команда должна найти в хеше этот айпи, и в хеше сразу хранится вместе с айпи в какой класс его отправить. То есть так находим по хешу айпи с каждым айпи в хеше хранится в какой класс пометить пакеты которые попадают под этот айпи. Если находим айпи сразу класифай делаем на месте.

Ну если это даст выиграш в производительности, то да нужная штука будет. Хотя "tc filter add dev ethX parent 1:0 protocol ip fw" очень шустро раскидывает пакеты по иерархии. При рейте в 400тыс пакетов/сек опрофайл показывает что классификатор потребляет ресурсов на уровне 0.5-0.7%

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

Немного подробностей, чтобы вам было понятнее.

Имеется роутер с кучей гигабитных интерфейсов Intel 82571EB(PCIE,NAPI, 2 TX HANDLER). Со стороны клиентов на него приходит около 50 vlan на bond группу из 4 интерфейсов. В каждом влане от 60 до 180 юзверей. "Клиентские" интерфейсы переименовываются c cli.XXX для оптимизированного группового применения правил iptables, также "Пиринговые" в peer.XXX, а "Интернетные" в up.xxx.

Используются несколько imq псевдоинтерфейсов, для организации шейпов по направлениям. Локальный, пиринговый, интернет.

На примере локального трафика.

 

Первое:

Заворачиваем локальный трафик(между клиентами) на imq0 интерфейс. Необходимо использовать MARK, так как imq не полная эмуляция и указывать с -i/-o imq0 не получается, тем более маркировка пригодится ниже. Маркируем весь локальный трафик 4, и по этому марку заворачиваем в imq0.

В mangle FORWARD имеем.

6559M 6287G MARK all -- cli+ cli+ 0.0.0.0/0 0.0.0.0/0 MARK xset 0x4/0xffffffff

6559M 6287G IMQ all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4 IMQ: todev 0

 

Второе

На imq0 построена htb иерархия классов с именами из последних двух октетов в хексе. Пример (192.168.16.133) -> 16.133-> 1085

В mangle POSTROUTING имеем

6555M 6284G IPMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4 IPMARK dst ip and 0xffff or 0x10000

IPMARK перемаркирует весь трафик промаркированный выше 4(локальный), исходя из двух последних октетов dst IP, пример (192.168.16.133) -> 16.133-> 1085

Новый MARK на трафик dst ip 192.168.16.133 будет 1085. В итоге мы имеем что весь трафик на устройстве imq0 промаркирован.

 

Третье.

Классификатор.

Раскидываем трафик по пользовательским классам на imq0.

Одной командой.

/sbin/tc filter add dev imq0 parent 1:0 protocol ip fw

Весь трафик попадает согласно маркировке в одноименные классы.

 

Что имеем в итоге, минимум правил в iptables/tc, прекрасную маштабируемость, настройки никак не зависят от количества абонентов. Остается только следить за двумя моментами. Чтоб не появились в сети ip с одинаковыми двумя последними октетами, иначе попадут в один класс, посему приходится следить за заведением новых серых сетей, чтоб они 3 октетом не пересеклись с имеющимися реальными сетями, и за своевременном созданием классов в иерархиях, иначе весь трафик что не нашел для себя класса по марку попадает в дефолтный класс с низкой скоростью 1bit/s(фактически банится).

 

 

 

[usachaa]

Видимо usachaa юзает IPMARK http://www.netfilter.org/projects/patch-o-...m-external.html, в iptables, а затем fw классификатор в tc.

IPMARK как я понимаю так и работает - ищет нужное правило по хешу от адреса и правило ставит марк. Вы, как я понимаю предлагаете реализовать любой таргет в таком правиле, и сделать в iptables что то похожее на хеш фильтры tc. Думаю это отличная идея.

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

Работа уже ведется в этом направлении.

Я решаю задачу с несколькими ip у пользователя даже из разных сегментов, заведеним одного общего класса для пользователя, и в него как дочерние классы для каждого его IP . С использыванием imq трафик всех сетей проходит по одному интерфейсу и это становится возможным.

 

 

[JMan]

Видимо usachaa юзает IPMARK http://www.netfilter.org/projects/patch-o-...m-external.html, в iptables, а затем fw классификатор в tc.

IPMARK как я понимаю так и работает - ищет нужное правило по хешу от адреса и правило ставит марк. Вы, как я понимаю предлагаете реализовать любой таргет в таком правиле, и сделать в iptables что то похожее на хеш фильтры tc. Думаю это отличная идея.

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

Работа уже ведется в этом направлении.

Я решаю задачу с несколькими ip у пользователя даже из разных сегментов, заведеним одного общего класса для пользователя, и в него как дочерние классы для каждого его IP . С использыванием imq трафик всех сетей проходит по одному интерфейсу и это становится возможным.

Ну как мы и думали, у меня не совсем получится такое, ибо уже реально пересекаться будут это раз. А во вторых юзеров столько что архитектура давно уже не на одном шлюзе. Есть локальная типа точка обмена трафиком куда включаю шлюзы (на компах или аппаратные) которые маршрутизируют трафик на пиров, или в другие точки обмена трафиком, на аплинки и т.п. И туда же включаются шлюзи доступа юзеров в инте. Посему на шлюзах доступа в инет есть только интерфейс включения в точку обмена трафиком, и вланы где юзеры. В такое архитектуре резервирование на важных направлениях легко делается (для аплинков через бгп, просто 2 роутера включения) для юзерских шлюзов шлюз на подхвате что переведет на себя вланы и конфиг упавшего шлюза, или горячее всегда все заведено только поднять интерфейсы, типа для випов или для юриков. Вот такое. А так как есть уже могут быть пересечение 2 байт последних, то тут через марк уже не как :(. Ладно работаем дальше как что все попробуете и поймете надо или нет :). Еще есть одна идея, но пока не придумал как реализовать. Типа по хешу находим нужный айпи, а в хеше храним цепочку куда надо прыгнуть, и прыгаем в нее. Типа когда надо в зависимости от юзера надо специфичные для него правила применить.