Шейпинг на ppp NASе

[KaYot 3 709]

Есть сервера доступа терминирующие PPPoE, на них шейпинг. В данный момент шейпинг реализован на IMQ, трафик заворачивается правилами iptables:

-A PREROUTING -i ppp+ -j IMQ --todev 0 (imq0, исход)

-A POSTROUTING -o ppp+ -j IMQ --todev 1 (imq1, вход)

В инет смотрит eth0, в локалку eth1 с десятком виланов.

IMHO схема избыточна, вместо imq можно применить ifb, а одно из направлений вообще шейпить на интерфейсе. Вот на этой мысли и остановился, ткните пальцем где почитать или объясните, что можно резать на внешнем интерфейсе, а что заворачивать с ppp на виртуальный ifb0 и есть ли какая-либо разница между imq и ifb на уровне фильтров и правил tc кроме названия интерфейса?

[KaYot 3 709]

Неужели ни у кого не было подобного этапа жизни, переход с imq на ifb?

Пока зрею к варианту собрать отдельную машину с 3x2 сетевых интерфейсов(с заделом на 2.5-3Г трафика) и шейпить собственно на bond0/bond1 этой машины, а NASы пусть тупо терминируют ppp и больше ничего.

[harry390625 0]

Возникла похожая задача - тоже пытаюсь написать шейпер для ppp+ интерфесов с помощью ifb. Поделитесь пожалуйста своими решениями данного вопроса

[keshaLG 5]

Простите, а можно узнать.

Чем обычный шейпер НТВ/ingress на ppp+ интерфейсах не устраивает?

[twg 871]

IMQ гибче в использовании. в IFB нужно заворачивать с ингресс. А в IMQ можно завернуть все что захочеш в iptables.

Я же для pptp/pppoe не использую ни одного ни другого. При подъёме юзерского ппп на него делается tbf по его скорости по тарифу. Аплоад тоже tbf на ингресс. И никакого шейпинга по видам траффика. ИМХО самая безизбыточная схема ))

[harry390625 0]

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

[twg 871]

Ну в таком случае IMQ предпочтительнее ИМХО. Одной строчкой а iptables завернул все ппп в этот интерфейс, аплинк также можно завернуть в этот же IMQ, или ещё 1 сделать. 1 или 2 интерфейса IMQ, думаю, не столь критично для системы. а там уже HTB по классам. Вот HTB наверное будет кушать ресурс.

[harry390625 0]

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

[twg 871]

Средствами ifb такую задачу вполне можно реализовать. Все заворачивается в ifb, а на нем тотже htb. Но imq ИМХО проще для понимания )) и гибче в использовании. Допустим 1 imq мир, во второй imq неньку. С ifb так уже не получится.

[harry390625 0]

Разделять мир и ua не нужно, поэтому вполне устроит ifb.

Помогите тогда с реализацией, а то второй день бъюсь и не пойму где туплю... Нашел такой пример (eth0 - инет, eth2 - локалка), то тут отлавливают пользователей по айпи, у меня же пользователи подключаются по ВПН (pptp), поэтому по айпи отловить их не получается. Как быть?

#!/bin/sh

modprobe ifb
ip link set dev ifb0 up
ip addr add 172.16.10.1/32 dev ifb0

tc qdisc del dev ifb0 root      2> /dev/null > /dev/null
tc qdisc del dev ifb0 ingress   2> /dev/null > /dev/null
tc qdisc del dev eth0 root      2> /dev/null > /dev/null
tc qdisc del dev eth0 ingress   2> /dev/null > /dev/null
tc qdisc del dev eth2 root      2> /dev/null > /dev/null
tc qdisc del dev eth2 ingress   2> /dev/null > /dev/null

tc qdisc add dev eth0 ingress handle ffff:
tc filter add dev eth0 parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

tc qdisc add dev ifb0 root handle 1: htb default 20

tc class add dev ifb0 parent 1: classid 1:1 htb rate 2048kbit ceil 2048kbit burst 15k
tc qdisc add dev ifb0 parent 1:1 handle 2: sfq limit 1024 perturb 15

