@aljoush12 wrote:
I tried configuring priority without bandwidth allocation for class PLATINUM and bandwidth allocation for the remaining classes but I received an error below. it looks like it is not supported on ASR920.
(config)#policy-map Network_EGRESS_Policy
(config-pmap)#class PLATINUM
(config-pmap-c)#priority
(config-pmap-c)#exit
(config-pmap)#class GOLD
(config-pmap-c)#bandwidth percent 20
Bandwidth kbps or percent command cannot co-exist with strict priority or priority level in the same policy-map
That's correct. Priority and bandwidth are mutually exclusive, but priority statement should also have a parameter for bandwidth allowance/restriction:
nserthostname-here(config-pmap-c)#priority ?
<1-2000000> Kilo Bits per second
level Multi-Level Priority Queue
percent % of total bandwidth
<cr> <cr>
@aljoush12 wrote:
So, I have also tested MPQ. It behaves like LLQ. Any feedback on the policy below is appreciated.
policy-map Network_EGRESS_Policy
class PLATINUM
priority level 2
class GOLD
priority level 3
class SILVER
priority level 4
class COPPER
priority level 5
class BRONZE
priority level 6
class Network_Control
priority level 1
class class-default
random-detect
The above is interesting, as I didn't know any platform supported more than levels 1 and 2, which is a relative recent addition, itself, to LLQ. My CML IOSv only shows 2 levels.
However, did find MPQ documented, and it just appears to be an extension of 2 levels up to 7 levels.
Way, way back, I've even used the original PQ (before CBWFQ), which had, and only had, 4 levels.
With it, you had the risk of, as Cisco describes for MPQ: "If high-priority traffic is not policed appropriately, bandwidth starvation of low-priority traffic can occur."
To avoid that issue, Cisco further says: "Therefore, though not required, we recommend that you configure a policer for high-priority traffic using the police command. If you configure the police command for priority queues, the traffic rate is policed to the police rate for each of the priority queues."
You couldn't do that with original PQ, and although it should avoid total starvation it's strictly hierarchical dequeuing would likely provide very variable performance for the lower priority queue classes. I would NOT recommend it for a generic policy, like your posted example.
Oh, I see you've now also added RED to class-default. I generally recommend RED only be used by QoS experts. (Getting it to work optimally, if much more complex than the introductory explanation documentation makes it out to be.
BTW, on a router, the following policy-map can probably effectively handle 99% (NB: might require some "tweaking", like queue depths) of all QoS needs:
policy-map Sample
class real-time !e.g. VoIP bearer
priority percent 35
class hi-priority !e.g. VoIP control, network-control
bandwidth remaining percent 81
fair-queue
class lo-priority !e.g. data backups, server-to-server mail
bandwidth remaining percent 1
fair-queue
class class-default !everything except which really, really needs a different class (above)
bandwidth remaining percent 9
fair-queue
