QoS queueing on Cisco Catalyst switches is what happens after traffic has already been classified and marked. During congestion, egress queueing and scheduling determine which traffic receives bandwidth, which traffic receives priority treatment, how much buffering is available, and which packets are dropped first. On Catalyst 9000 platforms such as the Catalyst 9300, current IOS XE QoS supports bandwidth allocation, priority queues, queue buffers, Weighted Tail Drop (WTD), and other congestion-management features through Modular QoS CLI policy.<\/p>\n
Within Cisco Network Engineering<\/a>, queueing is a capacity-sharing decision, not a marking exercise. The existing QoS queueing basics<\/a> article provides the conceptual foundation; this page focuses on Catalyst behavior and troubleshooting.<\/p>\n Current Catalyst 9300 documentation notes that wired interfaces have default queues even without a custom policy, with control traffic receiving special treatment. Custom policy changes that behavior, so engineers should know the defaults before adding a complex queuing design.<\/p>\n Egress queues make decisions based on fields such as DSCP, CoS, QoS group, class-map matching, or policy actions depending on platform and design.<\/p>\n If the access edge trusts unvalidated endpoint markings, ordinary user traffic can claim a high-priority class. If the network remarks everything to default, carefully designed egress queues never see the distinctions the policy expected.<\/p>\n Define trust boundaries first: which devices are trusted to mark, where traffic is classified, and where markings are rewritten.<\/p>\n Current Catalyst 9300 IOS XE documentation describes two default wired egress queues on each interface when no explicit QoS policy is applied, with control traffic treated separately from ordinary traffic.<\/p>\n That means output drops can occur within default buffering even before an engineer creates a custom service policy.<\/p>\n Use platform-specific queue counters and documentation rather than assuming a legacy Catalyst queue model or textbook queue count applies to the device in front of you.<\/p>\n Strict\/priority queueing is appropriate for traffic such as real-time voice when delay and jitter requirements justify it.<\/p>\n Priority should not be assigned to every \u201cimportant\u201d business application, because too much strict-priority traffic can starve ordinary queues during congestion.<\/p>\n Police or bound priority traffic according to design so one misclassified or abusive flow cannot consume the entire egress service rate.<\/p>\n Bandwidth allocation determines how scheduler service is divided among classes when the interface is congested.<\/p>\n The configured percentages or remaining-bandwidth logic should reflect actual business traffic mixes and interface speed.<\/p>\n Queue allocation is not a reservation of physical link capacity while the interface is uncongested; it becomes relevant when several classes compete for a limited egress resource.<\/p>\n Current Catalyst 9300 guides describe WTD as an enhanced tail-drop mechanism where frames associated with different threshold classes can be dropped at different queue depths.<\/p>\n This lets one traffic category begin dropping earlier while another can consume more of the queue.<\/p>\n WTD should be tuned using actual queue counters and burst behavior. A threshold that is too small causes avoidable drops; one that is too large can increase latency and buffer occupancy.<\/p>\n Switch ASICs have finite packet buffers distributed across interfaces\/queues according to platform architecture.<\/p>\n Microbursts can overflow an egress queue even when average interface utilization looks low, especially when many ingress ports converge on one lower-speed egress link.<\/p>\nClassification and marking must be trustworthy before queueing can work<\/h3>\n
Default queue behavior matters during troubleshooting<\/h3>\n
Priority queues should be reserved for traffic that cannot tolerate delay<\/h3>\n
Bandwidth commands express sharing among nonpriority classes<\/h3>\n
Weighted Tail Drop creates different drop thresholds inside a queue<\/h3>\n
Buffers are shared resources, not infinite protection<\/h3>\n