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