QOS on GRE/IPSec tunnel interface

QOS on GRE/IPSec tunnel interface

[Luc Paulin]

Hi, 
I am would like to know if it's possible to do QOS on GRE/IPSec interface ? 
I am would like to do traffic prioritization over a gre/ipsec tunnel that has a lot of video/voip traffic in addition to regular traffic (ftp/http... ) Is this something possible ? 

When I apply the rule on the interface it look like class doesn't do what they are suppose to do. ie(the traffic rate is way too low of the actual real traffic flow) 

Thanx! 

Re: QOS on GRE/IPSec tunnel interface

[Dave Taht]

On Tue, Apr 15, 2014 at 1:09 PM, Luc Paulin <paulinster@ymail.com> wrote:
> Hi,
> I am would like to know if it's possible to do QOS on GRE/IPSec interface ?

fq_codel can peel away a GRE version 0 header and do smart things with
it. IPSec, not so much.

> I am would like to do traffic prioritization over a gre/ipsec tunnel that has a lot of video/voip traffic in addition to regular traffic (ftp/http... ) Is this something possible ?

Difficult. You could for example do some sort of act_mirred thing into
multiple ifb or imq interfaces, and
apply some qos there before encapsulating them in ipsec.

> When I apply the rule on the interface it look like class doesn't do what they are suppose to do. ie(the traffic rate is way too low of the actual real traffic flow)

> Thanx!
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: QOS on GRE/IPSec tunnel interface

[Luc Paulin]

Great thanx for the information... 
Yeah that sound a bit complex as a setup. 

However now I am a bit confuse as I was doing search yesterday I found the following thread. 

http://www.spinics.net/lists/lartc/msg19972.html

The email thread state the the fwmark is should be carry on to the encrypted packet and therefore prioritisation of the encrypted packet should be the same as if it wasn't encrypted. Is this still true?

So as per the thread is I understand correctly if the traffic that come in to an interface is "MARK" correctly then when it goes out on the encrypted tunnel it should be prioritise as it would normally be? 

  -Luc 






On Tuesday, April 15, 2014 4:21:24 PM, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Apr 15, 2014 at 1:09 PM, Luc Paulin <paulinster@ymail.com> wrote:
> Hi,
> I am would like to know if it's possible to do QOS on GRE/IPSec interface ?

fq_codel can peel away a GRE version 0 header and do smart things with
it. IPSec, not so much.

> I am would like to do traffic prioritization over a gre/ipsec tunnel that has a lot of video/voip traffic in addition to regular traffic (ftp/http... ) Is this something possible ?

Difficult. You could for example do some sort of act_mirred thing into
multiple ifb or imq interfaces, and
apply some qos there before encapsulating them in ipsec.


> When I apply the rule on the interface it look like class doesn't do what they are suppose to do. ie(the traffic rate is way too low of the actual real traffic flow)

> Thanx!
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article 

Re: QOS on GRE/IPSec tunnel interface

[Christian Rößner]

Hi,

Am 15.04.2014 um 22:21 schrieb Dave Taht <dave.taht@gmail.com>:

>> I am would like to do traffic prioritization over a gre/ipsec tunnel that has a lot of video/voip traffic in addition to regular traffic (ftp/http... ) Is this something possible ?
> 
> Difficult. You could for example do some sort of act_mirred thing into
> multiple ifb or imq interfaces, and
> apply some qos there before encapsulating them in ipsec.

we, Dr. Michael Schwartzkopff and I, just talked about a similar solution this morning. Funny. Our idea:

We have an incoming and an outgoing interface to a router. The router is doing IPsec. What we can do is to detect RTP with nDPI and modify the DSCP bits for VoIP. Afterwards using u32 and match the bit mask for these DSCP-bits (S5 i.e., I gues 0x28).

We did not test it yet. Friday ;-)

Kind regards

-Christian Rößner

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: QOS on GRE/IPSec tunnel interface

[Luc Paulin]

Great thanx for the information... 
Yeah that sound a bit complex as a setup. 

However now I am a bit confuse as I was doing search yesterday I found the following thread.  http://www.spinics.net/lists/lartc/msg19972.html 
As per the email thread the fwmark should be carry on to the encrypted packet and therefore prioritisation of the encrypted packet should be the same as if it wasn't encrypted. Is this still true? So as per the thread is I understand correctly if the traffic that come in to an interface is "MARK" correctly then when it goes out on the encrypted tunnel it should be prioritise as it would normally be? 






On Tuesday, April 15, 2014 4:21:24 PM, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Apr 15, 2014 at 1:09 PM, Luc Paulin <paulinster@ymail.com> wrote:
> Hi,
> I am would like to know if it's possible to do QOS on GRE/IPSec interface ?

fq_codel can peel away a GRE version 0 header and do smart things with
it. IPSec, not so much.

> I am would like to do traffic prioritization over a gre/ipsec tunnel that has a lot of video/voip traffic in addition to regular traffic (ftp/http... ) Is this something possible ?

Difficult. You could for example do some sort of act_mirred thing into
multiple ifb or imq interfaces, and
apply some qos there before encapsulating them in ipsec.


> When I apply the rule on the interface it look like class doesn't do what they are suppose to do. ie(the traffic rate is way too low of the actual real traffic flow)

> Thanx!
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article 

Re: QOS on GRE/IPSec tunnel interface

[Benjamin Kiessling]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Greetings,

On 04/15, Luc Paulin wrote:
> Hi, 
> I am would like to know if it's possible to do QOS on GRE/IPSec interface ? 
> I am would like to do traffic prioritization over a gre/ipsec tunnel that has a lot of video/voip traffic in addition to regular traffic (ftp/http... ) Is this something possible ? 
> 
> When I apply the rule on the interface it look like class doesn't do
> what they are suppose to do. ie(the traffic rate is way too low of the
> actual real traffic flow) 

The most probable issues is that GRE interfaces don't have a queue per
default (i.e. a one packet queue) causing major inaccuracies. An easy
solution would be to just set an explicit queue length with ip:

	ip link set dev $gre_dev txqueuelen 32

If you decide to utilize ifb devices you have keep the same in mind. The
optimal queue length probably varies depending on your qdisc, speed,
etc., but 32 packets is usually enough for low bandwidths (<100Mbit/s).
Of course shaping will only be effective if the GRE tunnel constitutes
the choke point in your set up and the underlying medium has a
reasonable amount of additional bandwidth.

Regards,
Ben

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]