From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SeRKw-0006Pz-OC for garchives@archives.gentoo.org; Tue, 12 Jun 2012 13:40:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1C2B2E0329; Tue, 12 Jun 2012 13:40:33 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 1DC85E0444 for ; Tue, 12 Jun 2012 13:37:55 +0000 (UTC) Received: by obbuo19 with SMTP id uo19so9210355obb.40 for ; Tue, 12 Jun 2012 06:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=82UM1ZRGRek5DBn9/1Bq6JX39ZUvRzjlBOmoibziS0E=; b=Wp3j3fp8mkM8j/aqy5yu/ed6VhnIvjsfJ7OZTRC9Oc3UIQ9iOxDCbfwi86WCRlTWE4 mXErP1kTvoTUsjWvcbfVW+Repk2UdxfcG7Xg7t9pHxKehjtmmM5rh+cR8NLAlp0ZpB1d 3Tp9tn1G3FB4J1feLjlb2vfKB9XHdVhsn6qqlcxpIHEYq9I0JQacNpbW41ijR9YSzlfR jI8wq3jpNzvmyupUGtVjx8tuTAvaxQvK0/Qt6c4mr0Ya09qwF2u7VrXPT5qCLuOXcOjN 52ANZtl3g2f002Qto0H5NDuhpwRmyENXDNHMStRdfmarMi8cMvTMjK88hS33F2yo2ao4 Y9ng== Received: by 10.182.36.102 with SMTP id p6mr20322156obj.77.1339508275316; Tue, 12 Jun 2012 06:37:55 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.182.232.36 with HTTP; Tue, 12 Jun 2012 06:37:34 -0700 (PDT) In-Reply-To: References: <5bd4ba758840149a5dabfaf4515eb997.squirrel@www.antarean.org> From: Datty Date: Tue, 12 Jun 2012 14:37:34 +0100 Message-ID: Subject: Re: [gentoo-user] Traffic shaping - downstream data To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=f46d04451795ec894304c246925b X-Archives-Salt: 933c1f1e-9713-4810-b1ba-84783c44984d X-Archives-Hash: 663a42adab149e128149f0a9fa3b2639 --f46d04451795ec894304c246925b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol wrote: > More detail later...but make sure your vpn link is not TCP. UDP, fine, > IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly > traffic problems. > On Jun 12, 2012 8:59 AM, "Datty" wrote: > >> >> On Tue, Jun 12, 2012 at 9:58 AM, J. Roeleveld wrote: >> >>> On Mon, June 11, 2012 5:27 pm, Datty wrote: >>> > Hi all >>> > >>> > I'm looking for some help setting up traffic shaping on my internet >>> > connection. I have a bit of an odd setup in that I run a remote VPN >>> server >>> > that all of my traffic is pushed through and out on to the internet. >>> As I >>> > understand generally it isn't possible to shape incoming traffic but >>> as I >>> > have control of the VPN server which pushes the traffic to me I >>> wondered >>> > if >>> > it was possible to implement something on that side? No traffic other >>> than >>> > the VPN tunnel goes out of my home connection. >>> > >>> > I'm trying to do this because I have a service running on one of my >>> home >>> > machines that requires around 5kbps constantly with low latency >>> (<200ms), >>> > but as my home connection is 750kbps it gets saturated very quickly >>> > causing >>> > huge spikes in latency. Does anyone have any ideas as to how I could >>> > achieve this? Generally any pointers at all would be greatly >>> appreciated. >>> >>> If VPN is the only traffic to/from your home, eg. using your internet >>> connection and you control the VPN-server on the other side, you could >>> limit the "upstream" of the remote server to your home. >>> >>> > Thanks for your time >>> > >>> > Oliver >>> > >>> >>> >>> -- >>> Joost >>> >>> >>> Thanks that makes total sense. I was looking at it backwards, not >> thinking that I could apply the same upstream limit to my VPN server. >> A bit of background/my aims - The vpn interface is 100mbps, I want >> everybody but me on the VPN to be able to use up to that speed, but for >> traffic sent to 192.168.50.0/24 to be limited to 750kbps, with 700kbps >> of that for normal traffic and 50kbps for my tcp traffic from port 9999. >> >> Based on that do the following rules make sense? >> >> tc qdisc add dev tap0 root handle 1: htb default 12 -- Set the interface >> to be handle 1 and default traffic to be in class 1:12 >> tc class add dev tap0 parent 1: classid 1:1 htb rate 100mbps ceil 100mbps >> -- Set 100mbps to be available to all classes overall >> tc class add dev tap0 parent 1:1 classid 1:12 htb rate 100mbps ceil >> 100mbps -- Set 100mbps to be available to all people on the vpn >> tc class add dev tap0 parent 1:1 classid 1:15 htb rate 750kbps ceil >> 750kbps -- To be applied to all traffic from my home network >> tc class add dev tap0 parent 1:15 classid 1:16 htb rate 700kbps ceil >> 700kbps -- To be applied to all traffic other than special on home network >> tc class add dev tap0 parent 1:15 classid 1:17 htb rate 50kbps ceil >> 50kbps -- To be applied to special traffic on home network >> tc qdisc add dev $modemif parent 1:15 handle 20: sfq perturb 10 -- I >> understand this to prevent high bandwidth traffic in a class from filling >> up the whole of the class bandwidth and allow fair sharing. Is this >> right/needed? >> tc qdisc add dev $modemif parent 1:12 handle 20: sfq perturb 10 >> >> iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.0/24 -p tcp >> --sport 9999 -j CLASSIFY --set-class 1:17 >> iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.4/24 -j CLASSIFY >> --set-class 1:16 >> iptables -t mangle -A POSTROUTING -o tap0 -j CLASSIFY --set-class 1:12 >> >> >> Thanks again for your help >> >> Oliver >> > Ah it is TCP at the moment. Not something I could change too easily either. Is it possible to work around or is it not worth fighting with? --f46d04451795ec894304c246925b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <m= ikemol@gmail.com> wrote:

