pptp + ifb = bandwidth sharing?

Можно (через tc filter ... action mirred egress redirect). Насчет разделить полосу... Повестиь htb и нарезать каждому клиенту свою полоску? Отлавливать можно где угодно, но смысла ловить с реальным IP нет - вам ведь надо трафик шейпить в соответствии с внутренним IP клиента.

Отлавливать можно где угодно, но смысла ловить с реальным IP нет - вам ведь надо трафик шейпить в соответствии с внутренним IP клиента.

Совершенно верно. Вот поэтому и спрашиваю... получается, нужно ловить egress pppX? заворачивать на ifb, там его шейпить, метить и отдавать на pppX ?

Меня интересует равномерное деление полосы на всех. Когда-то это было esfq, сейчас как-то через flows classifier, но я с ним не пробовал, увы. За подсказки в этом поле тоже буду благодарен.

а кто то пробовал делать:

filter add dev ${UP_DEV} parent 1:${tmp}01 protocol ip prio 10 u32  match u32 0 0 flowid 1:${tmp}01 action mirred egress redirect dev ${DOWN_DEV}

Опять не совсем понимаю

Пакет пойдет так?

internet  ->  eth0  ->   nat ->  pppX  -> client
       ingress    egress    ingress  egress

и выхватить его надо с ingress pppX ? Или как? Если вы понимаете, как пойдет пакет (я давненько с этим не работал), то, пожалуйста, напишите.

Пакет из инета к юзеру:

net -> eth0 ingress qdisc -> netfilter(nat) -> routing -> netfilter -> ppp0 egress qdisc -> tunnel incapsulation

tunnel dencapsulation -> ppp0 ingress qdisc -> netfilter(nat) -> routing -> netfilter(nat) -> eth0 egress qdisc

net -> eth0 ingress qdisc ->redirect-> ifb0 egress qdisc -> netfilter ...

Но так как требуется сделать нат на этой же системе, то возникают проблемы - если вешать htb на ppp0, ингресс каждого ppp редиректить на свой ifb и там вешать htb для шейпинга юзерского аплоада то для разных юзеров нет общих классов и нельзя сделать равномерное разделение трафика. Другой вариант - редиректить весь egress всех ppp на один ifb, a весь ingress на другой в моем старом тесте не сработал.

net -> eth0 ingress qdisc ->redirect-> ifb0 egress qdisc -> netfilter ...

Где в этом случае происходит nat?

В нетфильтре. Я написал пример редиректа для eth0, если же это аплинк интерфейс и есть нат то дело должно выглядеть так:

даунлоад юзера:

net->eth0 ingress qdisc-> netfilter(nat)-> routing -> netfilter-> ppp0 egress qdisc(HTB,etc) -> client

аплоад юзера:

client->ppp0 ingress qdisc->redirect-> ifb0 egress qdisc(HTB,etc) -> netfilter -> routing -> netfilter(nat) -> eth0 egress qdisc -> net

Вопрос в том можно ли сделать

даунлоад юзера:

ppp0 egress qdisc -> redirect -> ifb0 egress qdisc
ppp1 egress qdisc -> redirect -> ifb0 egress qdisc 
pppN egress qdisc -> redirect -> ifb0 egress qdisc

аплоад юзера:

ppp0 ingress qdisc -> redirect -> ifb1 egress qdisc 
ppp1 ingress qdisc -> redirect -> ifb1 egress qdisc 
pppN ingress qdisc -> redirect -> ifb1 egress qdisc

Если можно - это то чего вы хотите, потом достаточно сделать на ifb устройствах фильтры/классы/дисциплины

Вот, про даунлоад юзера меня как раз и интересует. Если я правильно понимаю, то после ifb0 egress qdisc пакет еще раз попадает на pppN egress qdisc Т.е. нужно еще маркер некий поставить, чтоб знать какой пакет прошел через ifb, а какой еще нет. Верно?

Как уже говорил, я когда то пробовал делать редирект с ppp0 egress на ifb и это у меня не получилось.

По я тогда думал что должно работать как то так (если вообще оно может работать)

netfilter-> ppp0 egress qdisc -> redirect -> ifb0 egress qdisc -> ppp0???

Маркер можно ставить с помошью skbedit, если нужно это.

Возможно попробовать так же сделать роут в интерфейс ifb, затем там сделать хештаблицу, и в ней делать редиректы на юзерские ppp.

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

Ну и можно попробовать неправославный imq вообще.

>Маркер можно ставить с помошью skbedit, если нужно это.

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

P.S. LARTC читал, но давно

http://kerneltrap.org/mailarchive/linux-netdev/2008/12/5/4327834