QoS for Voice over GRE over IPSEC

[RHITCHCOCK]

I've been reading about about QoS over GRE/VPN tunnels, and I want to make sure I'm understanding things correctly and taking the right approach.

Here's my example:

Site A - 10.1.0.0/16

Site B - 10.2.0.0/16

Routers on both sides are set up like my lovely illustration shows.  A loopback interface sources a GRE tunnel terminating on a loopback interface on the other router.  An IPSEC tunnel from the outside interface terminates on the outside interface of the other router, and encrypts the GRE tunnel.

My goal is to give voice traffic priority when it's actually present (it will be fairly minimal, 1 conversation at a time normally).  I would prefer not to limit the bandwidth of other data, as I want as much as possible to be available when voice traffic is not present.  So I want it all - all my bandwidth available, but voice prioritized.

At Site A I can easily put the IP phones in their own IP range if I want.  At Site B it's not so easy - that's the home of the IP card on the phone system that will connect these calls, and the IP address is right smack in the middle of my server range.  Changing it would mean touching a lot of other equipment, and isn't an option right now, unfortunately.  So no range can be used at Site B in an access-list, but obviously specific host IPs could.

So, at Site A:

1. Should I apply the qos pre-classify command to the GRE tunnel interface only, or to the crypto map as well?

2. Can I create just one class-map, to match voice traffic either like this:

class-map Voice

match dscp ef

or

class-map Voice

match access-group 101

access-list 101 permit ip 10.1.4.0 255.255.255.0 (range with IP phones) host 10.2.1.50 (IP of phone system)

and then a policy-map like this:

policy-map VoicePolicy

class Voice

   priority

3. What interface do I apply the policy-map to?  I know I can't apply that policy-map that to the GRE tunnel interface.

I want to make sure I'm understanding the qos pre-classify command properly.  I understand it allows you to classify packets before they enter a tunnel.  But obviously you need to match and apply QoS rules on those packets at some point, and I want to make sure I'm doing it on the right interface.  If it's on the GRE interface, obviously my policy-map won't work, and I'll need some sort of shaping I assume?

Additionally, I want to make sure my policy-map will work with just one class set to priority, and no other classes defined.

Thanks!

[Lei Tian]

Hi,

1,using pre-classify or not depends whether you are going to match information on new header or old header.

2,no pre-classify is required if you match dscp ef, but you need to classfy and mark on the LAN inteface. If you want match the L3 and L4 values from the initial IP header, then you need pre-classify on tunnel and crypto.

3,you can apply on either physical or tunnel. if you want apply on tunnel, you need HQOS with shaping on the parent level.

pre-classify is only required if you want match information on pre encapsulate and pre encryption header. By doing that, a coping of the initial IP header will be used for classifation. By default, DSCP will be copied to new header, you can classify traffic based on DSCP without pre-classify.

Yes, it is fine to only have 2 classes. 1 priority and 1 default. You might want to increase the anti-reply window size because qos policy will re-order the packets.

HTH,

Lei Tian

[k.hariharan1]

Hi,

I would like to add few points and a sample configuration which will meet your requirement.

1. As Lei said, no pre-classify command is required if you match dscp values, but you need to classfy and mark on the LAN inteface

2. Set the dscp values for your voice packet in the inside interface (LAN) of your router by using a seprate policy map as shown below.

3. Once you set the DSCP value, by default the TOS byte preservation will happen. and the DSCP valuse are available for in the ouside interface where you will be getting the encapsulated packets.

4.   The router prints this log message when a tunnel interface is configured with a service policy that applies queuing without shaping.

                                        router(config)# interface tunnel1
                                        router(config-if)# service-policy output CISCO
                                       Class Based Weighted Fair Queueing not supported on this interface

5. so , first we want to creat a parent policy where we need to shape the bandwidth available for the tunnel interface and then we need to call a child policy where  admission control for the child class is done based on the shaping rate for the parent class.

Sample configuration:  (HUB router)

=================

