Traffic shaping over WAN

Unanswered Question
Aug 18th, 2009
User Badges:

We have two sites that connect via MPLS. The CIR of the circuits is 3Mbps.

We already have QoS configured for Voice/Video traffic which works fine. We want to restrict traffic coming from a particular applcation to 1 Mbps. I am looking at doing this using Class based traffic shaping (CTS) and not general traffic shaping (GTS).


Mentioned below is the current QoS profile including the new code:

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

Current QoS Config:



class-map match-any VoIP-CTRL

match access-group 110

class-map match-any VoIP

match access-group 111

class-map match-all VIDEO

match access-group 112

!

policy-map Out2MPLS

class VoIP

priority 408

set ip dscp ef

class VoIP-CTRL

bandwidth 82

set ip dscp af31

class VIDEO

set dscp af31

bandwidth 1536

class class-default

set ip dscp default

fair-queue

random-detect


interface ATM0/IMA0

bandwidth 4500

no ip address

ip route-cache flow

atm vc-per-vp 1024

no atm ilmi-keepalive

service-policy output Out2MPLS

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


New Traffic-shaping code:


I am going to add the following:

access-list 101 permit ip 10.10.1.0 0.0.0.255 10.10.0.0 0.0.0.255


class-map Shaping

match ip add 101


policy-map Out2MPLS

class Shaping

shape average 1000000

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

So my question is:


1) Is this code sufficient?

2) Am i missing anything?

3) Is there any other impact of this change apart from shaping of traffic from the servers in the 10.10.x.x range to 1 Mbps?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joseph W. Doherty Tue, 08/18/2009 - 07:59
User Badges:
  • Super Bronze, 10000 points or more

Depending on your IOS, you might need to add a bandwidth statement to the class.


BTW, I question using FQ and explicitly defined classes. On many platforms, the class-default FQ flows appear to be able to distort the other classes bandwidth allocations, excluding LLQ.


PS:

Also, just wondering why you want to shape this traffic. My personal preference is, if the bandwidth is available, and assuming there's no extra tier costs, use it. If some traffic is hogging bandwidth, just deprioritize it so that it, more or less, only gets excess available bandwidth. (For instance, instead of shaping your "Shaping" class, set the bandwidth allocation to the minimum setting.)

smhussain Tue, 08/18/2009 - 08:07
User Badges:

The application is quite sensitive to packet loss hence use of "bandwidth" allocation may not be suitable since if the allocated minimum for the new class is reached then the router polices the traffic?

That is why I was planning of using the traffic-shaping since this way the packets are buffered and not dropped when the application hits the maximum allowed limit.


Thoughts?

Joseph W. Doherty Tue, 08/18/2009 - 10:10
User Badges:
  • Super Bronze, 10000 points or more

If the application is "quite sensitive to packet loss", then a shaper isn't the solution. What you want to do is insure the application gets sufficient bandwidth and sufficient queuing that packets are not dropped. For the former, you set bandwidth to match the expected bandwidth requirement/need for the traffic and place it into its own class. For the latter, you would increase the queue depth of that class.


Depending on the nature of the arrival rate of the traffic in question, allocating more bandwidth than average need will influence average queue depth. Queueing depth can exponentially increase as the allocated bandwidth approaches actual average demanded bandwidth. In other words, if the average traffic demands about 1 Mbps, you want to allocate more than 1 Mbps. How much more depends on how little queuing you want. For example, if demand is 95% of allocation (e.g. 1 Mbps demand, 1.053 Mbps allocated), queuing will probably be much more extensive than if demand is 50% of allocation (e.g. 1 Mbps demand, 2 Mbps allocated).


As I mentioned in my first post, FQ, on some platforms IOSs I believe, tends to disrupt non-LLQ explict class bandwidth allocations. So to insure your bandwidth allocations, you might need to remove class-default FQ.


e.g.


class-map match-any VoIP-CTRL

match access-group 110

class-map match-any VoIP

match access-group 111

class-map match-all VIDEO

match access-group 112


class-map specialtraffic

match ip add 101


!

policy-map Out2MPLS

class VoIP

priority 408

set ip dscp ef

class VoIP-CTRL

bandwidth 82

set ip dscp af31

class VIDEO

set dscp af31

bandwidth 1536


class specialtraffic

;assume 1 mbps demand, allocate 75%

bandwidth 1333

;defined if default queue too small

queue-limit #

class class-default

set ip dscp default


no fair-queue

bandwidth 1000


random-detect


access-list 101 permit ip 10.10.1.0 0.0.0.255 10.10.0.0 0.0.0.255


(NB, above example may not correctly account for interface and/or CIR bandwidth. Running across MPLS, you many need to also deal with MPLS QoS model and/or account for other sites sending to other site.)


PS:

BTW, There isn't implicit policing of class bandwidth except for LLQ classes, such as your VoIP class.

Mohamed Sobair Tue, 08/18/2009 - 08:14
User Badges:
  • Gold, 750 points or more

Hi Syed,


There are a lot of points to be mentioned with regard to your current config:


1st: from the QoS background, you should classify and Mark at the Ingress and apply your QoS at the egress. So you should have 2 Policy maps:


a- One classifying and marking your traffic


b- one matching the marked traffic and applying to it the proper QoS queuing mechanism.


2nd: In order to have shaping CBTS and not Generic traffic shaping with Queuing , you should have a nested policy configured. In your config , you shaped traffic for (10.10.1.0) subnet but you didnt apply your QoS policy (Queuing)yet, it should be as follows:


policymap Out2MPLS

class shaping

shape average 1000000

service-policy output OUT2MPLS


3rd: If the Egress Interface connected to the MPLS provider, they might not preserve your marking unless you coordinate with them and ask them which QOS model in the MPLS they are using as they are 3 models:


1- PIPE Model

2- Short-PIPE Model

3- Uniform Model


Each model has its own characterstics and config. The Model which should preserve your QoS marking at layer-3 but has to be written on the MPLS Egress PE label Switch router is the (short-pipe model).


Pls rate if it helps,


Mohamed

smhussain Tue, 08/18/2009 - 08:25
User Badges:

Thank you for your response.


#1 I do have an ingress policy-map as well. It is not mentioned in this post as I thought it would not be related to a traffic-shaping question.


#2 If I use the same QoS policy (Out2MPLS)and just reference the new "shaping class" in the existing policy-map Out2MPLS - do I still need nested policy?



policymap Out2MPLS

class shaping

shape average 1000000


int atm0/ima0

service-policy Out2MPLS


Is this not sufficient?


#3 We have SLA's set by the MPLS provider to honor our QoS markings.


Mohamed Sobair Tue, 08/18/2009 - 08:43
User Badges:
  • Gold, 750 points or more

Hi Syed,


2- Yes , you will need nested policy, your parent policy is Shapes as per class shaping, and your child QoS which is your queuing should be under the shaping policy map.



HTH

Mohamed

smhussain Tue, 08/18/2009 - 08:53
User Badges:

I cannot nest the policy. It gives me an error:


% Error! cannot attach policy Out2MPLS under Out2MPLS.



Actions

This Discussion