Trouble applying QoS to GRE Tunnel

[dennylester]

I am attempting to apply QoS to a tunnel interface using a suggestion I received from a previous post and this is the message I received.

Class Based Weighted Fair Queueing not supported on interface Tunnel3

Here is what I am using for QoS

class-map match-any TERMINAL

match access-group 101

access-list 101 permit tcp host 192.168.x.x eq 3389 any

policy-map SHAPE

class TERMINAL

priority 192

Interface Tunnel3

service-policy output SHAPE

How else can I make this work?

Our host and remote sites are connected to a Sprint MPLS network. Since Sprint wouldn't support OSPF we built a bunch of GRE tunnels between the host and each site and run OSPF over those so we can utilize backups via DDR and floating static routes.

Now I need to apply some sort of QoS to these tunnels to give Terminal Server traffic priority. I assume if I try to apply this Policy-map to the serial interface all the traffic would look like GRE and I would see no benefit.

Help!!

TIA,

Denny

[tdrais]

Your policy called shape confused me since that is exactly what you have to do to make this work.

You have 2 choices to solve this.

The router has no idea how much bandwidth the tunnel really has (bandwidth command doesn't do anything). You create a artificial queue by shaping the traffic and then apply your QoS to that shaped traffic. This is normally called Parent and Child in the documentation. You should create a policy called for example SHAPE-PARENT and use a shape command in the default class. You would then in addition to shaping the traffic put in service policy statement pointing to your current SHAPE policy. This causes the router to first shape the traffic and then apply you QoS to the shaped traffic.

The other options is not place the QoS on the tunnel itself. You can mark your traffic coming into the router with the dscp/precendece . Since the markings are copied into the GRE headers you can then use the markings to diffenciate between the packets and build classes to match these. There is also a option to preclassify the traffic before it is encapsulated in the gre tunnel. You would place your QoS on the physical interface the tunnel was running over since the router has a real physical queue on the interface. Some people find it easier to understand on the physical interface. This of does not work well when there are multiple physical interfaces the tunnel can take.

[rwyates_2]

Here is a link that should help you configure this.

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800b3d15.shtml

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800c75d3.html

HTH

[dennylester]

Hello,

Thank you for responding to me.

I like the first option but am having a hard time understanding the Cisco docs.

The Cisco articles are great if I'm already familiar with the features, but in this case this is new and I'm having a hard time taking Cisco's limited examples and applying them to real life.

If I'm reading the QoS solution guide correctly, I believe what you suggested is Class-Based Traffic Shaping?

If I create a policy specifying bandwidth for Terminal Services traffic, what happens to all non Terminal Services traffic? Does it just compete for what's left or do I need to create another policy to handle that?

TIA,

Denny

[dennylester]

After re-reading this I have another question as well.

Under the Parent Policy, when I issue the command shaper average xxx

What should xxx be?

Since the child policy sets the bandwidth I want my matching traffic to have, I'm not sure what to set the shaper speed as.

Thank you,

Denny

[pxh]

under your tunnel interface:

int tunnel3

qos pre-classify

under your physical interface

int s0/0/0

service-policy output shape

please let us know if that works