[sirmax]

Добрый день!

 

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

 

Сейчас схема простейшая - каждый клиент заворачивается в отдельный 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 отслеживать соединения приоритетных клиентов.

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

[sirmax]

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

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).

[minderm]

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

[sirmax]

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

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

 

PS

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

[bos9]

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

 

IMQ

[minderm]

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

 

 

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

[voron]

2minderm

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

[minderm]

2minderm

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

 

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

[NiTr0]

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

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

[sirmax]

2minderm

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

 

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

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

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

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

 

 

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

[NiTr0]

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

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

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

 

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

[sirmax]

NiTr0

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

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

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

 

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

 

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

[NiTr0]

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

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

 

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

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

 

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

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

 

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

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

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