• Basic Campus Quality of Service (QoS) design

Print Friendly, PDF & Email


Quality of Service (QoS) is the ability to provide different priorities to different applications, users, or data flows, or to guarantee a certain level of performance to a data flow. QoS processes apply to traffic that flows through Ethernet ports and control planes. These processes can modify data fields (Class of Service (CoS) or Differentiated Services Code Point (DSCP)) or assign data streams to traffic classes for prioritised handling. In this document we will be implementing a basic enterprise QoS model.

Consider the following topology for the following examples:


What do we want to achieve

In this example, we will be building a small enterprise network with users connecting to Arista Wifi APs as well as directly to the switches.  We will also add an IP Phone to the network. 

We want the following applications to get priority above the other applications where possible:

  • Voice Over IP (VOIP) calls from IP Phones must be prioritised above everything else.
  • Conference applications (Zoom, Skype etc) must have a higher priority than other traffic.
  • All other traffic is considered best effort.

For a detailed view on the 3 stages of QoS namely, classification, marking and transmit queues & port shaping please refer to the document specified here – https://eos.arista.com/qos-basics/. We will be using these concepts throughout this document.


If we use the requirements mentioned above, the following can be derived:

  • We will need 4 traffic classes in the network:
    • Best effort
    • Business class
    • Voice
    • Network control (not usable by the end devices)
  • We will be classifying traffic using DSCP markings
    • 0 for best effort
    • 32 for business class
    • 46 for voice traffic
    • 48 for network control
  • From the requirements mentioned, traffic will be classified using strict priority queuing, meaning that traffic with a higher priority can starve the lower queues indefinitely.
    • This will allow in the event of massive congestion, that voice traffic will pass first, if there is capacity on the link, business class traffic will pass, and finally if there is capacity available,  best effort will pass. Network control traffic will always drop other queues to ensure the network’s control plane continues operating in heavily congested networks.


Using the “show qos maps” command to show the current DSCP to Traffic class mapping, it indicates that that DSCP values defined as:


Deriving the traffic class to DSCP mapping shows:

  • DSCP 0 will be using traffic class 1
  • DSCP 32 will be using traffic class 4
  • DSCP 46 will be using traffic class 5
  • DSCP 48 will be using traffic class 6


These values can be modified to suit your environments needs, for the purpose of this exercise, we will be using the predefined maps.

For this exercise we will be trusting the DSCP values from the end devices and not rewriting DSCP values except for the case of the IP Phones – These devices will be default marked using the voice VLAN functionality. More information available here – https://eos.arista.com/configuring-the-campus-voice-vlan/

For devices connected to the Arista Access Points (APs), we will be using the built-in Layer 7 (L7) firewall to classify conferencing and collaboration traffic and thus trusting the APs DSCP marking.

If you do need to remark or specifically classify packets, class maps can be used to identify and send traffic to the correct traffic classes. This can be done using service policies and an example for the simulated IP Phone will be shown later in the document.


SSID configuration

As mentioned in the requirements, we will be classifying and marking Wifi based traffic using Arista APs. This can be done using the L7 firewalling functionality on the APs by accepting and marking all conference applications with DSCP value 32. An example of this configuration is shown below in CloudVision Wifi. We will be marking packets both upstream and downstream to ensure the wireless radio side uses these DSCP values to prioritise the traffic according to Wi-Fi Multimedia (WMM).


Switch configuration

For the interface to recognise traffic, we must trust the DSCP marking supplied by the AP. To trust the DSCP values from an interface, apply the following configuration. For Campus Leaf 1 and Campus Leaf 2, configure the following:

Camp-Leaf-1/2(config-if-Et1)#interface Ethernet1
Camp-Leaf-1/2(config-if-Et1)#description Link to AP
Camp-Leaf-1/2(config-if-Et1)#qos trust dscp

We can now inspect to see if we are sending traffic to the uplink using different traffic classes:

