задача - есть две сети класса B (на разных сетевухах), надо повесить для каждого ip
шейпер (для адресов одной сети 64kb/s на каждый, для другой - 128kb/s) шейперы тупые - tbf
втупую получается 130000+ правил, u32 не вкурил ((
>задача - есть две сети класса B (на разных сетевухах), надо повесить
>для каждого ip
>шейпер (для адресов одной сети 64kb/s на каждый, для другой -
>128kb/s) шейперы тупые - tbf
>втупую получается 130000+ правил, u32 не вкурил ((
Использовать IPMARK target из pom-ng.Не понял - две сети - это два интерфейса? Если так то при чем тут tbf?
>>задача - есть две сети класса B (на разных сетевухах), надо повесить
>>для каждого ip
>>шейпер (для адресов одной сети 64kb/s на каждый, для другой -
>>128kb/s) шейперы тупые - tbf
>>втупую получается 130000+ правил, u32 не вкурил ((
>
>
>Использовать IPMARK target из pom-ng.
>
>Не понял - две сети - это два интерфейса? Если
>так то при чем тут tbf?
шейперы стоят, но для каждого ip из сети получаются записи вида/sbin/tc class add dev eth0 parent 1: classid 1:26 cbq bandwidth 100Mbit rate 64Kbit weight 2Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded
/sbin/tc qdisc add dev eth0 parent 1:26 handle 26 tbf rate 64Kbit buffer 30kb limit 15Kb mtu 1500
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 172.x.x.x classid 1:26в конечном итоге - 65000 правил для каждой сети класса B, что не есть хорошо с точки зрения производительности. Интересует способ сокращения количества цепочек (в частности через хеши )
>/sbin/tc class add dev eth0 parent 1: classid 1:26 cbq bandwidth 100Mbit
>rate 64Kbit weight 2Kbit prio 5 allot 1514 cell 8 maxburst
>20 avpkt 1000 bounded
>/sbin/tc qdisc add dev eth0 parent 1:26 handle 26 tbf rate 64Kbit
>buffer 30kb limit 15Kb mtu 1500
>/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32
>match ip dst 172.x.x.x classid 1:26
>
>в конечном итоге - 65000 правил для каждой сети класса B, что
>не есть хорошо с точки зрения производительности. Интересует способ сокращения количества
>цепочек (в частности через хеши )
Зачем cbq+tbf Уж лучше только htb. Что-то типа (если ip eth0 172.x.0.1)
#Общий один фильтр
tc qdisc add dev eth0 root handle 1: htb default ffff r2q 1
tc class add dev eth0 parent 1: classid 1:1 htb rate $[65533*64]kbit
tc class add dev eth0 parent 1:ffff classid 1:0326 htb rate 64Kbit
tc qdisc add dev eth0 parent 1:ffff handle ffff: bfifo limit 15000
tc filter add dev eth0 parent 1:0 protocol ip fw
iptables -t mangle -A POSTROUTING -o eth0 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000# Для каждого ip из диапозона 172.x.0.0/16 - в данном случае для 172.x.10.38
tc class add dev eth0 parent 1:1 classid 1:0a26 htb rate 64Kbit quantum $mtu_of_eth0
tc qdisc add dev eth0 parent 1:0a26 handle 0a26: bfifo limit 15000
Только вообще так будет возможно плоховато-работать в любом случае - кривое это решение. Могут быть относительно большие задержки. Имеет смысл добавить quantum $mtu_of_eth0
Точнееtc qdisc add dev eth0 root handle 1: htb default ffff r2q 1
tc class add dev eth0 parent 1: classid 1:1 htb rate $[65533*64]kbit
tc class add dev eth0 parent 1:1 classid 1:ffff htb rate 64Kbit
tc qdisc add dev eth0 parent 1:ffff handle ffff: bfifo limit 15000
#Общий один фильтр
tc filter add dev eth0 parent 1:0 protocol ip fw
iptables -t mangle -A POSTROUTING -o eth0 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000# Для каждого ip из диапозона 172.x.0.0/16 - в данном случае для 172.x.10.38
tc class add dev eth0 parent 1:1 classid 1:0a26 htb rate 64Kbit quantum $mtu_of_eth0
tc qdisc add dev eth0 parent 1:0a26 handle 0a26: bfifo limit 15000
Ну что, у кого-нибудь сервак реально тянет столько правил? Какой CPU usage?