01-07-2009 05:01 PM - edited 03-04-2019 03:22 AM
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?
01-07-2009 07:59 PM
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
01-08-2009 08:59 AM
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?
01-08-2009 09:20 AM
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.
01-08-2009 05:07 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide