Meraki MS QoS behavior question

Solved
Chema-Spain
Getting noticed

Meraki MS QoS behavior question

Hi, 

 

I have always thought Meraki MS would enqueue Real time traffic (i.e. EF DSCP flows) in a dedicated Queue by default. However, reading Meraki documents they say all traffic is sent to default queue in case you do not enable qos. In a MS there is not a button to enable qos so It seems you only enable other queues (there are 6 queues) when you add any qos rule. Once you do this, it seems to start managing the default DSCP to CoS Queue mapping table (you can then edit this table if default mappings do not completely fullfill your requirements). 

 

Is there any way to check qos scheduling in order to see packet loss or packet delay in Meraki MS FIFO queues? I think it is not possible, just asking to ensure I'm right.

 

Another doubt is what a MS does with any incoming DSCP packet field not explicitly trusted or remarked in a Qos rule. Would MS reset DSCP to 0 or would it keep it transparently? I can only see in Meraki docs all traffic not matching any qos rule is sent to Cos 0 default queue.

 

I have a very large customer warehouse with a non recomended MS cascade topology where mobile wifi calls (roaming in place) are suffering poor quality. We have been able to slightly improve voice quality after running a wifi site survey and some fast roaming and other wifi stuff. However, I was wondering maybe using a dedicated queue for voice would also help here. In all other customer we had never configure QoS in MS network. Mostly because I thought EF traffic would be treated in a dedicated queue. However, we have never had customer complains about poor voice quality (never have dealt with such a huge warehouse)

 

Thanks

1 Accepted Solution
Chema-Spain
Getting noticed

Thanks for your help. Appreciated!

View solution in original post

4 Replies 4
DarrenOC
Kind of a big deal
Kind of a big deal

Hi @Chema-Spain , What is your telephony solution?  Do you have a VLAN configured for Voice?

 

Under Switching > Configure > Switch Settings i assign the Voice VLAN (in this example VLAN 12) to Trust incoming DSCP.

 

DarrenOC_0-1690560554414.png

 

Incoming packets on VLAN 12 will already have a DSCP tag of 46 so they are trusted. DSCP 46 maps to CoS queue 3.  All other data will be in the default queue.

 

Then on my switch ports i assign both my Access and Voice VLAN's accordingly.

 

DarrenOC_1-1690560777645.png

 

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
Chema-Spain
Getting noticed

Hi, it is mostly webex calling. Only a few fixed Cisco IP Phones. Voice vlan is vlan 8. Customer already has a qos rule for that vlan (only entry configured). Instead of trusting incoming dhcp they are remarking to EF. We are going to tell them to better trust dcsp or even change protocol any to webex-calling udp and cisco RTP ranges and remark both as EF. This way we ensure signalling is not marked as EF.

 

Thanks!

GIdenJoe
Kind of a big deal
Kind of a big deal

So how it should work according to the documentation is as follows.
There are 8 queues where 6 of them are configurable.  Each queue has a minimum bandwidth scheduling guarantee that is double of the previous queue.  That means if there is no traffic from upper queues your queue can actually borrow leftover bandwidth from higher queues.

 

By default there already is some mapping from DSCP values to queues in the DSCP to CoS queue mapping link.  However if you don't have any rules configured all traffic will be send to queue 0.  If you have an MS 120 or 125 series you only have the possibility to match incoming VLAN values and no UDP/TCP port rules.  However if your traffic is already tagged upfront you can add a rule that trusts incoming DSCP values.

 

AFAIK there are no live counters you can view to see the amount of dropped packets due to buffer overflow let alone viewing it in each queue.

 

I'm not sure if the standard IFMIB supports a queue dropped packets counter so I guess you're out of luck there.

Chema-Spain
Getting noticed

Thanks for your help. Appreciated!

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels