ipt_netflow-1.6 & ipcad

[ipt_netflow-1.6 & ipcad]

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

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

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

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

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

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

У нас практически также. Несколько роутеров близнецов. На каждом часть вланов при падении одного hearbeat поднимает у себя недостающие линки другого.

Трафик между эти роутерами отдельная песня.

Но смысл в решении похожий. Кстати еще рац. предложение, можно в лог писать realm маршрутов. Откуда пришло ушло. Тоже очень полезная информация. И с iptables тоже вяжется хорошо.

 

[ipt_netflow-1.6 & ipcad]

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

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

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

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

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

 

 

[ipt_netflow-1.6 & ipcad]

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

Типа пример -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(фактически банится).

 

 

 

[ipt_netflow-1.6 & ipcad]

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

Типа пример -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%

 

[ipt_netflow-1.6 & ipcad]

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

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

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

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

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

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

[ipt_netflow-1.6 & ipcad]

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

[ipt_netflow-1.6 & ipcad]

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

[ipt_netflow-1.6 & ipcad]

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

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

[ipt_netflow-1.6 & ipcad]

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