Is anyone here use QoS on MX devices through VPN tunnel to traffic shape Voice and video?
Can you guys share your experiences, any challenges and suggestions?
First off you should realize that it doesn't matter what you mark your traffic when you are sending it in a VPN over the Internet. The Internet doesn't respect your markings. It laughs at your markings. It spits on the ground in front of your markings. It farts in the general direction of your markings.
But, for inside your own network, what @NolanHerring says is bang on. Well... Almost bang on, depending on what version of firmware you're running. As of version 14.5:
And then tweaked just a touch in version 14.6:
In our testing this has worked exactly as described. So at the end of the day, for Voice payload, as long as your end points are marking their traffic correctly and your switches trust those markings (or if you're marking on switch port ingress) you don't actually need to do anything on the MX. It's already doing it.
Video is obviously not covered here as it shouldn't be marked EF, so normal rules apply.
AutoVPN will preserve the DSCP markings of packets entering and leaving the AutoVPN tunnel - but will not act on it in anyway. More specifically, traffic flowing over an AutoVPN tunnel does not recieve any special treament.
As a point of clarification, will the MX copy the DSCP marking of the IP traffic header to the AutoVPN (IPSec) header. I need this to tell the MPLS WAN provider how to treat the traffic. For example, IP voice traffic marked as EF will be automatically copied by the MX to the AutoVPN (IPSec) header hence the MPLS network will know how to treat it?
>As a point of clarification, will the MX copy the DSCP marking of the IP traffic header to the AutoVPN (IPSec) header
It old firmware versions it did not. In new firmware versions it does. I don't know what version this behaviour changed in.
I opened a case with Meraki on this (date 3rd Jan 2020) and they came back stating that MX does not copy the encapsulated payload QoS marking to the IPSec packet header. Therefore VPN traffic transiting a QoS enabled network will not be recognised.
Meraki Case 04683455
The L3 header should get the marking but I haven't that the chance to test it.
But it should be normal that this is implemented.
The whole reason a company would choose a WAN solution instead of a public internet connection (like an MPLS connection with QoS queues from the SP) is to have that differentiated service.
Have you seen this working in the past? What did you base your answer on?
I've reached out to our Meraki SE and they confirmed that this is currently a feature request that has been open with the product team but no promise on delivery etc.
I was also wondering if this behaviour changes depending on whether we mark the traffic on the MX as it arrives on the LAN port or if it is simply trying to copy the DSCP from already marked traffic arriving on the LAN.
It would be really good if someone on here could test this behavior using a packet capture.
>Have you seen this working in the past? What did you base your answer on?
I have not seen it working.
I was told by a Meraki SE that I trusted that this was the behaviour in older MX firmware versions but this was changed in the 14.x train.
We need someone to do a packet capture of this to see if it is true or not.
>I was also wondering if this behaviour changes depending on whether we mark the traffic on the MX as it arrives on the
>LAN port or if it is simply trying to copy the DSCP from already marked traffic arriving on the LAN.
The behaviour should be the same.