Main Site to Branch MPLS QoS questions

Unanswered Question
Jan 7th, 2009

I have seen other QosS questions, but have some that apply to me that maybe someone can help with.

We have Main branch with 9M (X6 T1) that holds call manager and all the voice servers (IPCC, Unity).

The 6 remote branches have T1s with 768k CAR from the Provider.

The main site is configured:

policy-map P-QoS

class VOICE

priority 1544

set ip dscp ef

class PRIORITY-DATA

bandwidth 128

random-detect

set ip dscp af31

class class-default

set ip precedence 0

The remote branch:

policy-map P-QoS

class VOICE

priority 512

set dscp ef

class DATA-Priority

set dscp af31

bandwidth 128

class class-default

set dscp default

fair-queue

random-detect

Both the Main Branch and remote sites have the policy applied to their WAN interface with no direction (in or out) specified.

My questions are:

1. Does a direction need to be assigned to the policies, or ingress and egress policies applied to get more out of QoS?

2. Could the policies I have be made to better utilize QoS?

3. To accurately size the classes, do I need to count the number of potential phone calls from each branch to the main branch, and size accordingly, including any potential video (coming soon) calls made?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
lejoe.thomas Wed, 01/07/2009 - 19:59

Hi Richard,

1. Does a direction need to be assigned to the policies, or ingress and egress policies applied to get more out of QoS?

Yes Qos direction needs to be applied, specifically in the outbound direction. Applying the direction and marking the packets in the outbound direction will provide the guaranteed service level in the provider cloud. You might have some agreement with provider to prioritize certain kind (eg:voice) of traffic.

2. Could the policies I have be made to better utilize QoS?

I would also consider shaping (branch and Main). Especially at the Main branch to ensure it does not transmit at rate exceeding the line rate of the branch office (to avoid egress blocking)

3. To accurately size the classes, do I need to count the number of potential phone calls from each branch to the main branch, and size accordingly, including any potential video (coming soon) calls made?

It would be best to monitor the network (voice traffic,UDP based) by configuring IOS IP SLAs.

http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsjitter.html

Also, the show policy-map int command should help to see statistics regarding the classes of traffic in the policy map.

HTH

Lejoe

wilson_1234_2 Thu, 01/08/2009 - 08:59

Thanks for the reply:

"I would also consider shaping (branch and Main). Especially at the Main branch to ensure it does not transmit at rate exceeding the line rate of the branch office (to avoid egress blocking)"

Can you explain this?

chris.grammer Thu, 01/08/2009 - 09:20

I was going to make a similar comment regarding egress blocking but from the service providers point of view.

Generally, the service provider will offer QoS profiles to be applied to their router that applies to traffic as it egresses the service providers network into your network. These profiles usually break down in percentages of EF, AF31, AF21..etc. If for instances the mainsite egress EF traffic from the service provider is over the profile percentage selected, the traffic will be dropped. The bad thing is, there could be 10 calls currently in progress to and from the main site functioning normally and then an 11th call to the main site causes all calls to instantly suffer performance degradation because the 11th call push the EF traffic over the service providers configured EF limit.

This is why it is extremely important to make a good estimate of the number of calls at the remote locations and at the main site. Then, configure call manager to only allow X number of calls to the main site and remote sites.

This not a exact science, its an art :)

Make a good guess at call volume, then monitor and modify as required.

lejoe.thomas Thu, 01/08/2009 - 17:07

Hi Richard,

Egress blocking for traffic from Main to branch might occur because line rate of access-link from Main to the provider exceeds that of the Branch.

eg: if the Main office was sending a packet of size 1500 bytes to one of the branch, it takes aprrox 8 ms to send the packet into the provider cloud.(serialization delay)

However, the same packet takes 15.62 ms at the edge of the provider cloud to get into the branch router. As you can see it takes nearly twice the time, so depending on how many packets the Main is sending at T1 rate, these packets have to wait in the queue of provider edge connecting to the branch router.This is described as egress blocking. Again depending on provider network at that point, it might queue or even decide to drop packets during periods of congestion.

Now if you shape the traffic from Main to Branch at the same rate (768Kbps), this will not occur.

You'll have to constantly monitor the network to decide what works best for you and make changes based on that. We can set up a baseline but fine tuning comes with monitoring.

HTH

Lejoe

Actions

This Discussion