recommended QoS policy for NBX over MPLS

[bpieslak]

We run 2 NBX V3001 call processors which are connected across the country via 3Mbps MPLS. We have licenses for 9 virtual tie lines.



We also run several business apps over the MPLS as well, most of which are HTTP-based or connect over Citrix XenApp (ICA).



We are starting to experience poor call quality over our virtual tie lines, and I wanted to verify with our ISP what our QoS policy should be.



If anyone has multiple NBX call processors connected over MPLS, can you let me know what your QoS policy is?



Thanks,

-Brian

[bosoxfan_1]

One thing you should do is to make sure that all calls over VTL are

g.729 to save bandwidth. In Netset, under System Wide Settings -> Audio Settings, make sure Lowest Bandwidth is selected for VTL calls.

[bpieslak]

Thank you very much for recommending to change that setting.

Both V3001 call processors were set to "Best Audio Quality".

I will check with my users to see if they notice a difference over the next couple of days.

I am also still interested in verifying that our MPLS QoS policy is setup correctly to give the NBX phone traffic the highest priority.

Thanks again,

-Brian

[merlin_1]

2 Protocols that should be set up arer 802.1Q and 802.1P for layer 2 and layer 3 traffic . Perform a network trace on the far end of your network ( nbset ) and see if you arer recieving your audio with 802.1P set . Bandwidth could possibly be a culprit as bosoxfan states as well . Comon issue we see a lot of . MPLS is configured manually as there is no standard set up for QOS or Multicast protocols .  

[bpieslak]

Unfortunately, users are still reporting call quality issues, even with the changed audio quality setting.



I'm still trying to verify 802.1Q and 802.1P in our current QoS policy with our MPLS provider

[Luckycharms]

TCP traffic based traffic has a different traffcic pattern impact on QoS than UDP traffic because it has its own backoff methodology. Worst case scanarios, this backoff methodology with TCP can cause whats called "Global TCP syncronization" effect.

MPLS providers don't typicaly prioritise traffic across there network by default as they ususally charge customers for it and customers usually demand some kind of SLA (service level agreement) with the MPLS provider. The SLA usually compensates the customer with $$$ should there be a problem. Regardless you need to somehow be able to differentiate NBX traffic from non NBX traffic so your provider

Couple of questions to start

1. Is this a MPLS L2VPN and L3VPN.



2. Are the NBX's and phone on seperate subnet and/or Vlan.



3. What is the physical link to the MPLS cloud Ethernet, T1 etc

If L2VPN then make sure your provider honors the 802.1p priority and verify what that priorty is on the NBX so you can tell them. If its a L3VPN then the same applies but this time it needs to be either DSCP value in NBX packets or the NBX Subnets on each side

If the NBX shares the same VLAN/Subnet as your other traffic then you use the DSCP value or some other Layer 2 vlaues i.e OUI 00-e0-bb to differentiate the NBX traffic. If the NBX is on its own VLAN/Subnet then your provider can jsut prioritze the subnet.

Now the physical link. If its a 3MB subscription I assume its an Ethernet hand off to the MPLS provider. This means the provider is throttling incoming traffic it received on the link to 3MB but your side is sending it at 10/100/1G. If your comfortable with QoS and your switches you can rate limit your side of the Ethernet link to MPLS provider, down to 3MB. Then configure QoS yourself to prioritize NBX traffic.

Lastly, you coudl always bump up your pipe from 3MB to something else obviously  the provider will charge you it then it all comes down to Opex ( cost from provider Vs time and ongoing effort on your part.

[bpieslak]

Thank you very much for all of the information.

To answer your questions:

1.) L3VPN for MPLS implementation.

2.) NBX and phones are on the same VLan as all of our other network traffic

3.) We have MPLS-T1s at both locations.

My ISP has said that they will "We will mark voice traffics with DSCP-46"