H3C CR16000系列路由器，qos policy限速策略

这个应该还和板卡有关吧，可以找个接口测试一下看看，或者手册看下是否有说明，得对应版本型号的才行

https://www.h3c.com/cn/d_202606/2868037_30005_80.htm

CR16000（Comware V7）核心结论
把 qos apply policy 部署在【物理主接口】，该物理口下所有子接口流量全部会匹配这条 QoS 策略（inbound/outbound 双向均生效）**。
但是存在关键边界限制、业务选型建议，下面完整说明。
一、原理说明（CR16000 官方机制）
物理主接口上应用 QoS Policy：
所有从这个物理接口进出的报文（包含所有 Dot1q 子接口、QinQ 子接口流量），统一经过主接口的 QoS 策略处理。
plaintext
interface Ten-GigabitEthernet 1/0/1
qos apply policy LIMIT_ALL outbound
✅ 1/0/1.10、1/0/1.20 … 所有子接口流量都命中该 policy 内 car 限速、重标记、镜像等动作。
重要区分两个极易混淆的概念
qos apply policy（CBQ 流策略，car 限速、流分类）
部署在物理口 → 所有子接口流量继承生效
接口原生限速：qos lr /qos gts
物理口 lr 是整端口总带宽上限，和子接口无关；属于端口队列调度层面，不是流策略。
官方文档原文要点：
进入主接口视图应用策略，作用于该接口所有流量（包含子接口）；
进入子接口视图应用策略，仅单独这一个子接口生效，互不影响。
二、两种部署方案对比（你现场业务选型重点）
方案 A：策略应用在【物理主接口】
适用场景：
所有子接口共享同一套限速规则、统一管控；只需要对物理口整体流量分类限速，不需要子接口差异化限速。
优点：配置量少、统一管控；
缺点：无法针对不同子接口单独设置不同限速规则；所有子接口流量共用一套 classifier+behavior。
举个反例：
子接口 1.10 限速 100M、子接口 1.20 限速 50M；
❌ 不能只在物理口一条 policy 实现，必须把策略分别部署到各个子接口。
方案 B：策略应用在【各个子接口】（推荐：多子接口多业务标准方案）
plaintext
interface Ten-GigabitEthernet 1/0/1.10
qos apply policy POLICY_VLAN10 outbound
interface Ten-GigabitEthernet 1/0/1.20
qos apply policy POLICY_VLAN20 outbound
优点：每个三层子接口独立策略，不同 VLAN / 业务可独立限速、独立统计；
缺点：配置条目更多。
三、非常关键的优先级叠加规则（现场极易踩坑）
如果物理主接口 + 某个子接口同时都配置了 qos apply policy
报文同时命中两套策略，先后执行：先主接口策略，再子接口策略。
⚠️ 风险：两次 car 限速叠加，容易出现意想不到的双重限速，不建议混合部署。
规范做法二选一：
全部部署在物理口；
全部部署在子接口；不要混配。
四、验证命令（上线后确认策略是否匹配子接口流量）
plaintext
#查看物理接口下应用策略的统计，所有子接口流量计数汇总在这里
display qos policy interface Ten-GigabitEthernet 1/0/1 outbound

#子接口查看（如果策略只在物理口，这条看不到策略）
display qos policy interface Ten-GigabitEthernet 1/0/1.10 outbound
五、生产实施建议（直接可以回复现场）
如果所有子接口业务限速规则完全一致：
策略配置在物理主接口，简洁可行，子接口流量正常受限速；
如果不同子接口（不同业务 / VLAN）需要差异化限速：
禁止部署在物理口，必须每个子接口独立应用 qos policy；
禁止混合部署（物理口 + 子接口同时 apply policy），防止双层 CAR 叠加、带宽异常。
六、补充一个高频疑问
Q：能不能在物理口 policy 内部通过 if-match inbound-interface Ten-GigabitEthernet 1/0/1.10 区分子接口？
A：CR16000 V7 平台不支持 if-match 匹配子接口；流分类只能匹配五元组、VLAN ID、DSCP 等。
👉 需要按子接口区分流量，只能依靠 VLAN ID 匹配，或者策略绑定在子接口。
一句话极简总结
CR16000 上，qos policy 配置在物理主接口，该端口所有子接口流量都会生效；但无法区分子接口做差异化限速；多业务子接口建议将策略绑定到子接口。

可以生效，但它实现的是“聚合限速”——即限制整个物理接口的总带宽，从而间接限制该物理口下所有子接口的带宽总和，无法对单个子接口进行差异化限速。

以下是 CR16000 系列（Comware V7）上物理口 QoS 策略对子接口生效的具体行为分析和配置建议：

🔄 生效行为详解（入方向 vs 出方向）

结论：如果你的目标是“不管有多少个子接口，总出口带宽不能超过 1Gbps”，那么将 QoS 策略应用在物理口是最简洁、高效的做法。

⚠️ 关键注意事项

1. 策略中匹配流量的范围：在物理口上应用的策略，其流分类（Traffic Classifier）无法匹配到子接口的 VLAN ID（除非在规则中强行写入 vlan-id，但这在物理口视图下不推荐且容易混乱）。通常物理口策略只能匹配 IP 五元组（源/目的 IP、端口、协议）。

2. CBQ（基于类的队列）的局限性：如果在物理口配置了 queue af 或 queue ef 等队列调度，子接口的流量会混杂在同一个队列中，无法按子接口区分优先级。

3. CR16000 硬件特性：CR16000 的 QoS 是硬件转发（NP/FPGA）实现的，物理口限速直接作用在端口调度器上，对子接口流量的限速精度非常高，且不影响 CPU 性能。

🎯 如果你需要“分别限制子接口 A 和 B 的带宽”

必须将 QoS 策略直接应用在每个子接口上，而不是物理口。

示例：子接口 A 限速 100M，子接口 B 限速 200M。

（注：需为每个子接口创建独立的策略或使用不同的 cir 值）

🧪 CR16000 高级玩法：使用 HQoS（分层 QoS）实现物理口统一调度+子接口细分

如果既想把策略统一挂在物理口，又想精细控制每个子接口的带宽（例如：物理口总带宽 1G，子接口 A 保底 300M，子接口 B 保底 200M，剩余共享），CR16000 支持 HQoS（分层服务质量）。

• 配置思路：在物理口下配置 qos-profile（用户队列），通过 user-group-queue 将不同子接口的流量映射到不同的队列调度器中。

• 复杂度：配置较复杂，需要规划流分类（匹配子接口 VLAN）和调度树（调度器 + 整形器）。若非必须，不建议在普通限速场景使用，直接挂子接口更清晰。