On Fri, Jan 9, 2015 at 12:49 AM, Gonçalo Luiz <goncalo.luiz@xxxxxxxxx> wrote: > Hi, > > Thank you for your replies. My own answer is to try to *first* - offer fair and aqm'd service to all traffic exiting and entering the external interface with something like sqm-scripts + fq_codel. That fixes a lot. After that you can try deprioritizing certain kinds of traffic, and prioritizing a very few kinds of traffic. > > Russel's suggestion indeed works but is not quite what I'm aiming for. > While respecting the TOS header is often a good idea, what I really > need is to pivot the QoS decision in the source IP as some source IPs > will have very low priority despite the TOS header. The way sqm-scripts does it is to fw or TOS mark based on whatever you want and then toss that into one of three prioritized bins (priority, best effort, and background). Dealing with vpn traffic is harder, unless you want to fit it into one of those 3 bins. Recently I started work on finding better ways to FQ vpn traffic, but it involves changes to the underlying daemons and protocols. > > I can do this by shaping the tunnel ingress (by means of shaping an > IFB egress that mirrors it) along (i.e. on the same HTB qdisc) with > the bridge egress (also mirrored to the same IFB). The only thing I'm > missing is how throw into the (same IFB) mix the locally generated > packages. > > A workaround would be to shape eth1 egress with a simple PRIO (work > connserving) assigning whatever comes out of br0 and the tunnel (i.e. > what has already been shaped into a given bit rate) lower priority > than everything else (i.e. the locally generated traffic) as usually > on a router whatever generates traffic has super priority (it's > usually remote admin work, ssh for example) and not services or user > traffic. > > How does that sound ? > > G. > Gonçalo Luiz > > > On 9 January 2015 at 01:05, Raul Dias <raul@xxxxxxxxxxx> wrote: >> That's very close to what I had to do with TINC in a similar scenery. >> >> -rsd >> >> On 8 Jan 2015 20:12, "I-Strong, Russell J" <Russell.J.Strong@xxxxxxxxxx> >> wrote: >>> >>> Hi, >>> >>> I've never tried this with openvpn, but there is a --passtos option which >>> sets the TOS field of the tunnel packet to what the payload's TOS is. I've >>> done this sort of thing before with GRE tunnels. They have an inherit >>> option. >>> >>> Russell >>> >>> -----Original Message----- >>> From: lartc-owner@xxxxxxxxxxxxxxx [mailto:lartc-owner@xxxxxxxxxxxxxxx] On >>> Behalf Of Gonçalo Luiz >>> Sent: Thursday, 8 January 2015 7:40 PM >>> To: lartc@xxxxxxxxxxxxxxx >>> Subject: Help setting up home router >>> >>> Hi, >>> >>> I've been reading all the material I could get my hands on, but there is a >>> small detail I seem unable to get my head around. Let me show you my setup >>> first >>> >>> 1 linux PC (router) with two physical NICs: eth0 (inner facing) and >>> eth1 (outer facing) >>> many clients behind a switch to where eth0 connects to three network >>> namespaces in the router, whose veths bridge with eth0 in br0 one OpenVPN >>> VPN running on the router, through which I'm sending some traffic >>> originating from a few source IPs. Let's call it tun0 >>> >>> what I want to do: apply traffic control to the outer facing, controlling >>> *all* the outgoing traffic. For simplicity let's assume I want to apply the >>> rules based solely on the source IP >>> >>> my first instinct was to configure the qdiscs on eth1 egress. Seems to me >>> that this is the only way I can also apply the control to packets >>> originating in the router as they go straight away to the exit interface >>> (eth1). >>> >>> The problem I'm facing is that the traffic that goes through tun0 presents >>> itself to eth1, obviously, already compressed and without the real source IP >>> information (can come from any of the clients or network namespaces on the >>> router) and therefore I cannot infer what class should assign to it. In >>> practice, VPN turns all it's traffic opaque and I cannot treat it >>> differently depending on the client originating it. >>> >>> my second instinct was to shape tun0 ingress (through an IFB) along with >>> eth0 egress by redirecting both to an IFB and shapping it there. >>> Sadly this leaves traffic originating in the router itself out. >>> >>> lastly I've tried to add an iptables mark to the packets that are going >>> through tun0 before they go through the compressing process but it seems to >>> be lost when they come out of the other side of it. If they were not perhaps >>> I could apply traffic control based on iptables marks instead of source IPs >>> if I marked all the packets as soon as they land on the router or are >>> originated in the router. >>> >>> Any ideas? I fell this must be possible but am running out of ideas. >>> >>> Thanks. >>> >>> Gonçalo >>> >>> >>> Gonçalo Luiz >>> -- >>> To unsubscribe from this list: send the line "unsubscribe lartc" in the >>> body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at >>> http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe lartc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
