Wednesday, May 19, 2021

Cisco QoS with overhead accounting feature question

I'm not overly familiar with QoS other than what I've read so please bear with me if anything below is wrong.

We have a 50 Mbit MPLS circuit. The interface is 100Mb but we pay for 50 Mbit so we need to shape the traffic. We also need to account for 18 bytes of overhead within this 50 mbit. Current config looks like this which work well (random-detect etc removed for the sake of brevity):

policy-map parent_policy class class-default shape average 50000000 account user-defined 18 service-policy child_policy 

Now we are looking to add 5 Mbit of EF for a future voice service we are running across the link. I've read the Cisco QoS Scheduling documentation and it looks like we would be best with the "Priority queue with always on (unconditional) policer model" so that we never exceed the 5 Mbit we are allocated and that EF always has priority over the main internet traffic. So to this end I think i need a nested policy:

policy-map child_policy class EF police 500000 conform-action set-dscp-transmit ef exceed-action drop priority ! class class-default ! policy-map parent_policy class class-default shape average 50000000 account user-defined 18 service-policy child_policy 

My concern is that the overhead calculation will eat into the small amount of EF and so we'll get less than the full 5 Mbit. Ideally I'd like the overhead to be 'wasted' on the default traffic rather than my EF but my reading of the documentation suggests that account user-defined applied at the parent level will cascade down to all child policy classes equally. It does mention that for a 'conditional policer' the overhead is not accounted for but doesn't mention unconditional so i assume it's the same method as the policer.

Am i right in thinking that this will be the case and the EF policer includes the overhead ?

If so, Is there a way to bypass the overhead accounting feature for this EF class other than just guessing the EF packet size and adjusting the shaper accordingly?



No comments:

Post a Comment