Camp-Leaf-1/2(config-if-Et1)#show int e24 counters queue detail:
Port     TxQ   Counter/pkts      Counter/bytes      Drop/pkts         Drop/bytes
------- ----   ------------       ------------   ------------       ------------
Et24     UC0              0                  0              0                  0
Et24     UC1          10181            3179373              0                  0            ## Default queue
Et24     UC2              0                  0              0                  0
Et24     UC3              0                  0              0                  0
Et24     UC4            480             250717              0                  0            ## Business data queue
Et24     UC5              0                  0              0                  0            ## Voice queue
Et24     UC6              0                  0              0                  0            ## Network control queue
Et24     UC7              0                  0              0                  0
Et24     UC8            206              38190              0                  0
Et24     MC0              0                  0              0                  0

While wokring on the access switches, remember to configure the DSCP trust on the uplink interfaces as well. This will ensure we honour the markings sent from the Campus Core:

Camp-Leaf-1/2(config-if-Et1)#interface Ethernet24
Camp-Leaf-1/2(config-if-Et1)#description Link to Campus Core
Camp-Leaf-1/2(config-if-Et1)#qos trust dscp


Now that we are have completed the QoS for the business data queues on the Campus Leafs (take note that unmarked traffic will fall into the default queue), lets trust the DSCP markings on the interfaces connecting to the Campus Leafs:


Campus-Core(config-if-Et1-2)#show ac
interface Ethernet1
   description Link to Campus Switch 1
   qos trust dscp
interface Ethernet2
   description Link to Campus Switch 2
   qos trust dscp
interface Ethernet5
   description Link to FW-CORE
   qos trust dscp

Campus-Core#show int e1 counters queue detail | nz
Port     TxQ         Counter/pkts           Counter/bytes      Drop/pkts            Drop/bytes
-------    ----          ------------       ------------   ------------          ------------
Et1      UC0              0                  0              0                    0
Et1      UC1            162              12950              0                    0
Et1      UC2              0                  0              0                    0
Et1      UC3              0                  0              0                    0
Et1      UC4            834             234022              0                    0
Et1      UC5              0                  0              0                    0
Et1      UC6              6                508              0                    0
Et1      UC7              0                  0              0                    0
Et1      UC8           1356             171888              0                    0
Et1      MC0              0                  0              0                    0


Now we should be able to see the conferencing applications being correctly classified and forwarded on the various switches in the network. For testing purposes, we will be using a traffic generator to send DSCP marked packets to the access switches. Another alternative is to force the marking and Traffic Class of the traffic using a policy map. An example is given below:


policy-map type quality-of-service remark
   class class-default
      set dscp 46
      set traffic-class 5
interface Ethernet2
   description Link to simulated IP Phone
   service-policy type qos input remark


Let’s inspect the various points in the network to confirm we are seeing the different traffic being tagged.


Campus Leaf 1 (simulated VOIP client and wifi client) – uplink port:


Camp-Leaf-1(config-if-Et2)#show int e24 counters queue detail | nz

Port     TxQ   Counter/pkts      Counter/bytes      Drop/pkts         Drop/bytes
------- ----   ------------       ------------   ------------       ------------
Et24     UC1         129511          143210091              0                  0 ## Default queue
Et24     UC4          25222           16168647              0                  0 ## Business data queue
Et24     UC5         292453          443060302              0                  0 ## Voice queue
Et24     UC6              1                 70              0                  0 ## Network control queue
Et24     UC8             12               2232              0                  0
Et24     MC1            153              13525              0                  0
Et24     MC5             12               1608              0                  0
Et24     MC6             37               3174              0                  0


Lets ensure the traffic is being sent to the client correctly on ethernet 1 and 2 (ethernet 1 being the AP with a connected device sending and receiving best effort and business data traffic., ethernet 2 being the simulated IP phone sending and receiving voice traffic)


Camp-Leaf-1#show int e1-2 counters queue detail | nz

Port     TxQ   Counter/pkts      Counter/bytes      Drop/pkts         Drop/bytes
------- ----   ------------       ------------   ------------       ------------
Et1      UC0            683             333241              0                  0
Et1      UC1         239301          281925398              0                  0 ## Default queue
Et1      UC2             48              18409              0                  0
Et1      UC4          11894            9965463              0                  0 ## Business data queue
Et1      UC6             12               1272              0                  0
Et1      UC8            118              15046              0                  0
Et1      MC1           3145             206351              0                  0
Et1      MC5              6                804              0                  0
Et1      MC6             44               3784              0                  0

