Summary: Mastering Arista EOS QoS isn’t just about memorizing CLI commands; it’s about protecting your critical traffic when the buffers get hammered. Here is a battle-tested guide to classification, queue mapping, and priority handling that goes beyond the manual.

Configuring Arista QoS: Stopping the Jitter Before the CTO Calls You

I still remember the first time I realized how crucial QoS actually was. I was a junior admin, and we had just migrated our storage backend to a new array. It was 10:00 AM on a Tuesday. Marketing was uploading 4K video assets to fs-01-prod, and suddenly, the VoIP phones in the executive wing started sounding like robots trapped in a blender. Packet drops. Jitter. It was a mess.

I spent an hour looking at interface counters before realized: my shiny new Arista switches were treating the CFO’s conference call with the exact same priority as a YouTube upload. In the trenches, we call this “equality,” but in network architecture, equality is the enemy of performance. If you are reading this, you probably just realized that default settings don’t cut it in a converged network.

The “Why”: It’s All About the Buffers

Here is the root of the problem: Switch buffers are finite. When you have a microburst—like a backup job hitting backup-srv-02 or a vMotion event—the interface buffer fills up instantly. By default, Arista EOS (and most vendors, honestly) operates on a FIFO (First-In, First-Out) basis for unclassified traffic.

When the buffer is full, the switch has to make a choice: drop the next packet, or queue it. Without QoS, it drops whatever arrives next. If that happens to be a UDP voice packet, you get audio artifacts. If it’s a TCP packet for a database transaction, you get retransmissions and latency spikes. We need to tell the switch that some packets are royalty and others are peasants.

Solution 1: The Quick Fix (Trusting the Edge)

If you are in a rush—maybe the phones are glitching right now—and you trust your endpoints (like IP phones or properly configured servers) to mark their own packets, you can simply tell the interface to trust the incoming DSCP or CoS values.

This assumes your VoIP phones are already sending traffic marked as DSCP 46 (EF) or CoS 5. This is the “set it and forget it” method for edge ports.

Configuration:

! Enter interface configuration mode for your edge port
interface Ethernet12
   description UPLINK_TO_VOIP_VLAN
   ! Trust the DSCP value sent by the device
   qos trust dscp
   ! Alternatively, if you use Layer 2 tagging:
   ! qos trust cos

Pro Tip: Only do this on ports where you control the device. If you put qos trust dscp on a user’s laptop port, they can technically tag their BitTorrent traffic as “Critical Voice” and hog your bandwidth. I’ve seen it happen.

Solution 2: The Permanent Fix (MQC Class & Policy Maps)

This is the “Architect” way to do it. We don’t trust; we verify and classify. We are going to use the Modular QoS CLI (MQC) structure. This involves three steps: Class Maps (identify the traffic), Policy Maps (tell the switch what to do with it), and Service Policy (apply it to the port).

In this scenario, we are explicitly matching VoIP traffic (EF/DSCP 46) and ensuring it gets mapped to a high-priority traffic class.

Configuration:

! Step 1: Define the Class Map
class-map type qos match-any CLASS-VOICE
   match ip dscp 46
   match ip dscp 40

! Step 2: Define the Policy Map
policy-map type qos POLICY-EDGE-IN
   class CLASS-VOICE
      ! Map this to Traffic Class 5 (High Priority Queue)
      set traffic-class 5
   ! Catch-all for everything else
   class class-default
      set traffic-class 0

! Step 3: Apply to the Interface
interface Ethernet48
   description UPLINK_TO_CORE
   service-policy type qos input POLICY-EDGE-IN

This ensures that no matter how hard db-worker-04 hammers the link, the voice traffic is sorted into a VIP lane immediately upon entering the switch.

Solution 3: The ‘Nuclear’ Option (Strict Priority Queuing)

Sometimes, shaping and bandwidth reservation aren’t enough. You have a link that is constantly saturated, and you need to guarantee that voice traffic never waits. Period.

We can configure a specific queue to be “Strict Priority.” This means the switch will always empty this queue before touching anything else. Be careful: if you misconfigure this and pump 10Gbps of traffic into the strict priority queue, you will starve every other application on the network to death.

Arista handles this by mapping traffic classes (tc) to output queues (mc/uc). Here is how we enforce strict priority for our voice traffic (which we mapped to TC 5 in the previous step).

Configuration:

! Map Traffic Class 5 to Output Queue 5 (Multicast/Unicast)
qos map tc 5 to mc-queue 5 uc-queue 5

! Configure Interface Queues
interface Ethernet48
   ! Set Queue 5 to Strict Priority
   tx-queue 5
      priority strict
   
   ! Set Queue 0 (Data) to Round Robin (Best Effort)
   tx-queue 0
      bandwidth percent 50

This is somewhat hacky because it overrides the nuanced weighted round-robin algorithms, but when latency is killing your app, sometimes you have to bring out the big guns.

A Quick Note on Hardware

Don’t wait for the scream test to configure this. Take an hour during your next maintenance window and get your tagging sorted out. Your future self (and your CTO) will thank you.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions