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.
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 128T
service-class definitions. Each 128T system will have these mappings as part of the "factory default" configuration.
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 Class||DSCP Marking||128T Service Class||Workload|
|Voice||EF (46)||Telephony||Skype/Microsoft Teams/Lync voice|
|Interactive||AF41 (34)||MultimediaConferencing||Video, VBSS|
|Interactive||AF21 (18)||LowLatencyData||App sharing|
|Default||AF11 (10)||HighThroughputData||File transfer|
|Default||CS0 (0)||Standard||Anything else|
Sample Configuration Excerpt
The following example configuration excerpt illustrates the relationship between a
service-policy, and a
description "Skype voice traffic"
description "RTP/bearer audio"
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
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.
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