Hi Arie, Thanks for your feedback!
I'll try to clarify my question 1 - it would be useful to know if (experience showed) there is such a thing as a maximum for the PQ bandwith allocation. Let's say you have just one priority class (in a child policy) and you police it at 80% of the available bandwidth (conditioned through shaping in the parent policy). Will CBWFQ/MDRR within the child policy be able to accurately distribute & assure the provisioned bandwitdh between the other classes when the priority class is congested? I'm actualy concerned about allocating 70% to the priority class. Thanks, Mihai -----Original Message----- From: Arie Vayner (avayner) [mailto:[email protected]] Sent: 10 iunie 2010 18:30 To: Mihai Todor; [email protected] Subject: RE: [c-nsp] QoS concerns Mihai, Please see inline. Arie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mihai Todor Sent: Thursday, June 10, 2010 13:12 To: [email protected] Subject: [c-nsp] QoS concerns Hello, I have some issues related to QoS I hope you might help to shed some light upon: 1. Is there any maximum bandwidth allocation percentage for the LLQ deployed in conjuction with CBWFQ/MDRR so as to enssure that other non-priority traffic classes are not starved when PQ utilizes the maximum bandwith. The plaforms details are: - XR 12406, SIP 601, SPA-10X1GE-V2 running IOS XR 3.8.0 - 7609-S, SIP 600, SPA-5X1GE-V2 running IOS 122-33.SRB5 Advanced IP Services [Arie Vayner] Yes. Every time you configure a priority class you have to specific a policer value (will be active only when there is congestion). This can be done either after the priority keyword or as an explicit police command in the class (will be active at all times). 2. Is there any possibility that a 7206VXR performace is impacted by deploying traffic marking policies based on input interface? The plaform configuration is: - 7206VXR, NPE-G1, PA-2FE-TX running IOS 124-15.T9 Advanced IP Services [Arie Vayner] Yes, but for just marking the impact should be quite low. On platforms like 7200 (software bases) any feature has some impact on CPU. 3. Has anyone deployed with satisfying results the classification of voice traffic within a normal class (not priority)? The benefit would be the possibility of borrowing bandwith from the other classes when available. [Arie Vayner] For VOIP you need to maintain low jitter, which is what the priority queue does. Using a non-priority class for VOIP would potentially create a high jitter stream, which would reduce the voice quality. Many thanks for any of your comments! Mihai _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
