QoS over VPN tunnel

[BS]

Hey all,

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?

BS

[NolanHerring]

Yup. I basically just apply the defaults that they came out with few months back. As long as both sides of the tunnel have it, they will honor the markings they receive (assuming your applications are marking).

[jdsilva]

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. 

[PhilipDAth]

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.

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/QoS_over_a_Site-to-site_VPN

[PaulB]

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?

[ww]

Yes sir

[PhilipDAth]

>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.

[PaulB]

Hi Philip,

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.

[PhilipDAth]

>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.

[CarlosRu]

Hi all,

I had a customer asking if the MX units copied DSCP markings from the unencrypted IP header to the encrypted UDP packet header. I was happy to find this discussion with some saying yes, and some others saying no. I took the time to set a little lab and I was even happier to see by myself that DSCP tags ARE copied from both already marked traffic ingressing the MX, and traffic that is marked by a custom traffic shaping rule in the MX. I could see the DSCP field with the corresponding class on the encrypted UDP packet in a packet capture.

Mystery solved 🙂

[Bruce]

@CarlosRu Great to know for certain. This is supported by the FAQ at the end of this article, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/.... Out of interest, what firmware version did you use in your test?

[CarlosRu]

Hi @Bruce 

I thought I had included the firmware version in my post. I pushed the latest stable as of Oct 2 2020 which is MX14.53.

Thanks for the tip about the FAQ reference. I was hoping that they had this documented somewhere.

[cmr]

Just a pointer but we have tagged traffic that was going over an MPLS network and dividing into three classes.  When we added MXs and created autoVPN over the MPLS, all the traffic ended up in the base class.  This was with the 15.x release train.

I didnt do any wireshark captures but I do know that once the autoVPN was created no tagged traffic matched to anything other than the base tier.

[GIdenJoe]

@cmr 
First thing to be absolutely sure of:
Is the CE-router accepting pre-tagged DSCP packets?  That means trust DSCP.
Or is it trusting COS or doing it's own classification?

[cmr]

I'm pretty sure it was trusing DSCP as it was routing the packets to the different queues before the MXs were put in place and we hadn't told them what traffic we wanted in each queue other than by
DSCP value.  We since disabled QoS on the MPLS so now it trusts no-one 😇

[DennisSN]

i did the exact same test today, and ALL traffic between my branch MX and HQ VPN hub is CS0

Both devices are on firmware 14.53

[Bruce]

And so the mystery continues...... 🤣

[GIdenJoe]

If your inner traffic is not tagged, your outer traffic will not be tagged to.
Please make a capture on the final switch right before the packet enters the LAN interface of the MX.

Or make sure you have rules in place to tag the packets at the MX.

[Xoncomms]

Hi

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

[PhilipDAth]

The only way to confirm this will be via a packet capture.

[GIdenJoe]

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.