H3C Comware QoS: Priority Trust and Mapping Explained

2026年9月21日 LOG admin

H3C Comware prioritises traffic in a specific order that is easy to get wrong: the switch first decides whether to trust a frame's priority marking at all, then maps that marking to an internal priority, and finally serves the internal priority from a queue. If any of those three steps disagrees with the markings your phones and servers send, QoS silently does nothing. This article shows the Comware priority model, the trust-mode commands that drive it, and the display commands that prove the mapping is what you intended.

The Comware priority pipeline

Ingress classification — the port either trusts the incoming marking or applies its own port priority.
Mapping — the incoming value (802.1p CoS or DSCP) is translated to an internal priority value.
Queuing and scheduling — the internal priority selects one of the eight queues, which are served per the configured schedule (WRR, SP, or a hybrid).
Egress remarking — optionally the CoS/DSCP is rewritten before the frame leaves, which is how you normalise markings between domains.

Trust mode: the first decision

<H3C> system-view
[H3C] interface GigabitEthernet 1/0/1
[H3C-GigabitEthernet1/0/1] qos trust dot1p
[H3C-GigabitEthernet1/0/1] quit

[H3C] interface GigabitEthernet 1/0/2
[H3C-GigabitEthernet1/0/2] qos trust dscp

Choose per port role, not globally:

Port role	Typical trust setting	Reason
IP phone / access port	`qos trust dot1p`	Phones mark voice with 802.1p CoS 5 or 6
Server / routed uplink	`qos trust dscp`	Servers and routers mark at L3
Untrusted access port	No trust (default) + port priority	Prevents users from claiming voice priority
Uplink to the core	Trust the internal domain's convention	Preserves the markings you already established

Check the effective setting before trusting anything:

[H3C] display priority-trust
[H3C] display qos trust interface GigabitEthernet 1/0/1

Port priority and the CoS mapping tables

[H3C] interface GigabitEthernet 1/0/10
[H3C-GigabitEthernet1/0/10] qos priority 0
[H3C-GigabitEthernet1/0/10] quit

[H3C] display qos map-table dot1p-lp
[H3C] display qos map-table dscp-lp

Port priority applies to frames that arrive untagged or untrusted — it is the fallback bucket. On the map tables themselves, Comware ships sensible defaults: CoS 5 and 6 map to high internal priority, CoS 0 to best effort. Only change these when you have a documented marking plan; ad-hoc edits here are a common source of "the network ignores my DSCP" complaints.

Queue scheduling

[H3C] interface GigabitEthernet 1/0/1
[H3C-GigabitEthernet1/0/1] qos wrr 5 weight 30
[H3C-GigabitEthernet1/0/1] qos wrr 0 weight 10
[H3C-GigabitEthernet1/0/1] qos sp 7
[H3C-GigabitEthernet1/0/1] quit

A hybrid schedule is standard practice: strict priority for the control and voice queues (7 and 6), weighted round robin for everything else so best-effort traffic cannot be starved indefinitely. Queue 7 in strict priority should carry only a small fraction of the total — typically under one percent — or one misbehaving sender can starve every other queue.

Verification

[H3C] display qos trust interface GigabitEthernet 1/0/1
[H3C] display qos queue-statistics interface GigabitEthernet 1/0/1
[H3C] display qos queue interface GigabitEthernet 1/0/1
[H3C] display qos map-table
[H3C] display interface GigabitEthernet 1/0/1

Queue statistics are where the truth lives. If the voice queue counter stays at zero while calls are running, the trust mode or mapping is wrong no matter what the configuration says.

Common Comware QoS mistakes

Trusting everything on user ports — a user can mark their traffic as priority 7 and dominate the strict-priority queue.
Trusting nothing on the uplink — the switch strips the marking at the boundary and QoS disappears one hop before the WAN.
Changing map tables on one switch only — an inconsistent fabric reclassifies traffic unpredictably at each hop.
Confusing port priority with port rate limiting — qos priority sets a marking, not a bandwidth cap.
Assuming default queues are per-port — on many Comware platforms, queue configuration is per-port but counters need a per-port display to be meaningful.

Migration note for multi-vendor teams

Comware's display family is much closer to Huawei VRP than to Cisco IOS, while the configuration grammar (system-view, quit, interface) is nearly identical to Huawei's. For teams operating both, keep the command mapping handy — the QoS concepts are the same, but the verification commands differ enough that muscle memory produces errors. A side-by-side comparison of the two command sets is in the related articles below.

Verifying QoS is actually working

Configuration review is not verification. Three checks prove that priority handling is live on a Comware switch, in increasing order of confidence:

Read the effective trust mode. display qos trust interface confirms what the port does with incoming markings, not what you intended.
Read the queue counters. Send known traffic and watch the per-queue packet counts. Voice-like traffic must increment the high-priority queue; if only the best-effort counter moves, the mapping is wrong.
Read the map tables. display qos map-table prints the actual CoS/DSCP to internal priority relations. A switch that was previously customised may not match the documented defaults.

[H3C] display qos queue-statistics interface GigabitEthernet 1/0/1
[H3C] display qos map-table
[H3C] display qos trust interface GigabitEthernet 1/0/1
[H3C] reset counters interface GigabitEthernet 1/0/1

Reset the counters immediately before the test, otherwise historic traffic masks the result. On busy access ports, generate the test traffic deliberately — a synthetic flow with the expected marking is far more conclusive than observing live traffic and guessing.

QoS design checklist for a Comware network

Define the marking plan first. Which applications get which DSCP or CoS values, documented in one page. Without it, every device becomes an island.
Trust at the edge, enforce in the core. Trust markings on ports connected to devices you control; do not trust unmanaged user ports.
Keep strict priority minimal. Only control and real-time voice belong in the strict-priority queue.
Verify at the boundary. The point where your network meets a carrier is where markings are most often dropped or rewritten.
Test under congestion. QoS does nothing on an uncongested link; validate with a saturated uplink.
Document the queue mapping per platform. Queue count and default mapping vary between Comware switch families, so a design copied from a datasheet may not match the hardware.

验证 QoS 是否真正生效

配置检查不等于验证。在 Comware 交换机上，三层手段由弱到强地证明优先级处理真的在工作：

读取实际信任模式：display qos trust interface 显示的是端口对入向标记的实际处理方式，而不是你希望的处理方式。
读取队列计数：发送已知标记的流量，观察各队列的报文计数。语音类流量必须让高优先级队列计数增长；若只有尽力而为队列在动，映射就是错的。
读取映射表：display qos map-table 打印实际的 CoS/DSCP 到内部优先级的对应关系。被前任工程师改过的设备，未必与文档中的默认值一致。

测试前先执行 reset counters interface，否则历史流量会掩盖结果。在繁忙的接入端口上，最好主动构造带目标标记的测试流，而不是靠观察现网流量猜——后者无法区分"没生效"与"刚好没有该类流量"。

QoS 设计原则与常见反模式

先定标记方案：哪些应用使用哪个 DSCP 或 CoS 值，写在一页文档里。没有它，每台设备都会成为孤岛。
边缘信任、核心执行：对自己可控的设备端口信任标记；对接入的非受管用户端口一律不信任。
严格控制队列保持极小：只有控制协议与实时语音才应进入严格优先级队列，否则单个异常发送方会让其他队列完全饿死。
在边界验证：与运营商互联的接口是标记最容易被丢弃或改写的位置。
在拥塞下测试：链路不拥塞时 QoS 什么也不做，用打满的上行口验证才有意义。
按平台记录队列映射：不同 Comware 系列的队列数与默认映射不同，照抄数据手册的设计可能和实际硬件不匹配。