sirmax Posted March 19, 2011 · Report post Добрый день! Есть желание соорудить "шыбко хитрый" шейпер. Сейчас схема простейшая - каждый клиент заворачивается в отдельный 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
sirmax Posted March 20, 2011 · Report post Похоже, я действительно желаю странного ... 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
minderm Posted March 25, 2011 · Report post На этом форуме есть замечательный шейпер от Photon'а. Его можно повесить на внутренний интерфейс, а внешнем самому написать пару правил. И никаких отдельный IFB на пользователя не понадобиться. Share this post Link to post Share on other sites
sirmax Posted March 25, 2011 · Report post Я понимаю что то что я хочу можно сделать несколькими разными способами, в том числе и с помошью одного сложного шейпера. но я хочу немного не это. PS Шейпер на внешнем интерфесе одновременно с НАТ - подробнее плз. Share this post Link to post Share on other sites
bos9 Posted March 25, 2011 · Report post Шейпер на внешнем интерфесе одновременно с НАТ - подробнее плз. IMQ Share this post Link to post Share on other sites
minderm Posted March 26, 2011 · Report post Шейпер на внешнем интерфесе одновременно с НАТ - подробнее плз. NAT происходит после того, как пакет отмаршрутизирован и переложен из внутреннего интерфейса во внешний. Соответственно делаем шейпинг на внутреннем интерфейсе. А исходящую скорость резать можно на том же ifb на которую завернут исходящий трафик с внутреннего интерфейса, либо полисинг. Share this post Link to post Share on other sites
voron Posted March 26, 2011 · Report post 2minderm Это всё ясно и понятно. Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими. Полисинг на низких скоростях грустен. Share this post Link to post Share on other sites
minderm Posted March 26, 2011 · Report post 2minderm Это всё ясно и понятно. Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими. Полисинг на низких скоростях грустен. Не убирая per client ifb - никак. А вот если отказаться, то уже появляется простор для маневров. Share this post Link to post Share on other sites
NiTr0 Posted March 26, 2011 · Report post Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими. А почему бы не привязать классы низкоприоритетных к одному подклассу корневого класса, высокоприоритетных - к другому? Share this post Link to post Share on other sites
sirmax Posted March 26, 2011 · Report post 2minderm Это всё ясно и понятно. Вопрос в том как, не убирая ifb per client, сделать шейпер дающий одним клиентам приоритет на другими. Полисинг на низких скоростях грустен. Не убирая per client ifb - никак. А вот если отказаться, то уже появляется простор для маневров. вернулись к тому с чего начали. Если запихнуть весь траффик в один интерфейс ifb то сгородить можно шейпер любой сложности. Но не хочется. Удобнее вешать шейпер на ifb per client Т.к. пока разговор идет не о гигабитах то можно прогонять траффик через серв 2 раза... но это тоже решение которое не блещит изяществом. Share this post Link to post Share on other sites
NiTr0 Posted March 26, 2011 · Report post Если запихнуть весь траффик в один интерфейс ifb то сгородить можно шейпер любой сложности. Но не хочется. А в чем проблема-то? Городить особо ничего не нужно, хеши в помощь если более 50-100 классов, а вот куча IFB - не есть хорошо ИМХО. Хеш-фильтры с несколькими классами на пул в 2к-4к адресов элементарно создаются в общем-то скриптом, правда это занимает секунд 20-40... А гонять траффик через сервер дважды - смысл, если куда проще все в один IFB запихнуть? Share this post Link to post Share on other sites
sirmax Posted March 26, 2011 · Report post NiTr0 ifb на клиента дает некоторую гибкость, например можно не просто шейпить, а "хитро", что бы клиент сам себе торрентом не ломал хттп. ну и т.п. Пока скорости небольшие и ресурсы позволяют - почему нет? Дебагать удобно, тспдамп на ифб стал и смотришь. Ну и считать на них же, если возникнет такое желание ... А вот с одним IFB это возможно, но все таки шейпер получиться с большим числом вложенных классов, совсем неочевидная конструкция. Кстати, сейчас у меня стопка интерфейсов, схема влан-на-дом, и кучи фильтров нет и не будет. все предельно просто и прозрачно. Share this post Link to post Share on other sites
NiTr0 Posted March 26, 2011 · Report post ifb на клиента дает некоторую гибкость, например можно не просто шейпить, а "хитро", что бы клиент сам себе торрентом не ломал хттп. ну и т.п. 2 подкласса к классу абонента. Тот же эффект. Пока скорости небольшие и ресурсы позволяют - почему нет? Почему - вы вроде как уже сами ответили :) Потому что нужного вам функционала не дает. Дебагать удобно, тспдамп на ифб стал и смотришь. Ну и считать на них же, если возникнет такое желание ... Тспдамп прекрасно и на eth/vlan становится. И жует прекрасно сотни мегабит траффика. А вот с одним IFB это возможно, но все таки шейпер получиться с большим числом вложенных классов, совсем неочевидная конструкция. А зачем вам очевидность (вернее, читабельность) конструкции? Вам ведь нужно только шейпить и смотреть статистику - ну так и делаете скрипт, который инициализирует хеш-таблицы фильтров и дерево классов, + он же меняет скорость для нужного IP из дерева, ну и отображает статистику по классам. Подобный скрипт ваял для себя, выложил здесь. Работает с того времени прекрасно, правда - перетерпел некоторые несущественные изменения (добавилась возможность работы с несколькими интерфейсами), которые вам не особо актуальны. Последний вариант живет здесь. Share this post Link to post Share on other sites