tc class add dev ifb0 parent 1:1 classid 1:20 htb rate 512kbit ceil 1512kbit burst 15k prio 5
tc qdisc add dev ifb0 parent 1:20 handle 20: sfq limit 128 perturb 15
tc class add dev ifb0 parent 1:1 classid 1:30 htb rate 512kbit ceil 512kbit burst 15k prio 4
tc qdisc add dev ifb0 parent 1:30 handle 30: sfq limit 128 perturb 15
tc class add dev ifb0 parent 1:1 classid 1:40 htb rate 256kbit ceil 256kbit burst 1k prio 3
tc qdisc add dev ifb0 parent 1:40 handle 40: sfq limit 128 perturb 15

tc filter add dev ifb0 parent 1: protocol all prio 2 u32 match ip dst 10.0.0.7/32 flowid 1:40

[Гайджин 574]

При подъёме юзерского ппп на него делается tbf по его скорости по тарифу. Аплоад тоже tbf на ингресс.

Про аплоад, ингресс и tbf подробней плиз.

[twg 871]

Разделять мир и ua не нужно, поэтому вполне устроит ifb.

Помогите тогда с реализацией, а то второй день бъюсь и не пойму где туплю... Нашел такой пример (eth0 - инет, eth2 - локалка), то тут отлавливают пользователей по айпи, у меня же пользователи подключаются по ВПН (pptp), поэтому по айпи отловить их не получается. Как быть?

 

#!/bin/sh

 

modprobe ifb

ip link set dev ifb0 up

ip addr add 172.16.10.1/32 dev ifb0

 

tc qdisc del dev ifb0 root 2> /dev/null > /dev/null

tc qdisc del dev ifb0 ingress 2> /dev/null > /dev/null

tc qdisc del dev eth0 root 2> /dev/null > /dev/null

tc qdisc del dev eth0 ingress 2> /dev/null > /dev/null

tc qdisc del dev eth2 root 2> /dev/null > /dev/null

tc qdisc del dev eth2 ingress 2> /dev/null > /dev/null

 

tc qdisc add dev eth0 ingress handle ffff:

tc filter add dev eth0 parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

tc qdisc add dev ifb0 root handle 1: htb default 20

 

tc class add dev ifb0 parent 1: classid 1:1 htb rate 2048kbit ceil 2048kbit burst 15k

tc qdisc add dev ifb0 parent 1:1 handle 2: sfq limit 1024 perturb 15

 

tc class add dev ifb0 parent 1:1 classid 1:20 htb rate 512kbit ceil 1512kbit burst 15k prio 5

tc qdisc add dev ifb0 parent 1:20 handle 20: sfq limit 128 perturb 15

tc class add dev ifb0 parent 1:1 classid 1:30 htb rate 512kbit ceil 512kbit burst 15k prio 4

tc qdisc add dev ifb0 parent 1:30 handle 30: sfq limit 128 perturb 15

tc class add dev ifb0 parent 1:1 classid 1:40 htb rate 256kbit ceil 256kbit burst 1k prio 3

tc qdisc add dev ifb0 parent 1:40 handle 40: sfq limit 128 perturb 15

 

tc filter add dev ifb0 parent 1: protocol all prio 2 u32 match ip dst 10.0.0.7/32 flowid 1:40

 

 

Ловить нужно не на eth0 а на ппп юзера. При подьеме, из /etc/ppp/ip-up береш $iface, потом

"$TC" qdisc add dev $iface handle ffff: ingress

"$TC" filter add dev $iface parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

[twg 871]

При подъёме юзерского ппп на него делается tbf по его скорости по тарифу. Аплоад тоже tbf на ингресс.

Про аплоад, ингресс и tbf подробней плиз.

 

"$TC" qdisc add dev $iface handle ffff: ingress                                                                                                                      
"$TC" filter add dev $iface parent ffff: protocol ip prio 50 u32 match ip dst 0.0.0.0/0 police rate ${bandw_up}kbit burst 10k drop flowid ffff: 

[harry390625 0]

Пробовал и так, но по айпи (впновский айпи клиента - 10.0.0.7) все равно не отлавливает:

tc filter add dev ifb0 parent 1: protocol all prio 2 u32 match ip dst 10.0.0.7/32 flowid 1:40

А tcpdump -i ifb0 выдает следующее:

