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

перенаправление траффикк ifbX --> ifbY

Добрый день!

 

Есть желание соорудить "шыбко хитрый" шейпер.

 

Сейчас схема простейшая - каждый клиент заворачивается в отдельный ifbХ где на него в зависимости от "навернутости" приклеивается его личный шейпер.

Хотелось бы весь траффик всех клиентов после прохождения ifbX (или до - в зависимости от направления) завернуть в ifbY где применить на них еще некую общюю политику.

 

 

К примеру, есть 2 клиента по 512кбита и 2 клиент по 10мбит. Всего внешний канал 15 мбит.

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

Т.е. 512 должны получить гарантировано.

 

Задача усугубляется тем, что на выходе НАТ, и на выходном интерфейсе ничего не получиться разрулить.

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

 

Буду очень рад ссылкам на документацию, и примерам.

 

#Move packets from ETH to IFB

Так правила добавить можно:

/sbin/tc filter add dev ifb1 parent 1:    protocol ip u32 match ip dst 172.16.2.253 action mirred egress redirect dev ifb3                                                                                                                      
/sbin/tc filter add dev ifb2 parent ffff:  protocol ip u32 match ip src 172.16.2.253 action mirred egress redirect dev ifb4

но траффик не ходит.

 

Что на самом деле представляет собой action mirred egress redirect dev ifb3 и куда траффик передается на следующем шаге после фильтра?

 

 

PS

Есть конечно вариант с CONNMARK отслеживать соединения приоритетных клиентов.

но хочется изящного решения ...

Share this post


Link to post
Share on other sites

Похоже, я действительно желаю странного ...

B) Do not redirect from one IFB device to another.

Remember that IFB is a very specialized case of packet redirecting

device. Instead of redirecting it puts packets at the exact spot

on the stack it found them from.

Redirecting from ifbX->ifbY will actually not crash your machine but your

packets will all be dropped (this is much simpler to detect

and resolve and is only affecting users of ifb as opposed to the

whole stack).

Share this post


Link to post
Share on other sites

На этом форуме есть замечательный шейпер от Photon'а. Его можно повесить на внутренний интерфейс, а внешнем самому написать пару правил. И никаких отдельный IFB на пользователя не понадобиться.

Share this post


Link to post
Share on other sites

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

но я хочу немного не это.

 

PS

Шейпер на внешнем интерфесе одновременно с НАТ - подробнее плз.

Share this post


Link to post
Share on other sites

Шейпер на внешнем интерфесе одновременно с НАТ - подробнее плз.

 

IMQ

Share this post


Link to post
Share on other sites

Шейпер на внешнем интерфесе одновременно с НАТ - подробнее плз.

 

 

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

Share this post


Link to post
Share on other sites

2minderm

Это всё ясно и понятно. Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими. Полисинг на низких скоростях грустен.

Share this post


Link to post
Share on other sites

2minderm

Это всё ясно и понятно. Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими. Полисинг на низких скоростях грустен.

 

Не убирая per client ifb - никак. А вот если отказаться, то уже появляется простор для маневров.

Share this post


Link to post
Share on other sites

Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими.

А почему бы не привязать классы низкоприоритетных к одному подклассу корневого класса, высокоприоритетных - к другому?

Share this post


Link to post
Share on other sites

2minderm

Это всё ясно и понятно. Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими. Полисинг на низких скоростях грустен.

 

Не убирая per client ifb - никак. А вот если отказаться, то уже появляется простор для маневров.

вернулись к тому с чего начали. Если запихнуть весь траффик в один интерфейс ifb то сгородить можно шейпер любой сложности.

Но не хочется.

Удобнее вешать шейпер на ifb per client

 

 

Т.к. пока разговор идет не о гигабитах то можно прогонять траффик через серв 2 раза... но это тоже решение которое не блещит изяществом.

Share this post


Link to post
Share on other sites

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

Но не хочется.

А в чем проблема-то? Городить особо ничего не нужно, хеши в помощь если более 50-100 классов, а вот куча IFB - не есть хорошо ИМХО. Хеш-фильтры с несколькими классами на пул в 2к-4к адресов элементарно создаются в общем-то скриптом, правда это занимает секунд 20-40...

 

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

Share this post


Link to post
Share on other sites

NiTr0

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

Пока скорости небольшие и ресурсы позволяют - почему нет?

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

 

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

 

Кстати, сейчас у меня стопка интерфейсов, схема влан-на-дом, и кучи фильтров нет и не будет. все предельно просто и прозрачно.

Share this post


Link to post
Share on other sites

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

2 подкласса к классу абонента. Тот же эффект.

 

Пока скорости небольшие и ресурсы позволяют - почему нет?

Почему - вы вроде как уже сами ответили :) Потому что нужного вам функционала не дает.

 

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

Тспдамп прекрасно и на eth/vlan становится. И жует прекрасно сотни мегабит траффика.

 

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

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

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

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