Jump to content
Калькуляторы

ipt_netflow-1.6 & ipcad добавление потдержки как в ipcad подсчета трафика в ipt_netflow-1.6

Видимо 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 тоже вяжется хорошо.

 

Share this post


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

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

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

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

Share this post


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

Привет! Хотел спросить не сделал еще версии с информацией по интерфейсам? Ато я тут вкуриваю в ядреный кодинг, и пока както негусто...

Если есть что обновленное, выложи плс?

 

Если кому надо - патч в аттаче чтобы на 2.6.32 собралось (накладывать на 1.6) - вроде работает, под нагрузкой пока не проверял.

ip_netflow_2.6.32.patch.gz

Share this post


Link to post
Share on other sites
Что скажут админы нужная вещь, или есть где-то такая штука? А то у нас я как посмотрел на тот ужас что творится при классификации сразу захотелось исправить, а так один быстрый поиск по хешу и сразу классификация в одной команде, а не куче правил.
В ipset хэши IP-адресов и сетей уже есть (см. iphash и nethash), их просто надо как-то связать с номерами классов tc. Видимо стоит сделать модификацию iphash и nethash (условно назовем ее ipclasshash), в которую можно записывать не только IP-адреса, но и номера классов. Также понадобится target-модуль, чтобы делать --set iphash1 src -j CLASSIFY в правилах iptables. Получится некий аналог pipe tablearg из FreeBSD, но более гибкий. Это представляет некий интерес, а маркировка на шейпере особо не нужна, это лишний промежуточный этап перед классификацией.

 

Классификация по хэшам делается также и средствами tc (см. flow classifier, u32 hashing filters). В частности, модули IPMARK и IPCLASSIFY можно полностью заменить использованием классификатора flow. u32 предоставляет большую гибкость, чем flow, но у него слишком мелкие хэши (по 256 записей), и их приходится выстраивать в цепочки.

Edited by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Действительно перезалейте пожалуйста или на мыло hub00@mail.ru пришлите.

Share this post


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

Привет! Хотел спросить не сделал еще версии с информацией по интерфейсам? Ато я тут вкуриваю в ядреный кодинг, и пока както негусто...

Если есть что обновленное, выложи плс?

 

Если кому надо - патч в аттаче чтобы на 2.6.32 собралось (накладывать на 1.6) - вроде работает, под нагрузкой пока не проверял.

Обнови плиз патч

Share this post


Link to post
Share on other sites

где сейчас взять патченную версию?

upd. оказывается, у меня уже патченная :)

Edited by marikoda

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this