05-13-2009 02:02 PM
Our company runs QoS over an MPLS WAN, but I am personally new to the technology. Given that our provider only allows four queues (EF, AF31, AF21, and BE), we have configured four corresponding policies. This seems somewhat limiting, given the number of queues Cisco actually supports. Here's the question; Is it possible to further prioritize traffic within a given queue?
Say for example, we want to place a certain traffic type within AF31, but we do not want to adversely impact other traffic within the queue. By the same token, we do not want to move either of these traffic types to EF. Can we control, in a more granular manner, prioritization within a respective queue? Any clarification you can provide would be greatly appreciated.
Solved! Go to Solution.
05-13-2009 06:07 PM
Hi,
Unfortunately, inside a class, it's the war between the different flows.
What you could do is to have a cascaded router behind the one connected to your SP link:
LAN--ROUTER-A---ROUTER-B--SP Cloud
On Router-A interface facing router B, you can do what you want in term of QoS. The only requirement is that congestion happens on this interface before it happens on Router B WAN interface so the way the traffic is prioritized on router A will not be changed by router B even if router B has less Class Of Service than Router A.
This implementation works only for the outgoing traffic. You still rely on the 4x classes of your SP for the receiving traffic.
HTH
Laurent.
05-14-2009 03:09 AM
As Laurent also describes, it's usually possible to fully manage congestion to MPLS (generally easy if you control the CE router). With MPLS, though, where the limitations of the provider's QoS model are most troublesome is upon MPLS cloud egress. It's possible to indirectly control this if you logically manage your MPLS cloud as you might with frame-relay or ATM. Unfortuanately, this is often impractical if you have more than a few nodes and have a logical mesh topology vs. hub and spoke.
PS:
Some MPLS providers allow you to select from various "profiles" of QoS model choices. This can be very helpful if traffic ratios vary between sites. Also, some MPLS vendor QoS models also provide support for different drop thresholds within some classes.
05-13-2009 06:07 PM
Hi,
Unfortunately, inside a class, it's the war between the different flows.
What you could do is to have a cascaded router behind the one connected to your SP link:
LAN--ROUTER-A---ROUTER-B--SP Cloud
On Router-A interface facing router B, you can do what you want in term of QoS. The only requirement is that congestion happens on this interface before it happens on Router B WAN interface so the way the traffic is prioritized on router A will not be changed by router B even if router B has less Class Of Service than Router A.
This implementation works only for the outgoing traffic. You still rely on the 4x classes of your SP for the receiving traffic.
HTH
Laurent.
05-14-2009 03:09 AM
As Laurent also describes, it's usually possible to fully manage congestion to MPLS (generally easy if you control the CE router). With MPLS, though, where the limitations of the provider's QoS model are most troublesome is upon MPLS cloud egress. It's possible to indirectly control this if you logically manage your MPLS cloud as you might with frame-relay or ATM. Unfortuanately, this is often impractical if you have more than a few nodes and have a logical mesh topology vs. hub and spoke.
PS:
Some MPLS providers allow you to select from various "profiles" of QoS model choices. This can be very helpful if traffic ratios vary between sites. Also, some MPLS vendor QoS models also provide support for different drop thresholds within some classes.
05-14-2009 01:06 PM
Your responses were very helpful. Thank you.
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: