Outbound QoS Issue - Far End Congestion

[sr71rules]

Greetings…

I have a QoS (shaping/policing) issue.  My WAN runs over an MPLS network, and I have a Frac DS3 here at the corporate data center running at 15.3 Mbps.  I have around 40 remote sites, all at either a single T1 or dual T1 (multilink) bandwidth.  I have a QoS policy in place, which works well the majority of the time.  The problem…when a user at a remote site is downloading a large file, either from my data center or from the Internet (via my data center), the remote end circuit can get saturated.  If the out-going circuit from the data center is saturated, QoS kicks in and everything is fine.  But, if it is not congested, then QoS does not kick in (other than still servicing any voice packets via Priority Queuing).  This situation causes issues with business critical applications and voice setup sessions, and these data streams no longer are prioritized.

How can I mitigate this issue?

My QoS policy config is listed below.  Also, I have attached a Visio drawing to give you an idea of my setup.

class-map match-any HIGH

description match high priority business traffic, will mark DSCP af31

match access-group 110

match protocol telnet

match protocol ssh

match protocol citrix

match  dscp cs3

match  dscp af31

class-map match-any LOW

description match lower priority business traffic, will mark DSCP af21

match access-group 111

class-map match-any VOICE

description match high priority voice traffic marked EF

match  dscp ef

!        

!        

policy-map cbwfq-out

class HIGH

    bandwidth remaining percent 80

class LOW

    bandwidth remaining percent 10

class VOICE

    priority 9000

class class-default

    bandwidth remaining percent 10

policy-map mark-inbound

class HIGH

set ip dscp af31

class LOW

  set ip dscp af21

class VOICE

  set ip dscp ef

class class-default

  set ip dscp default

Your help is much appreciated…

Thanks,

Brad

[Roman Rodichev]

You have a couple of options.

1. Setup parent-child QOS policy at the data center. Parent QOS policy will match traffic to each remote site, you can do this by using access-list matching remote IP subnet (yes lots of configuration). You would then shape each remote site class to the bandwidth that you have at the remote site and apply service-policy for the child qos policy. Child qos policy will do the actual queuing for each site. Even if all your remote sites have different banwidth sizes, you could potentially get away with a single child policy if you believe you can allocate bandwith using percentages. As a result, traffic from data center to the remote site will be shaped to the bandwidth of your remote site, and then child qos policy will prioritize your traffic accordingly.

2. The other option is to work with your MPLS provider and have them setup egress QOS policy on the PE-CE links according to your SLA. They might or might not be willing to be flexible with this request. I bet they already have their standard qos policy configured, you just need to find out what it is, and maybe ask them to adjust queues.

Either way, you should introduce scavenger class in your qos policy (or child qos policy if you go with option 1). At the dat center, mark any traffic that doesn't deserve bandwidth under 100% utilization as DSCP CS1 or IP Prec 1, and then give only 1% of bandwidth to that class. Network backup traffic, ftp transfers, and potentially http browsing traffic could fall into scavenger class, that's up to you.

If you need clarification on any of the above, let me know.

P.S. If you don't want to configure all those access-lists in the option 1 above, consider running DMVPN (without protection) on top of your MPLS cloud. You could then do per-tunnel QOS policy for DMVPN (http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_per_tunnel_qos.html). There are several great benefits from running DMVPN on top of MPLS. The only disadvantage is 5% overhead for IMIX traffic.

[sr71rules]

Thanks Roman!  I will look into option #1.  I had a feeling it would be something like that.  I will let you know if I have any other questions, and I'll let you know how it goes.

Brad