So recently in another forum post this was discussed and deemed not OK.
However with some troubleshooting with the support team we finally managed to verify the marking are copied.
What am I talking about?
Well, when you have a Meraki SD-WAN setup all traffic going through the AutoVPN tunnels is encrypted inside an UDP header. So any routers in between the MX appliances cannot see the contents of the packets, which also means they cannot see the inner IP header that possibly contains a DSCP value in the ToS byte. This part is essential if you are running that AutoVPN over a QoS supported MPLS WAN and you would like your real-time traffic to not be dropped if one of the WAN links is congested.
So what if you had an MPLS connection that has 20Mbps downstream and 10Mbps upstream limitation.
Then the ISP usually uses traffic shaping. Since bandwidth shaping is only applicable outbound that function is spread between the customer edge and provider edge router to have both the uplink and downlink squeezing.
For the upstream traffic you are smart and set the MX to have an upstream speed of no higher than 10Mbps, so it does it shaping for itself and you control that flow. But what if several other branch offices send data at your location at once exceeding your 20Mbps downstream. You just cannot account for that at the senders side. So the traffic gets buffered at the PE interface towards your CE causing extra delay or worse if the buffer is full, it gets dropped causing packet loss.
This is where you should make use of the outbound queues on the PE router and have voice traffic placed in the priority queue of that router so it is sent first and non-delay sensitive traffic is delayed or possibly dropped. You can of course also have some data queues for drop sensitive data.
Since the ISP routers cannot make use of their ACL's or deep packet inspections (NBAR) they cannot differentiate between voice traffic and data traffic. However if they are configured to accept pre-marked packets from your MX and propagate those through the MPLS network then those routers can just use incoming DSCP marking to put the voice packets in the priority queue.
This is why it is important that the MX appliances read the DSCP value from the incoming LAN packet and copy that value to the outer IP packet when they encrypt and encapsulate the payload.
We finally managed to correlate the correct outer packets to the inner packets (we first had it wrong because a NAT'ed outer IP was shown in the captures somehow). And we noticed that the DSCP value is indeed copied to the outer IP header in the ToS byte. We also noticed that the overhead for the voice packets was exactly 60 bytes when being encrypted.
Screenshot of wireshark: the 195. address was the global address of the other MX appliance.
So both Meraki appliances in NAT mode (running stable) and in Concentrator mode (also stable) do copy the DSCP values from the incoming IP packets to the outer IP headers of the tunneled packets.
