Skip to main content

ExpressRoute QoS Configuration

When peering with Microsoft using ExpressRoute – particularly for Skype for Business and Microsoft Teams applications – it is important to ensure that you leverage appropriate QoS (DSCP) markings. Failing to use recognized marks will cause your packets to get dropped by Microsoft.1 This document identifies the appropriate service-class configuration to be used to ensure smooth interoperability with Microsoft ExpressRoute peering.

note

This applies only to ExpressRoute peering for voice applications. Consult your Microsoft account representative to ensure these requirements apply to your peering connection for other service types.

Microsoft only recognizes five different DSCP values on ExpressRoute. Any packets marked with a DSCP value other than one of these five will be dropped; therefore, it is important to ensure any services that will leverage ExpressRoute have a service-policy that marks traffic to one of thsee five values.

The table below is an augmented version of the one provided by Microsoft, to indicate the mapping of ExpressRoute DSCP to built-in SSR service-class definitions. Each SSR system will have these mappings as part of the "factory default" configuration.

important

It is possible that your factory default configuration has been administratively modified or various elements administratively deleted, and thus these service-class definitions do not exist on your system. You can confirm the presence or absence of these configuration elements by using the PCLI command show config running authority service-class verbose all, and ensuring the five classes mentioned below exist, and match the DSCP markings as indicated.

Traffic ClassDSCP MarkingSSR Service ClassWorkload
VoiceEF (46)TelephonySkype/Microsoft Teams/Lync voice
InteractiveAF41 (34)MultimediaConferencingVideo, VBSS
InteractiveAF21 (18)LowLatencyDataApp sharing
DefaultAF11 (10)HighThroughputDataFile transfer
DefaultCS0 (0)StandardAnything else

Sample Configuration Excerpt

The following example configuration excerpt illustrates the relationship between a service, a service-policy, and a service-class:

config

authority

service Skype-Voice
name Skype-Voice
description "Skype voice traffic"
scope private
security my-encryption-policy
application-name O365-Skype

access-policy trusted
source trusted
permission allow
exit

access-policy quarantine
source quarantine
permission deny
exit
service-policy voip-audio
exit

service-policy voip-audio
name voip-audio
description "RTP/bearer audio"
service-class Telephony
session-resiliency failover
path-quality-filter true
best-effort true
max-loss 1
max-latency 150
max-jitter 30
exit

service-class Telephony
name Telephony
dscp 46
traffic-class high
exit
exit
exit

In this example, the Skype-Voice service leverages the built-in O365 application module for Skype and is given treatment according to the voip-audio policy. The voip-audio policy in turn references the service-class named Telephony, which will mark packets with DSCP 46 (a.k.a. EF).

Given this configuration, as traffic arrives and is matched to the Skype-Voice service, it will be marked as EF (46) on egress.

note

This marking is path independent, so even if this traffic does not use an ExpressRoute (if for example the ExpressRoute is temporarily unavailable), the packets will still be marked per the service-class assigned.

Footnotes

  1. https://docs.microsoft.com/en-us/azure/expressroute/expressroute-qos