16:57:43.156952 00:28:d2:23:40:00 (oui Unknown) > c0:a8:00:21:45:00 (oui Unknown), ethertype Unknown (0x8006), length 44:
       0x0000:  006d 0a00 0007 5e64 bfd4 0624 0050 3070  .m....^d...$.P0p
       0x0010:  3fbd 627f 5f64 5010 ffff 4f10 0000       ?.b._dP...O...

16:57:43.156955 00:28:d2:24:40:00 (oui Unknown) > c0:a8:00:21:45:00 (oui Unknown), ethertype Unknown (0x8006), length 44:
       0x0000:  006c 0a00 0007 5e64 bfd4 0621 0050 2e65  .l....^d...!.P.e
       0x0010:  d4d7 6348 0a12 5010 fd8c 1300 0000       ..cH..P.......

[twg 871]

хм вообщето да )) вылавливать нужно с eth0 для юзера довнлоад. А аплоад юзера с его интерфейса.. Сори я чуть ошибся. )

[harry390625 0]

а если отлавливать на eth0, то не по src, не по dst клиентский айпи мы не увидим... метки через iptables для ifb не работают. Возникает вопрос - как идентифицировать пользователя?

[twg 871]

Разделять мир и ua не нужно, поэтому вполне устроит ifb.

Помогите тогда с реализацией, а то второй день бъюсь и не пойму где туплю... Нашел такой пример (eth0 - инет, eth2 - локалка), то тут отлавливают пользователей по айпи, у меня же пользователи подключаются по ВПН (pptp), поэтому по айпи отловить их не получается. Как быть?

 

#!/bin/sh

 

modprobe ifb

ip link set dev ifb0 up

ip addr add 172.16.10.1/32 dev ifb0

 

tc qdisc del dev ifb0 root 2> /dev/null > /dev/null

tc qdisc del dev ifb0 ingress 2> /dev/null > /dev/null

tc qdisc del dev eth0 root 2> /dev/null > /dev/null

tc qdisc del dev eth0 ingress 2> /dev/null > /dev/null

tc qdisc del dev eth2 root 2> /dev/null > /dev/null

tc qdisc del dev eth2 ingress 2> /dev/null > /dev/null

 

tc qdisc add dev eth0 ingress handle ffff:

tc filter add dev eth0 parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

 

tc qdisc add dev ifb0 root handle 1: htb default 20

 

tc class add dev ifb0 parent 1: classid 1:1 htb rate 2048kbit ceil 2048kbit burst 15k

tc qdisc add dev ifb0 parent 1:1 handle 2: sfq limit 1024 perturb 15

 

tc class add dev ifb0 parent 1:1 classid 1:20 htb rate 512kbit ceil 1512kbit burst 15k prio 5

tc qdisc add dev ifb0 parent 1:20 handle 20: sfq limit 128 perturb 15

tc class add dev ifb0 parent 1:1 classid 1:30 htb rate 512kbit ceil 512kbit burst 15k prio 4

tc qdisc add dev ifb0 parent 1:30 handle 30: sfq limit 128 perturb 15

tc class add dev ifb0 parent 1:1 classid 1:40 htb rate 256kbit ceil 256kbit burst 1k prio 3

tc qdisc add dev ifb0 parent 1:40 handle 40: sfq limit 128 perturb 15

 

tc filter add dev ifb0 parent 1: protocol all prio 2 u32 match ip dst 10.0.0.7/32 flowid 1:40

 

Красная строчка тут не лишняя?

 

вот я и говорю, что imq попроще. ))

[harry390625 0]

