Has anyone noticed the MOS usually stays around 4.1 no matter how good your VPN tunnel is performing? We have an excellent link with 4ms latency, 2ms jitter, and 0% packet loss and the MOS never goes above 4.1. This keeps the traffic shaping from performing as expected. The MX wants to use both WAN connections even though the other link is around 90ms latency, 16ms jitter, and 0% packet loss when "best for VoIP" is selected for traffic shaping. We really want to use the "best for VoIP" instead of preferring one WAN over another for the faster failover switching.
I can confirm the same behaviour. I never see it go about 4.1.
Could someone from Meraki confirm how this is calculated?
Well I just learnt something. It seems using G.711 and "standard" parameters a MOS of 4.1 is the maximum you can get.
https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html
I guess the moral of the story is that both circuits are equally good for voice.
It is just our view of the maths getting in the way, and thinking it should be better because one circuit performs better than the other.
However, I'm still with you. I would prefer the lower latency lower jitter circuit myself.
I agree. Allowing the MX to calculate using the entire range would be better since most everyone would prefer to use the best path, not just one that is acceptable for g.711. Or let us choose the scale we would like to use.
Can someone answer this for me? When looking at the uplink decision stats for both sites, there are different stats depending on which site you are looking at. Are the stats measuring the inbound ICMP traffic? So if you are seeing packet loss in the stats at one site and not the other, that means the packet loss is on the inbound traffic for the MX you are viewing?
The stats are based upon bespoke performance probes, which the MX generates - these are not based upon ICMP, as it happens: see 'Performance probes' here, for a little more info: https://documentation.meraki.com/MX-Z/Deployment_Guides/SD-WAN_Deployment_Guide_(CVD)#Dynamic_Path_S... My assumption is that each MX is generating its own probes, so they are likely to be similar, but not identical. This matches what I see in a live deployment.
Thank you for the response! So if you saw packet loss for about 3 minutes in the stats of one side of the tunnel, but 0 in the other, what would that lead you to believe? We are trying to troubleshoot upstream network issues and hoping this will give us a good starting point with the carrier.
Where are you looking for the stats you mention?
The VPN Uplink Decision page with the Latency, Jitter, Loss, and MOS graphs. Site 1 > Site 2 Shows 0% Packet Loss. Site 2 > Site 1 Shows 3% Packet Loss.
I haven't seen symptoms like this - I think you will need to speak to the Support team, to look specifically at the site(s) in question.
As I recall, the 'Best for VoIP' pre-populated performance class monitors the calculated MOS for each path (tunnel) and will consider any path with a MOS < 3.6 as unsuitable for voice. The MOS is based on a calculation taking into account latency, jitter and packet loss. If a path has MOS 2.6 or greater then other rules, relating to path preference will take precedence. A path with MOS 3.9 will (for example) not be preferred to a path with MOS 3.7 - at least, not based upon the 'Best for VoIP' class.