WAN Quality of Service Implementation Question

[John Peek]

I am asking all over the place to get the best idea on how to implement this. I don't know if I am posting in the correct forum or not, my apologies if it is in the wrong one.

I have a 22 Mbit partial DS3 at my main facility and 1.5 Mbit T1's at the remote locations.

So let’s say I create this policy map

Policy-map QOS

Class voice

Priority 4400

Class missioncritical

Bandwidth 5500

Class transactional

Bandwidth 4400

Class other

Bandwidth 2200

As you can see a single site can max out a single queue and their T1 without even triggering policing. I have 17 sites. My outbound traffic generally sits at about 4Mbps and can max out multiple T1's easily. What is happening is when someone re-downloads their 8GB email folder, it will max out the T1. So I currently rate limit based on source and destination IP addresses(I want to try and get away from that). Is it possible to have the queue's listed for each site with bandwidth limitations equaling 75% of the T1?

Any help would be greatly appreciated. If you need me to clarify any points, I will do so gladly.

[lgijssel]

You can do this but you will always need to add info regarding src/dest for all sites in order specify maximum values.

Perhaps it will become easier to administer with a hierarchical policy:

policy-map qos
class Voice
  priority percent 20

class missioncritical

  shape average percent 25
  service-policy missioncritical-sites

The policy-map missioncritical-sites contains matches on acl to classify the traffic, much like you do it now.

This would allow a max of 25% for missioncritical but in the underlying policy, you can limit the rate per site in order to prevent overloading a T1.

IMHO you need to use a shaper because otherwise any traffic in excess of the specified bandwidth will also be forwarded.

This should not be a problem as long as the rates are higher than what an individual T1 can absorb.

regards,

Leo

[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

You didn't note what kind of "cloud" the DS3 and T1 are using, or your platform/IOS, so unable to be very specific, but in general, you might want an approach smillar to one that uses CBWFQ with a class to match each branch (hopefully each branch has a single address block), class shaper to match downstream availble bandwidth (for supporting VoIP, use tight Tc and you may need to allow 15 to 25% shaper bandwitdth to account for L2 overhead), child policy to prioritze your traffic types (you might initially try LLQ for VoIP and FQ for everything else).  (NB: you might also need to decrease the DS3 interface's hardware TX queue.)

For branches, likley a direct application of a CBWFQ to the T1 will suffice.

[John Peek]

Thank you. You are the first person to ask a question. It's an MPLS network. I am running  15.1(1)T1 on the DS3 connection(new router). I am running 12.4(25a) on all my t1 sites.

So let me see if I understand what you're suggesting. .

policy-map parent

class child

shape average 1152000 115200

service-policy child

!

policy-map child
class VOICE
priority percent 27
class CRITICAL
bandwidth percent 33

class TRANSACTIONAL
bandwidth percent 27
class SCAVENGER
bandwidth percent 13

For the shape average that's 75% of a t1 with a bc of 115200. If I am understanding the TC correctly, that would give me a tc of 10? Essentialy 1/10 of a second.

Where would be the best place to account for the 25%? Or does it even matter? I could shape to a full t1 and then the queue's within are limited? Your help is greatly appreciated. Thank you.

[Joseph W. Doherty · Accepted solution]

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

Ah, if you're using an MPLS cloud, does your MPLS vendor provide any QoS support?  If so, you would only need to control priorities and mark your traffic as you ingress into their cloud.  (NB if you have any-to-any [site] communication, you really need MPLS vendor QoS support.)

Yes, your policy is close to what I have in mind but you need to map to each site, something like:

(syntax likely incorrect)

class-map site1

match all site1ACL

.

.

class-map siteN

match all siteNACL

policy-map parent

class site1

shape average 1152000 115200
service-policy child

.

.

class siteN

shape average 1152000 115200
service-policy child

For T1, unlikely you need to shape less than 85% of nomimal bandwidth to account for L2.  You can compute worst case using L2 overhead relative to minimum packet.

I believe your shaping values would indeed provide a Tc of 100ms, but would recommend about 10ms when supporting VoIP.  Older IOSs, I recall, default Tc to 25ms, newer I believe default even smaller, but as you've described, you can control Tc but setting burst size relative to rate.