Apply Qos police on GRE interface or Physical interface ?

[Sarg .]

Hello guys.

This is my situation. I have site A and site B connected via a GRE tunnel. The GRE tunnel has a Qos policy applied to it but the physical interface does not. Site to site calls are fine, but when site B receives calls coming from the outside via an isdn voice gateway, the voice quality can be rather poor. Based on how I’m seeing it, the problem is occurring because there is no Qos applied to the physical interface so when in-coming calls enter from the isdn voice gateway, the returning voice traffic ( I.e the returning voice call leg going from LAN to WAN) does not get priority treatment. This is a live network and I will have to carry out this fix during network-up-time. I am considering if I should just apply the same Qos service policy already applied to the Tunnel-interface to the actual physical interface and still leave the policy applied to the logical interface in place?   By the way, if I was to do this, which policy would take precedence, the physical interface?

Guys do you think any problems could result from this?

cheers

[Marwan ALshawi]

Well, it is good question and there are couple of ways to do it

however the way i would recommend you to do it is by having Qos on the physical interface with shaping

to shape the physical interface to the actual WAN bandwidth then apply the qos percentages based on the desired and available bandwidth

however what you need to do here is enable/use a pre-classify command on the tunnel interface to make sure the TOS/marking value is being copied to the GRE/IP header as it is before got encapsulated in the GRE tunnel so your QoS policy on the physical interface can still recognize traffic types and perform the configured actions

bellow are some links of how this can be done

http://packetlife.net/blog/2009/jun/17/qos-pre-classification/

http://cisconinja.wordpress.com/2008/11/29/qos-pre-classify-in-gre-over-ipsec-vpns/

hope this help

if helpful rate

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

however what you need to do here is enable/use a pre-classify command on the tunnel interface to make sure the TOS/marking value is being copied to the GRE/IP header as it is before got encapsulated in the GRE tunnel so your QoS policy on the physical interface can still recognize traffic types and perform the configured actions 
bellow are some links of how this can be done 
http://packetlife.net/blog/2009/jun/17/qos-pre-classification/
http://cisconinja.wordpress.com/2008/11/29/qos-pre-classify-in-gre-over-ipsec-vpns/

NB: ToS should be copied to the GRE header since 11.3T.  Pre-classify is needed on the physical interface if you want to match against other header fields beyond ToS.  This is described in the very first sentence of the second reference.  However, the next sentence of the second reference goes on to describe a copy is made of the packet.  Unsure this is correct as it might only be header information that's available for classification.  I vaguely recall something like NBAR doing deep packet inspection, e.g. http site analysis or Citrix subtype classification, might not work.

Cisco technote on QoS options for GRE tunnels:

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml

[Marwan ALshawi]

Hi Joseph,

i think we had same discussion about this concept before

although i do agree that the marking, ToS will be copied however using the pre classify to make sure its being copied won't hurt as long as the QoS policies concept was done correctly

Cheers,

[Joseph W. Doherty]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

Marwan, re: "won't hurt"

Well, yes and no.  Logically agree with you 100%, physically, though, it might.

As an example of the latter, a couple of months ago had a vendor doing VoIP stress tests.  One or our 7200s with a G1 maxed out its CPU.  Turned out there was a policy map whose sole purpose was to "count" the different DSCP markings passing through the interface.  Taking this policy off reduced CPU to about 60%.  So, if you only need to look at the ToS, needlessly using pre-classify might create an issue that you wouldn't otherwise have.

Most of the time, would not expect using pre-classify needlessly to cause an issue, but just something to consider.