Default QoS setting ansd increased utilization

[Charlie]

Does anybody run the default Qos rules on their hub MX450s?  I ran into a situation where I was running high on my hubs utilization and decided to switch on the default Qos rules.  What I noticed is that using the default qos rules increased the utilization to an almost unmanageable mode. 

So in one sense I was trying to use qos rules on a MX hub with 78% utilization to prioritize traffic but what ended up happening is that the hub's utilization jumped up to about 90 to 95% and made the spokes unusable.  Does it make sense that enabling default qos rules would increase 15 to 20% on the hub's summary report? 

[ww]

it has to inspect the traffic and tag the related packets with dscp. so i guess this wil increase utilization. 

This default option does not make a lot sense i.m.o because it does not prioritize anything on the mx itself. you would match traffic and set prio low/normal/high with a traffic shaping rule and then you also can tag a packet with dscp.

[Charlie]

Yeah I get the idea that this would use up processing power just surprised me that it seemed to be so much.  Just wondered if others saw the same and if anybody was considering enabling then to be aware of your current ceiling. 

As for the QOS (I guess technically it's called default traffic shaping rule) Maybe I was a bit turned around in that I thought the default traffic shaping rules would be like auto-qos so for example if it saw an EF tag or voice application from the spoke it would then prioritize that in the event of an over utilized hub.  Being that Voip is what I was most interesting in preserving and was called out in the default rules as EF I thought it might get priority when resources got tight.   I disabled it and went with an actual rule definition for Voip in case that might do what I was hoping and then use less resources on my hubs.  

@head in the cloud thanks for the feedback and thoughts. 

-Regards

[ww]

if your voice packets are  already marked with ef at arrival it should be working by default.  there is always a kind of "prio queue" in the mx which is not configurable and not visible.

[Charlie]

interesting.  Just so I make sure I am wrapping my head around your comment.   Let me state it this way.  So there's no need to use any of the traffic shaping features on the hubs as long as I am marking them on my spokes because the hub WILL use this "queue" of it's own and prioritize accordingly (if marked).    If so that's great and I can take even more resource load off my hubs but removing the individual rule. 

What I would like to see is some counters on the hub to see if this "queue" is dropping or hit with tags like we usually see on a switch command.  

[ww]

only for EF.

see end of this

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Using_Packet_Prioritization_on_a_Tr... .

[Charlie]

Thank you for the clarification and link.  -Regards

[PhilipDAth]

>so there's no need to use any of the traffic shaping features on the hubs as long as I am marking them on my spokes because the hub WILL use this "queue" of it's own and prioritize accordingly (if marked). 

This wrong.  The traffic priorization rules apply to the device that are assigned on for traffic going out its uplink(s).  The traffic heading towards the hub is being received, so the rules will have no impact on the hub in this case.

It does seem excessive that such a large amount of CPU is being used.  You must have a big network to be maxing out an MX450 like that.  I think I would open a support case about QoS consuming CPU like this and see what they say.

If the MX450 is being driven so hard you may need to consider using a pair of MX450 in an active/active configuration to lower the CPU load.

[Charlie]

First things, yes our sites are not smallish sites but do include some rather large footprints with 3-8 switches/Aps/ many hosts plus voip.  

So if I think I understand your comment.  If the setting on the MX only works on the outgoing links, then adding a voip rule there *would* prioritize my voip traffic as it leaves the MX and into my internal network?  

** It's also worth mentioning that we use a NAT mode cause we want to pass all of our unencrypted traffic to our next hop firewall for inspection.  

[PhilipDAth]

>then adding a voip rule there *would* prioritize my voip traffic as it leaves the MX and into my internal network?  

Hopefully all your sensitive traffic is already DSCP marked.  AutoVPN preserves these markings.  Your internal switches should be able to use these to provide internal QoS.

This is independent of using the QoS option on the head end.