Arista EOS Queue Counters and Congestion Troubleshooting

When an application stalls on an Arista EOS fabric, the link is up, the interface error counters are clean, and the switch reports no routing change — because the problem is not errors, it is buffer depth. Egress queue drops are invisible in show interfaces counters errors and only appear once you read the per-queue counters or arm LANZ buffer monitoring. This article shows how to read queue statistics, how to catch the congestion event while it is happening, and how to tell a microburst from sustained oversubscription.

Why queue drops are different from interface errors

Interface error counters count malformed or dropped frames on the wire: CRC, alignment, runts. Queue counters count frames the switch itself decided not to transmit because the egress buffer for a traffic class was full. Both produce an application-visible stall, but only one of them tells you to change your QoS design. A switch can carry a perfectly clean link and still drop 4 % of a storage flow's packets in a single burst.

Reading per-queue statistics

switch# show interfaces counters errors
switch# show queue counters
switch# show queue counters Ethernet1
switch# show queue counters Ethernet1 | nz
switch# show qos maps

show queue counters prints transmitted and dropped packets and bytes per queue, per interface, with unicast, multicast and mixed-packet-type indices. The | nz filter removes zero rows so a long table collapses to the interfaces that actually have traffic on a given queue. show qos maps displays the traffic-class to transmit-queue mapping, which is what you need to translate a queue number back into a DSCP class — on Arad and Jericho platforms the egress port has sixteen physical queues split evenly between unicast and multicast.

Watching the threshold the packets died at

Knowing that queue 5 dropped is only half the answer; you also need to know how deep the queue was when it dropped. queue-monitor length arms buffer-depth monitoring per interface and per traffic class, and show queue-monitor length reports the maximum queue length reached during each congestion event:

switch(config)# queue-monitor length
switch(config)# interface Ethernet2
switch(config-if-Et2)# queue-monitor length threshold 512 256
switch# show queue-monitor length
switch# show queue-monitor length drops
switch# show queue-monitor length tx-latency

Three outputs to use together: show queue-monitor length gives the congestion duration and maximum queue length, show queue-monitor length drops gives a per-interface drop count per event, and show queue-monitor length tx-latency converts buffer occupancy into the latency a packet experienced while it waited. If a storage flow is missing its deadline, tx-latency is the number that explains the application problem better than any packet counter.

Is it a microburst or is the link oversubscribed?

• Short congestion events, deep queues, few drops — microbursts. The average utilisation is low but instantaneous bursts exceed the egress rate. Fix with a bigger buffer allocation, ECN, or spread the flow with ECMP/port-channel hashing.
• Long congestion events on the same queue, drops climbing steadily — sustained oversubscription. Measure the egress traffic against the port rate; a 100G uplink carrying a 4:1 fan-in of 25G access ports will congest under storage replication.
• Drops on the control queue — something is sending protocol traffic faster than it should. Check for a routing loop or a misconfigured BFD/LLDP interval before touching QoS.

switch# show interfaces counters rates
switch# show interfaces Ethernet1 rates
switch# show interfaces counters queues Ethernet1

Adding ECN instead of dropping

On EOS, ECN is configurable independently on every egress queue of every Ethernet interface, and the setting is applied per member interface for a port channel. Average queue length is tracked for transmit queues, so congestion can be signalled by marking rather than dropping — the correct behaviour for RoCEv2 and loss-sensitive storage traffic. Combined with per-queue counters, you can prove the marking worked: ECN-marked packets are transmitted, and the drop counter stops climbing.

A practical troubleshooting order

1. show interfaces counters errors — rule out a physical problem first.
2. show queue counters with | nz — find the port and queue carrying the drops.
3. show qos maps — convert the queue index into a traffic class and DSCP.
4. Arm queue-monitor length and re-run the failing workload to capture the congestion profile.
5. Decide: shape the source, mark with ECN, widen with ECMP, or reschedule the workload.

See also: Arista EOS interface error counters, enabling sFlow on Arista EOS, and WRED vs tail drop congestion avoidance.

原文链接：https://www.arista.com/docs/Manuals/QuickStart-Managing7150Series.pdf