Port     TxQ   Counter/pkts      Counter/bytes      Drop/pkts         Drop/bytes
------- ----   ------------       ------------   ------------       ------------
Et2      UC5          89156          134807160              0                  0 ## Voice queue
Et2      UC8            119              15133              0                  0
Et2      MC1           3257             219158              0                  0
Et2      MC6             44               3784              0                  0


As seen in the output above, the traffic is being classified as expected. On ethernet 1, the end device is on a conference call and sending traffic in traffic class 4. All other traffic unclassified traffic, for example background steaming, browsing, etc is being sent out as traffic class 1.

The simulated IP phone is sending traffic with a DSCP marking of 46, and will be put into traffic class 5 as expected.

Testing the QoS in a congested environment

To simulate a congested environment, we can apply interface shapers to a port to determine what happens when a port is congested. We will be shaping to 10Mbps on the uplink port of Campus Leaf 1, as well as the downlink port of Campus Core as illustrated in the diagram below:


While testing the following traffic will flow:

  • 5Mbps of voice traffic (This traffic should never drop, except if the routing protocols require the bandwidth)
  • A video call on a conferencing application – Around 0.5 to 3Mbps (this traffic should get priority over any other best effort applications)
  • Other best effort applications running in the background (streaming services, speedtest etc, these service should get whatever is left of the 10Mbps)

Switch shaping configuration

Campus-Core(config-if-Et1)#show ac
   interface Ethernet1
   description Link to Campus Switch 1
   qos trust dscp
   shape rate 10000

Camp-Leaf-1/2(config-if-Et24)#show ac
   interface Ethernet24
   description Link to Campus Core
   qos trust dscp
   shape rate 10000

Doing a speedtest while the other application should provide a result that is less than at least less than 5Mbps:

From the figure above we can safely presume the conference call is using around 3Mbps downstream and 2Mbps upstream, seeing that we know the “voice” call is using a constant 5Mbps.

The drops should also be reflected on egress from the campus switch for upload traffic, and on egress from the Core switch for Download traffic:


Campus-Leaf-1(config)#show int e24 counters queue detail | nz
Port     TxQ   Counter/pkts      Counter/bytes      Drop/pkts         Drop/bytes
------- ----   ------------       ------------   ------------       ------------
Et24     UC0              4                256              0                  0
Et24     UC1          21892           15643711           1119            1640176
Et24     UC4          53375           47964047              0                  0
Et24     UC5         316885          262914625              0                  0
Et24     UC8             19               3933              0                  0
Et24     MC1            289              39637              0                  0
Et24     MC5             17               2632              0                  0
Et24     MC6             57               4902              0                  0

Campus-Core(config-if-Et1)#show int e1 counters queue detail | nz

Port     TxQ   Counter/pkts      Counter/bytes      Drop/pkts         Drop/bytes
------- ----   ------------       ------------   ------------       ------------
Et1      UC0           2938             700560              0                  0
Et1      UC1         117758           70229186           1007            1415413
Et1      UC2           1243             315314              0                  0
Et1      UC4          76028           83432090              0                  0
Et1      UC5         189583          160237819              0                  0
Et1      UC8            561              72083              0                  0
Et1      MC1          14713             946868              0                  0
Et1      MC6            108               9332              0                  0

Note: These features may vary according to the hardware platforms. Please check the datasheet/manual to confirm the available features.

Related Information: https://www.arista.com/en/um-eos/eos-quality-of-service



  • For users connecting directly to the switch, the built-in Deep Packet Inspection (DPI) from the Arista APs cannot be used and marking will need to occur on the application (ensure that the conferencing applications change the DSCP values in packets accordingly) or using ACLs to identify and mark packets correctly.
  • The defined QoS must be enforced network wide. If any device or hop in the network doesn’t classify the traffic correctly, or even worse, removes the marking (either CoS or DSCP values), the QoS will not apply to that point and traffic will be treated as best effort. It is highly recommended to ensure higher priority traffic is marked and classified correctly throughout the network. An excellent example here is the conferencing application traffic that left through the firewall to the internet. There is no guarantee that it will come back marked.

Get every new post on this blog delivered to your Inbox.

Join other followers: