[Am1G0]

Приветствую, коллеги,

 

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

Задача становится интересной благодаря тому, что клиентов в районе 18 тысяч и создавать для каждого отдельный qdisc и фильтр - совсем неправильно.

Hash-based матчинг не подходит потому, что лимит должен распространяться на каждого клиента отдельно, не объединяя доступную полосу нескольким клиентам. Если делать в лоб, то получится по 18 тысяч фильтров и qdisc'ов, что совсем не айс.

 

Если более глобально, то задача выглядит так:

шейпить входящий трафик и пошейпленный уже пускать дальше. Общий шейпинг (для всех клиентов) реализован с помощью редиректа трафика на ifb и использования htb на нём, но вот как изящно и без костылей реализовать внутри ещё и per-ip independent шейпинг, который численно вовсе необязательно соотносится с общим - ума не приложу и буду очень признателен за советы.

[bos9]

Толи у меня дислексия развивается, толи...

Но из того что уловил

Hash-based матчинг не подходит потому, что лимит должен распространяться на каждого клиента отдельно, не объединяя доступную полосу нескольким клиентам.

неправда! )

[snark]

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

...

клиентов в районе 18 тысяч

 

При таком кол-ве пользователей купите SCE и задача решится сама собой.

[kayot]

Создать эти самые 18к qdisc и filter + естественно hash на фильтры. Никаких объединений там нет, класс на клиента с каким угодно лимитом(хоть разный каждому, хоть одинаковый), а с хешами никаких проблем с большим числом классов/фильтров нет.

[photon]

С хэш-фильтрами и кучей классов все прекрасно работает, пользователи шейпятся по отдельности. Просто нужно создавать правила не тупо через командную строку, а загружать через stdin: cat tc.rules | tc -b.

[Am1G0]

С хэш-фильтрами и кучей классов все прекрасно работает, пользователи шейпятся по отдельности. Просто нужно создавать правила не тупо через командную строку, а загружать через stdin: cat tc.rules | tc -b.

да, всё прекрасно, но 18 тысяч классов... что ж, если иных альтернатив нет :)

[photon]

да, всё прекрасно, но 18 тысяч классов... что ж, если иных альтернатив нет :)

Во FreeBSD есть "динамические пайпы", для которых не нужно описывать кучу очередей, а создать столько правил, сколько разных тарифов. Или pipe tablearg, но там как и в Линуксе нужно отдельными правилами описывать все очереди.

Edited May 29, 2013 by photon

[~AsmodeuS~]

только пайп на абонента или два елси вход выход при 18 тис просто положит систему и елси не положит по подниматься будте минут 5

 

при 18 тис лучше всего воспользоваться аппатными решениями типа Junipex MX80, Ericson RedBack, Cisco ISG, потраченные деньги с лихвой отобют себя в стабильности работы и функционале

[bos9]

Просто нужно создавать правила не тупо через командную строку, а загружать через stdin: cat tc.rules | tc -b.

 

а почему через конвейер, а не просто tc -b <filename> ? Привычка?

[photon]

Можно и через файл, я не настаиваю.