please, help, i have build vpn server (suse 9 + poptop), i have managed to implement tc htb in ip-up script, but every client has own ppp interface (ppp0, ppp1, ppp2...), and my idea is to share available bandwidth, not to limit connection, how to build root tc rule, when I have more then one interface?... please any one width experiance regards _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Hi mail.cat-net.co.yu, Because ppp traffic is over your real network link, you can control ppp traffic over that physic device. But I think it have limitation, because with this way you can''t look into the ppp layer and differential TCP/IP applications encapsulated in ppp layer. On Wed, 6 Apr 2005 00:44:55 +0200, "mail.cat-net.co.yu" <hiphin@cat-net.co.yu> wrote:> please, help, i have build vpn server (suse 9 + poptop), i have managed to implement tc htb in ip-up script, but every client has own ppp interface (ppp0, ppp1, ppp2...), and my idea is to share available bandwidth, not to limit connection, > > how to build root tc rule, when I have more then one interface?... please any one width experiance > > regards-- lark
Hi Wang,...>Because ppp traffic is over your real network link, you can control ppp >traffic over that physic device. But I think it have limitation, because >with this way you can''t look into the ppp layer and differential >TCP/IP applications encapsulated in ppp layeryes, that is my question, if I control eth0 only, I can not have per user limmiting... can I do something simple like this: /sbin/tc qdisc add dev eth0 root handle 1: htb default 10 /sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit /sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 32kbit ceil \ 256kbit prio 1 burst 64kbit cburst 96kbit /sbin/tc filter add dev ppp0 protocol ip parent 1:0 prio 1 u32 match ip dest \ $REMOTEIP0 folow 1:10 /sbin/tc class add dev ppp1 parent 1:1 classid 1:20 htb rate 32kbit ceil \ 256kbit prio 1 burst 64kbit cburst 96kbit /sbin/tc filter add dev ppp1 protocol ip parent 1:0 prio 1 u32 match ip dest \ $REMOTEIP1 folow 1:20 ... or IMQ must be involved... there must be way, to do bandwidth sharing throught vpn-ppp connections thanks _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Hi hiphin, It seems that your network link is eth0. Then tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 32kbit ceil 256kbit prio 1 Then you can use tc filter to classify all pptp traffic to 1:2. You don''t need to specify different class for every ppp connection. But the drawback is no fairness. Not all ppp connections can get 32kbit assured if they want. If you need guaranteed bandwidth for each ppp connection, try my per flow control queue patch. You can find it in list''s archive. On Wed, 6 Apr 2005 10:08:40 +0200, "hiphin" <hiphin@cat-net.co.yu> wrote:> Hi Wang,... > > >Because ppp traffic is over your real network link, you can control ppp > >traffic over that physic device. But I think it have limitation, because > >with this way you can''t look into the ppp layer and differential > >TCP/IP applications encapsulated in ppp layer > > yes, that is my question, if I control eth0 only, I can not have per user > limmiting... > > can I do something simple like this: > > /sbin/tc qdisc add dev eth0 root handle 1: htb default 10 > /sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit > > /sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 32kbit ceil \ > 256kbit prio 1 burst 64kbit cburst 96kbit > /sbin/tc filter add dev ppp0 protocol ip parent 1:0 prio 1 u32 match ip dest > \ > $REMOTEIP0 folow 1:10 > > /sbin/tc class add dev ppp1 parent 1:1 classid 1:20 htb rate 32kbit ceil \ > 256kbit prio 1 burst 64kbit cburst 96kbit > /sbin/tc filter add dev ppp1 protocol ip parent 1:0 prio 1 u32 match ip dest > \ > $REMOTEIP1 folow 1:20 > > ... > > or IMQ must be involved... > there must be way, to do bandwidth sharing throught vpn-ppp connections > > thanks > >-- lark
Hi hiphin, You can also look into ESFQ. Corey Hickey releases esfq for 2.6.12-rc1. On Wed, 06 Apr 2005 16:42:35 +0800, Wang Jian <lark@linux.net.cn> wrote:> Hi hiphin, > > It seems that your network link is eth0. Then > > tc qdisc add dev eth0 root handle 1: htb default 10 > tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit > tc class add dev eth0 parent 1:1 classid 1:2 htb rate 32kbit ceil > 256kbit prio 1 > > Then you can use tc filter to classify all pptp traffic to 1:2. You > don''t need to specify different class for every ppp connection. > > But the drawback is no fairness. Not all ppp connections can get 32kbit > assured if they want. > > If you need guaranteed bandwidth for each ppp connection, try my per > flow control queue patch. You can find it in list''s archive. > > On Wed, 6 Apr 2005 10:08:40 +0200, "hiphin" <hiphin@cat-net.co.yu> wrote: > > > Hi Wang,... > > > > >Because ppp traffic is over your real network link, you can control ppp > > >traffic over that physic device. But I think it have limitation, because > > >with this way you can''t look into the ppp layer and differential > > >TCP/IP applications encapsulated in ppp layer > > > > yes, that is my question, if I control eth0 only, I can not have per user > > limmiting... > > > > can I do something simple like this: > > > > /sbin/tc qdisc add dev eth0 root handle 1: htb default 10 > > /sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit > > > > /sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 32kbit ceil \ > > 256kbit prio 1 burst 64kbit cburst 96kbit > > /sbin/tc filter add dev ppp0 protocol ip parent 1:0 prio 1 u32 match ip dest > > \ > > $REMOTEIP0 folow 1:10 > > > > /sbin/tc class add dev ppp1 parent 1:1 classid 1:20 htb rate 32kbit ceil \ > > 256kbit prio 1 burst 64kbit cburst 96kbit > > /sbin/tc filter add dev ppp1 protocol ip parent 1:0 prio 1 u32 match ip dest > > \ > > $REMOTEIP1 folow 1:20 > > > > ... > > > > or IMQ must be involved... > > there must be way, to do bandwidth sharing throught vpn-ppp connections > > > > thanks > > > > > > > > -- > lark > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc-- lark
Wang, hi, little of thinking and listen what I found logical Q1: Is ppp interface, as only one connection on my real eth0 ? If answare is YES, then simple SFQ on eth0 is good ? ...and main difference SFQ/ESFQ is that SFQ watching connections, and ESFQ watching host IP... Q2: I have 2.4.xx, kernel ESFQ is for 2.6 kernel only ? I need to limit max bandwidth for all users and fair share, do not need to have guaranteed-minimum mathematic is simple: N*user <= 256kbps soo if I have one user on vpn, hi gets 256kbps if I have 2 users on vpn downloading, both is getting max 128kbps and soo on... (this is too simple to be ...) _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Hi hiphin, On Wed, 6 Apr 2005 13:39:40 +0200, "hiphin" <hiphin@cat-net.co.yu> wrote:> Wang, hi, little of thinking and listen what I found logical > > Q1: Is ppp interface, as only one connection on my real eth0 ? > > If answare is YES, then simple SFQ on eth0 is good ? > ...and main difference SFQ/ESFQ is that SFQ watching connections, and ESFQ watching host IP... >You didn''t tell if you use pptp, but I think you use pptp. ppp interface in this case is a peusdo network interface, under it there is IP connection between client and server. So your control the ip connection''s rate, and then you can control the ppp interface. So if you want fairness amongst these interfaces, you can either enforce fairness on connection ( 1 client only has 1 ppp connection) or enforce fairness on host (1 client may have multiple ppp connection but you take the client as one)> Q2: I have 2.4.xx, kernel ESFQ is for 2.6 kernel only ? > > > I need to limit max bandwidth for all users and fair share, do not need to have guaranteed-minimum > > mathematic is simple: N*user <= 256kbps > > soo if I have one user on vpn, hi gets 256kbps > if I have 2 users on vpn downloading, both is getting max 128kbps > and soo on... > > (this is too simple to be ...)I am not familiar with ESFQ. In my test, SFQ doesn''t provide good fairness. ESFQ should have some improvement, I think. Any good implemented fair queue can achieve your goal. -- lark
mail.cat-net.co.yu wrote:> please, help, i have build vpn server (suse 9 + poptop), i have managed to implement tc htb in ip-up script, but every client has own ppp interface (ppp0, ppp1, ppp2...), and my idea is to share available bandwidth, not to limit connection, > > how to build root tc rule, when I have more then one interface?... please any one width experiance > > regardsYou may be able to do it on ethx by marking or classifying in forward/postrouting and hoping the marks survive encapsulation. I''ve never tried so don''t know. If that fails there is also a chance you can do it with IMQ or the dummy device (You will need to build a 2.6 and use a different dummy.c I don''t think the new one is in kernel yet). Andy.
On Wed, 6 Apr 2005 00:44:55 +0200 "mail.cat-net.co.yu" <hiphin@cat-net.co.yu> wrote:> please, help, i have build vpn server (suse 9 + poptop), i have managed to implement tc htb in ip-up script, but every client has own ppp interface (ppp0, ppp1, ppp2...), and my idea is to share available bandwidth, not to limit connection, > > how to build root tc rule, when I have more then one interface?... please any one width experiance > > regardsFew month ago I have such trable too. Now I subscribed to this mail list in hope to resolve problem :). My workaround done in a following way: 1.Difference is that I use pptpd. 2.The idea is to drive all traffic to unlim on a dev eth0, except "gre 1723". The traffic I wish to control I classify as default! 3.The rules a here: /sbin/tc qdisc del dev eth0 root /sbin/tc qdisc add dev eth0 root handle 1 htb default 30 r2q 100 /sbin/tc class add dev eth0 parent 1: classid 1:2 htb rate 100Mbit burst 15K /sbin/tc class add dev eth0 parent 1:2 classid 1:10 htb rate 50Mbit burst 5K prio 5 /sbin/tc qdisc add dev eth0 parent 1:10 handle 10 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 80 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 110 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 110 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 25 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 139 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 139 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 137 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 137 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 138 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 138 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dport 445 0xffff classid 1:10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip sport 445 0xffff classid 1:10 /sbin/tc class add dev eth0 parent 1:2 classid 1:30 htb rate 200Kbit ceil 200Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:30 handle 30 sfq perturb 10 /sbin/tc class add dev eth0 parent 1:30 classid 1:1010 htb rate 10Kbit ceil 80Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:1010 handle 1010 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.19.10 classid 1:1010 /sbin/tc class add dev eth0 parent 1:30 classid 1:1011 htb rate 10Kbit ceil 80Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:1011 handle 1011 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.19.11 classid 1:1011 /sbin/tc class add dev eth0 parent 1:30 classid 1:1012 htb rate 10Kbit ceil 80Kbit prio 5 /sbin/tc qdisc add dev eth0 parent 1:1012 handle 1012 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.19.12 classid 1:1012 And so on. This rules were compiled with help of shapecfg-2.2.12-15asp. Command - htb. But all of this is wrong, only workaround. Month of searching of ability to bridge (brctl), eql, teql etc. - bring nothing. What I have to do :) - C, sources and compiler. I made little change to eql.c making this module only transparent transit device. It''s working... But I have some bugs, and now need help and testing. As I understood - qdisc and class can not apply to more then one device... Is it wrong? Be free for asking more and feeding back. And I am sorry if I have many mistakes in my English. -- With best regards, Pan''ko Alexzender. pankoAA@yandex.ru
Pan''ko Alexzender wrote:> As I understood - qdisc and class can not apply to more then one device... Is it wrong?You can use imq or new dummy (both not in kernel) to shape traffic from more than one device. Andy.
On Wed, Apr 06, 2005 at 01:39:40PM +0200, hiphin wrote:> Q2: I have 2.4.xx, kernel ESFQ is for 2.6 kernel only ?No, I''ve been using it in 2.4. for almost a year: http://www.ssi.bg/~alex/esfq/ And you get unimportant minus points from me for not using google. Bye, Peter Surda (Shurdeek) <shurdeek@routehat.org>, ICQ 10236103, +436505122023 -- It''s not a bug, it''s tradition!