Don't strip QOS DSCP markings
Azure vNets with ExpressRoute should support QOS markings. Ideally the Expressroute circuit should honour and prioritise packets with DSCP priorities set.
If honouring DSCP is not possible then the values should at least be passed along and not be stripped out.
We have Azure connected to our internal MPLS network via an Expressroute Exchange provider. (Our MPLS provider is not setup as a Network provider in Azure). Some of our remote sites have congested links however with QOS we ensure all business applications perform well.
We are now moving some business applications into Azure and getting performance problems due to Azure removing the DSCP markings from our packets. The servers in Azure have QOS settings applied via group policy and network captures on the VMs show the correct DSCP values on outbound packets. Once those packets arrive in our network the DSCP values have been stripped.
Thank you for your suggestion. We are reviewing it at this time.
anyone had any feedback from admins on this yet?
This link suggests they only strip dscp on traffic received on azure.
Does that mean azure doesnt strip dscp on traffic out of azure towards an expressroute providers PE?
Totally agree that MS doesn't need to honor DSCP tagging, but shouldn't be stripping it either! MS wants everyone to move in their cloud solution, but they don't provide robust infrastructure that has been in practice for years...shame
Jonathan Rosen commented
We are deciding between AWS DirectConnect and Azure ExpressRoute at the moment. We would like to use ExpressRoute, since we are using other Microsoft services where it would be useful (Exchange, Dynamics, etc). However, the main use case for ExpressRoute was ensuring voice traffic would flow without interruption between a hosted PBX and our branch offices. We will not go with ExpressRoute (and therefore Azure for hosted servers, etc), without Azure respecting QoS tagging. It can be done for Skype for Business, but not any other voice solution. This seems like an attempt to potentally cross-market Skype for Business, but it's going to lose you our business.
Shane Pearce commented
Hi Azure Networking Team. I see this issue was reported back in 2015. It's now 2020 and in my recent experience, it looks like there has been some changes to not strip DSCP marked traffic using express route. However, other than via Windows GPC there still seems there is no way to mark traffic and shape traffic into low bandwidth pipes. I have investigated the use of a VNF / Router in azure to do this, however, I have found there is no way to get other VM's to route traffic via the VNF due to other limitations in Azure ! This is very frustrating...
During migration we find out that we have problems with UDP QoS.
We are using QoS DSCP in our services for management VoIP traffic between our server and mobile client. But after passing Azure network hubs the headers of the data packets (DSCP field) become nulled (changed from “1011 10” to “0000 00”). It leads to unstable work on channels with low bandwidth capacity or during high load.
So, in UDP packets sent from the server hosted in Azure, to end clients located outside of the infrastructure Azure are lost QoS flags. We're not trying to balance the UDP traffic inside infrastructure inside Azure, we need QoS flags outside Azure. I.e. we are trying to figure out how to keep our flags of outbound QoS UDP packets from Azure.
I wonder why they remove priority flags, without them any VoIP solution is simply impossible.