ArubaOS-CX QoS Trust and Queue Profiles Guide

ArubaOS-CX splits QoS into four pieces that are applied with a single activation command, and that structure is exactly what makes it portable across a fleet: define how ingress packets get a local priority, define how local priorities map to queues, define how queues are scheduled, then apply both profiles at once. This guide walks that configuration order with real CLI, explains the override behaviour between global and per-interface trust settings, and covers the verification commands that show which profile an interface is actually using.

Step 1: assign local priority on ingress

switch(config)# qos trust dscp
switch(config)# qos dscp-map 46 local-priority 5
switch(config)# qos cos-map 5 local-priority 5

switch(config)# interface 1/1/1
switch(config-if)# qos trust cos
switch(config-if)# exit

Trust mode decides which header is believed. qos trust dscp set globally applies to every interface that has no override; configuring qos trust cos on an individual interface overrides the global setting for that port only, and the only way to remove the override is a no qos trust on that interface. Trust none is the default and the safer choice on access ports facing endpoints you do not control, where the switch should classify by policy rather than believe the host.

Step 2: map local priority to queues

switch(config)# qos queue-profile Q1
switch(config-queue)# name queue 5 VOICE
switch(config-queue)# map queue 0 local-priority 0
switch(config-queue)# map queue 1 local-priority 1
switch(config-queue)# map queue 1 local-priority 2
switch(config-queue)# map queue 2 local-priority 3
switch(config-queue)# map queue 3 local-priority 4
switch(config-queue)# map queue 4 local-priority 5
switch(config-queue)# map queue 5 local-priority 6
switch(config-queue)# map queue 5 local-priority 7
switch(config-queue)# exit

Every local priority from 0 to 7 must be mapped, and the queues you use must be contiguous starting at 0. That constraint is deliberate - it keeps the egress scheduler's assumptions explicit instead of leaving gaps that behave differently per ASIC.

Step 3: schedule the queues

switch(config)# qos schedule-profile S1
switch(config-schedule)# strict queue 5
switch(config-schedule)# dwrr queue 0 weight 5
switch(config-schedule)# dwrr queue 1 weight 10
switch(config-schedule)# dwrr queue 2 weight 15
switch(config-schedule)# dwrr queue 3 weight 20
switch(config-schedule)# dwrr queue 4 weight 25
switch(config-schedule)# exit

Deficit weighted round robin allocates bandwidth in proportion to weights among non-strict queues; strict queues are served first and can starve the rest if they carry too much traffic. Reserve strict treatment for a queue whose traffic is genuinely bounded - voice or PTP - and keep everything else on DWRR.

Step 4: activate

switch(config)# apply qos queue-profile Q1 schedule-profile S1

Nothing in steps 2 and 3 takes effect until this command runs. Applying a schedule profile to a single interface is possible for overrides, but the common design is one queue profile and one schedule profile applied globally so that every port is consistent - which is what makes configuration automation straightforward.

Verification

switch# show qos trust
switch# show interface 1/1/1 qos
switch# show qos queue-profile Q1
switch# show qos schedule-profile S1
switch# show interface 1/1/49 queues

show interface ... qos is the decisive command: it prints the effective trust mode (including whether it is an override), the queue profile and the schedule profile in force for that port. When a port behaves as though QoS is unconfigured, this output normally shows either a leftover per-port trust override or a global trust of cos where dscp was intended.

Interaction with remarking

Port remarking and trust are mutually exclusive in practice. CX emits a warning if remarking is configured on a port and the trust mode is then set to cos or dscp - and the remark configuration is not applied. Set trust to none if you want the remark to take effect, or remove the remark if you want to honour incoming markings.

Related: ArubaOS-CX VSF stacking and VSX active-active configuration for the HA designs these QoS profiles are deployed onto.

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.15/HTML/qos_5420-6200-6300-6400/Content/Chp_Config/cnf-qos-10.htm