access-list 101 permit ip 10.1.4.0 255.255.255.0 (range with IP phones) host 10.2.1.50 (IP of phone system

class VOICE
match access-group 101

policy-map SETDSCP

class VOICE
set DSCP  AF11

class class-default
fair-queue

Interface

Service-policy input SETDSCP

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ip access-list extended tunnel1
permit  ip  any 10.203.12.0 0.0.0.255  -------------> considering destination as your remote site LAN ip range

ip access-list extended  tunnel2

permit ip any 10.203.13.0 0.0.0.255      -------------> considering destination as your remote site LAN ip range

class tunnel1

  match access-group name tunnel1

class tunnel 2

  match access-group name tunnel2

class GOLD

  match DSCP AF11

policy-map CHILD

class GOLD          

bandwidth percent 35

class class-default

fair-queue

!

policy-map ROOT

class tunnel1

  shape average 256000

  service-policy CHILD

class tunnel2
  shape average 128000

  service-policy CHILD

class tunnel3
  shape average 128000

  service-policy CHILD

interface tunnel 1
service-policy output ROOT

interface tunnel 2
service-policy output ROOT

Hope this helps

Regards,

Hariharan k

[RHITCHCOCK]

Thank you for the suggestions so far.

Hariharan, I tried to set things similar to your example.  I ran into the following things:

1. I can't use a class-map default set to fair-queue in SETDSCP.  If I do, I can't assign the service-policy to input on the Internal interface.  So, I tried eliminating it.  Instead of:

policy-map SETDSCP

class VOICE
set DSCP  AF11

class class-default
fair-queue

I have this:

policy-map SETDSCP

class VOICE
set DSCP  AF11

I don't know if that will work or not.

2. I wasn't sure why you had multiple tunnel access-lists and classes created.  Is that necessary?  I created one to define all traffic that would pass through the GRE interface on its way to the other site:

ip access-list extended tunnel0
permit ip any 10.2.0.0 0.0.255.255

and one class-map for it:

class-map tunnel0

match access-group name tunnel0

So, here is the relevant information from a sh run:

class-map match-all GOLD
match  dscp af11
class-map match-all tunnel0
match access-group name tunnel0
class-map match-all VOICE
match access-group 2600
!
!
policy-map CHILD
class GOLD
    bandwidth percent 20
class class-default
    fair-queue
policy-map ROOT
class tunnel0
    shape average 256000
  service-policy CHILD
policy-map SETDSCP
class VOICE
  set dscp af11

interface GigabitEthernet0/1

description Inside

service-policy input SETDSCP

ip access-list extended tunnel0
permit ip any 10.2.0.0 0.0.255.255

access-list 2600 permit ip 10.1.4.0 0.0.0.255 host 10.2.1.50

But when I try to apply the service-policy to my GRE interface I get this:

(config)# int tunnel0

(config-if)# service-policy output ROOT

Traffic Shaping feature is not supported in user defined class of parent level policy

I had hoped putting the shaping policy first, then the CHILD policy under it would allow me to apply the service policy to the GRE interface.  But apparently it doesn't like it, or I'm doing something wrong.

I can apply ROOT to the outside interface without any problem.  But I have no idea if that has any effect?  Is the TOS bit the same after GRE encapsulates the packets, so the outside interface still prioritizes them before they get encrypted by IPSEC and sent on their way?

[Lei Tian]

Hi,

When you have policy-map under tunnel interface, it should apply to all traffic pass through the tunnel interface. You can configure shaping under class-default and attach the child policy under the class-default as well.

You can apply policy-map under physical interface as well. As I mentioned in my previous post, dscp will be copied to the new header. Packets will be encrypted first and then be queued based on the priority, not the other way around,  and that is why you might need to change the anti-reply window size.

HTH,

Lei Tian

[RHITCHCOCK]

I'll attempt putting the policy on that outside interface, then.  I'll be doing some testing shortly and see how this works out, and update this thread with my results.  Thanks again for all your advice!