More detail later...but make sure your vpn link is not TCP. UDP, fine, I= P-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traff= ic problems.

On Jun 12, 2012 8:59 AM, "Datty" <<= a href=3D"mailto:datty.wtb@gmail.com" target=3D"_blank">datty.wtb@gmail.com= > wrote:

On Tue, Jun 12, 2012 at 9:58 AM, J. Roelevel= d <joost@antarean.org> wrote:
On Mon, June 11, 2012 5:27 pm, Datty wrote:
> Hi all
>
> I'm looking for some help setting up traffic shaping on my interne= t
> connection. I have a bit of an odd setup in that I run a remote VPN se= rver
> that all of my traffic is pushed through and out on to the internet. A= s I
> understand generally it isn't possible to shape incoming traffic b= ut as I
> have control of the VPN server which pushes the traffic to me I wonder= ed
> if
> it was possible to implement something on that side? No traffic other = than
> the VPN tunnel goes out of my home connection.
>
> I'm trying to do this because I have a service running on one of m= y home
> machines that requires around 5kbps constantly with low latency (<2= 00ms),
> but as my home connection is 750kbps it gets saturated very quickly > causing
> huge spikes in latency. Does anyone have any ideas as to how I could > achieve this? Generally any pointers at all would be greatly appreciat= ed.

If VPN is the only traffic to/from your home, eg. using your in= ternet
connection and you control the VPN-server on the other side, you could
limit the "upstream" of the remote server to your home.

> Thanks for your time
>
> Oliver
>


--
Joost


Thanks that makes total sense. I was looki= ng at it backwards, not thinking that I could apply the same upstream limit= to my VPN server.
A bit of background/my aims - The vpn interface is 1= 00mbps, I want everybody but me on the VPN to be able to use up to that spe= ed, but for traffic sent to 192.168.50.0/24 to be limited to 750kbps, with 700kbps of that fo= r normal traffic and 50kbps for my tcp traffic from port 9999.=A0

Based on that do the following rules make sense?= =A0

tc qdisc add dev tap0 root handle 1: htb = default 12 -- Set the interface to be handle 1 and default traffic to be in= class 1:12
tc class add dev tap0 parent 1: classid 1:1 htb rate 100mbps ceil 100m= bps -- Set 100mbps to be available to all classes overall
tc clas= s add dev tap0 parent 1:1 classid 1:12 htb rate 100mbps ceil 100mbps -- Set= 100mbps to be available to all people on the vpn
tc class add dev tap0 parent 1:1 classid 1:15 htb rate 750kbps ceil 75= 0kbps -- To be applied to all traffic from my home network
tc cla= ss add dev tap0 parent 1:15 classid 1:16 htb rate 700kbps ceil 700kbps -- T= o be applied to all traffic other than special on home network
tc class add dev tap0 parent 1:15 classid 1:17 htb rate 50kbps ceil 50= kbps -- To be applied to special traffic on home network
tc = qdisc add dev $modemif parent 1:15 handle 20: sfq perturb 10 -- I understan= d this to prevent high bandwidth traffic in a class from filling up the who= le of the class bandwidth and allow fair sharing. Is this right/needed?
tc qdisc add dev $modemif parent 1:12 handle 20: sfq perturb 10=A0

iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.0/24 -p t= cp --sport 9999 -j CLASSIFY --set-class 1:17
iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.4/24 -j CLASSIFY --set-class 1:1= 6
iptables -t mangle -A POSTROUTING -o tap0 -j CLASSIFY --set-cla= ss 1:12


Thanks again for your help
Oliver

Ah it is TCP at the moment. N= ot something I could change too easily either. Is it possible to work aroun= d or is it not worth fighting with? --f46d04451795ec894304c246925b--