QoS over VPN tunnel

BS
Getting noticed

QoS over VPN tunnel

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

20 REPLIES 20
NolanHerring
Kind of a big deal

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).
Nolan Herring | nolanwifi.com
TwitterLinkedIn

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:

 

image.png

And then tweaked just a touch in version 14.6:

 

image.png

 

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
Kind of a big deal
Kind of a big deal

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
Comes here often

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
Kind of a big deal
Kind of a big deal

Yes sir
PhilipDAth
Kind of a big deal
Kind of a big deal

>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
Comes here often

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
Kind of a big deal
Kind of a big deal

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

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 🙂

 

DSCP -final.png

Bruce
Kind of a big deal

@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?

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
Kind of a big deal
Kind of a big deal

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
Kind of a big deal
Kind of a big deal

@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
Kind of a big deal
Kind of a big deal

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 😇

Skærmbillede 2020-11-06 085401.png

 

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
Kind of a big deal

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

GIdenJoe
Kind of a big deal
Kind of a big deal

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.

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
Kind of a big deal
Kind of a big deal

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

GIdenJoe
Kind of a big deal
Kind of a big deal

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.

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