((

так не хотелось патчить... помучаю еще ifb

спасибо за обсуждение, может еще кто что подскажет

[Гайджин 574]

"$TC" qdisc add dev $iface handle ffff: ingress                                                                                                                      
"$TC" filter add dev $iface parent ffff: protocol ip prio 50 u32 match ip dst 0.0.0.0/0 police rate ${bandw_up}kbit burst 10k drop flowid ffff:

Гы - Вы не находите что qdisc TBF это несколько иное, т.е. не то что Вы написали? Ибо это обычный полисер.

[Гайджин 574]

((

так не хотелось патчить... помучаю еще ifb

спасибо за обсуждение, может еще кто что подскажет

Во простой пример, для случая когда каждому pppXX интерфейсу соответствует свой ifbXX интерфейс.

Я понимаю что это несколько маразматично, но если сервер держит на себе до 1000 ppp интерфейсов, то такой подход может быть оправдан.

И в конечном итоге никто не мешает свернуть весь трафик (входящий и исходящий, при помощи action mirred redirect) со всех ppp интерфейсов на два ifb интерфейса и на них построить структуру классов htb, применив для ретушированные фильтры с u32.

 

Но есть одно НО - если сервер еще и натит, то с IFB ничего не выйдет. Восходящий от клиента трафик заматчить не удастся.

 

tc qdisc del dev ppp0 root
tc qdisc del dev ppp0 ingress
ip link set dev ifb0 up
tc qdisc del dev ifb0 root

tc qdisc add dev ppp0 root handle 1: htb r2q 10
tc class add dev ppp0 parent 1: classid 1:1 htb rate 1080Kbit prio 1 quantum 1514

tc class add dev ppp0 parent 1:1 classid 1:101 htb rate 1079Kbit ceil 1080Kbit prio 1 quantum 1514
tc class add dev ppp0 parent 1:1 classid 1:102 htb rate 1Kbit ceil 1080Kbit prio 7 quantum 1514
tc qdisc add dev ppp0 parent 1:101 sfq perturb 10
tc qdisc add dev ppp0 parent 1:102 sfq perturb 10
tc filter add dev ppp0 parent 1: protocol ip u32 match ip src 0.0.0.0/0 flowid 1:102
tc filter add dev ppp0 parent 1: protocol ip u32 match ip tos 0x10 0xff flowid 1:101
tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 1 0xff flowid 1:101
tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 17 0xff match ip sport 53 0xffff flowid 1:101
tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:101



tc qdisc add dev ppp0 handle ffff: ingress
tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid ffff: action mirred egress redirect dev ifb0 1>/dev/null 2>/dev/null

tc qdisc add dev ifb0 root handle 1: htb r2q 10
tc class add dev ifb0 parent 1: classid 1:1 htb rate 1080Kbit prio 1 quantum 1514

tc class add dev ifb0 parent 1:1 classid 1:101 htb rate 1079Kbit ceil 1080Kbit prio 1 quantum 1514
tc class add dev ifb0 parent 1:1 classid 1:102 htb rate 1Kbit ceil 1080Kbit prio 7 quantum 1514
tc qdisc add dev ifb0 parent 1:101 sfq perturb 10
tc qdisc add dev ifb0 parent 1:102 sfq perturb 10
tc filter add dev ifb0 parent 1: protocol ip u32 match ip dst 0.0.0.0/0 flowid 1:102
tc filter add dev ifb0 parent 1: protocol ip u32 match ip tos 0x10 0xff flowid 1:101
tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 1 0xff flowid 1:101
tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 17 0xff match ip dport 53 0xffff flowid 1:101
tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:101

[harry390625 0]

jugernault, заворачиваю я интерфейсы ppp+ на ifb0, строю на нем структуру классов htb - а как назначить одному клиенту 101 класс, а другому 102?

[Гайджин 574]

jugernault, заворачиваю я интерфейсы ppp+ на ifb0, строю на нем структуру классов htb - а как назначить одному клиенту 101 класс, а другому 102?

Фильтрами по u32.

[harry390625 0]

jugernault, не догоняю я что-то... Можно пример или ссылку где почитать можно?

[Гайджин 574]

jugernault, не догоняю я что-то... Можно пример или ссылку где почитать можно?

Чего Вы не догоняете?

 

Того, как матчить по u32? - Так просто, но не эффективно:

tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.1 flowid 1:101

tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.2 flowid 1:102

tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.3 flowid 1:104

 

Или как пользоваться хешированым фильтерингом в tc? - Так тоже не сложно найти, гуглите по фразе "tc hash table". Масса примеров найдется.

[harry390625 0]

jugernault, если я заворачиваю ppp+ интерфейсы на ifb0, то данные правила не срабатывают:

tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.1 flowid 1:101
tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.2 flowid 1:102
tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.3 flowid 1:104

 

Я об этом уже писал тут в данной теме. Думал вы предлагаете какое-то другое решение...