From: Wang Jian <lark@linux.net.cn>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] ppp+vpn+htb
Date: Wed, 06 Apr 2005 08:55:42 +0000 [thread overview]
Message-ID: <20050406165345.027B.LARK@linux.net.cn> (raw)
In-Reply-To: <000a01c53a31$16b0ef30$0200a8c0@racunar02>
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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2005-04-06 8:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 22:44 [LARTC] ppp+vpn+htb mail.cat-net.co.yu
2005-04-06 4:24 ` Wang Jian
2005-04-06 8:08 ` hiphin
2005-04-06 8:42 ` Wang Jian
2005-04-06 8:55 ` Wang Jian [this message]
2005-04-06 11:39 ` hiphin
2005-04-06 12:28 ` Wang Jian
2005-04-06 13:35 ` Andy Furniss
2005-04-10 9:51 ` Peter Surda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050406165345.027B.LARK@linux.net.cn \
--to=lark@linux.net.cn \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.