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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
