cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
810
Views
0
Helpful
8
Replies

Traffic shaping over WAN

smhussain
Level 1
Level 1

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?

8 Replies 8

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.)

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?

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
Level 7
Level 7

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

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
Level 7
Level 7

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

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

% Error! cannot attach policy Out2MPLS under Out2MPLS.

Mohamed Sobair
Level 7
Level 7

please refer to the bellow link on how to configure hierarchical policy and when:

http://www.cisco.com/en/US/docs/ios/12_2sb/feature/guide/chldprio.html#wp1052578

HTH

Mohamed

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: