华为H3C实战 | 第35章 BRAS 用户策略与 QoS

📚 本系列共 43 篇（第 35 / 43 篇）　·　第五卷 BRAS 与认证计费篇 —— 大规模用户接入

← 上一篇：第 34 章 IPoE 接入与 Web/Portal 认证 　下一篇：第 36 章 BRAS 排错专题 →

本章导读：前三章解决"能不能上网"，本章解决"上得爽不爽、守不守规矩"。限速、优先级、ACL、计费策略、多播副本这些事，多数不是你手工敲在 BRAS 上，而是认证通过后由 RADIUS 下发。

本章结构：

• 35.1 功能原理与业务场景 —— 上下行限速到底限在哪（别看反）、CAR 与 Shaping 的区别、用户组与优先级、属性驱动策略的整体模型
• 35.2 华为设备配置详解 —— 用户限速、用户组、ACL 下发、优先级与计费策略的配置模板
• 35.3 H3C 设备配置详解 —— H3C 侧写法与差异标注
• 35.4 华为 / H3C 命令对照表
• 35.5 配置验证 —— 用户策略是否真的挂上了、限速值对不对
• 35.6 排错与故障树 —— “限速不生效"“上下行反了"“策略没挂上"的分支定位
• 35.7 新手踩坑与注意事项
• 35.8 本章小结

重点提示：用户投诉"下载很慢上传很快”，基本就是把上下行限速配反了，回 35.1.2 的图对一遍再改；改完 BRAS 发现没生效，先查 RADIUS 有没有下发对应属性——这是本章和第 33 章最容易串的地方。 关联章节：RADIUS 授权属性与域配置见第 33 章；ACL 基础写法见第 17 章；BRAS 会话模型见第 31 章；限速不生效的深度排查见第 36 章 36.7。

35.1 功能原理与业务场景

35.1.1 这功能是干嘛的（通俗版）

前三章解决的是「用户能不能上网」，本章解决的是「上网上得爽不爽、守不守规矩」。

把 BRAS 想成高速公路收费站 + 服务区管理：

• 限速：你买的是「100M 宽带」，那就只能给你 100M 的车道宽度，别想挤占别人的。
• 优先级：救护车（语音、视频会议）优先通过，普通车（下载）排队。
• ACL：有些路段对某些车禁行（学生不能访问游戏网站）。
• 计费策略：按里程（流量）或者按时段（时长）收费。
• 多播副本：学校要直播一场讲座，一份数据只传一次，到分叉口再复制（IPTV、远程教学）。

这些功能统称「用户策略」（user policy），技术上归到 QoS（服务质量，Quality of Service）和访问控制的范畴。关键认知：这些策略绝大多数不是你在这台 BRAS 上手工敲的，而是由 RADIUS 认证通过后「下发」给 BRAS 的。 这就是第 33 章讲的「属性驱动」的具体落地。

35.1.2 限速到底限在哪：上下行的真实位置

这是新手最容易搞错的一件事，必须先讲清楚：

   用户 ──────→ BRAS ──────→ 核心 ──────→ 互联网
       上行          上行            上行
   （用户发出去的）（一直往上游走）

   互联网 ──────→ 核心 ──────→ BRAS ──────→ 用户
                        下行          下行
                   （一直往下游走）

在 BRAS 上看：

这就是为什么装宽带常说「300M 下行、30M 上行」——两个方向是分别限的。

一个极易犯的错误：把上下行限速搞反。用户投诉「下载很慢、上传很快」，八成是把上下行限速配反了。

35.1.3 限速的两种技术手段：CAR 与 Shaping

同样是限速，底层有两种很不一样的做法：

   CAR（承诺访问速率，Committed Access Rate）——"警察"
   ──────────────────────────────────────────
   超速的包：直接丢弃
   优点：简单、省内存
   缺点：丢包会导致 TCP 重传，用户体验"卡顿"
   适用：入口方向（上行）限速

   Shaping（流量整形）——"减速带"
   ──────────────────────────────────────────
   超速的包：先缓存，等有空闲再发
   优点：不丢包，TCP 表现平滑
   缺点：占内存（缓存队列），延迟增加
   适用：出口方向（下行）限速

为什么上行用 CAR、下行用 Shaping？因为：

• 上行的瓶颈在用户自己那边（用户的上行口本来就只有那么多带宽），BRAS 侧直接丢超出的包，让用户端的 TCP 自己去降速，是可以的。
• 下行如果也直接丢包，用户会感觉到明显的「顿挫」（TCP 拥塞控制反复触发），体验很差。用整形先缓冲一下，平滑输出，体验好得多。

理解这一点，你就明白了为什么很多设备的「下行限速」命令叫 user-queue（用户队列）而不是 car——它在做队列调度，而不是简单计数丢包。

35.1.4 用户组（User Group）：策略的分组管理

如果每个用户都在 RADIUS 上单独配限速，管理量会爆炸。所以引入「用户组」：

   用户组 ug_teacher  → 上行 100M / 下行 500M / 高优先级
   用户组 ug_student  → 上行 20M  / 下行 100M / 普通优先级
   用户组 ug_guest    → 上行 10M  / 下行 50M  / 低优先级
   
   用户在 RADIUS 上只需要标记"属于哪个用户组"
   → BRAS 根据用户组套用整套策略

两种绑定路径：

   路径一（推荐，运营商做法）：RADIUS 下发用户组名
      认证通过 → RADIUS 返回用户组名 → BRAS 套用该组的策略
   
   路径二（简化，园区做法）：域绑定用户组
      域 isp_student → 绑定用户组 ug_student → 该域所有用户都套这套策略

路径二更适合校园网：整个宿舍区的用户都是学生，策略一样，在域里绑一次就完事，不用在 RADIUS 上给三万个账号逐个配。

35.1.5 华为与 H3C 的策略模型差异

这是本章最重要的对比，先给结论：

用一句话概括：华为用「用户组 + UCL」，H3C 用「user-profile 模板」。H3C 的模型更接近「一个模板套所有参数」，华为的模型更接近「用 ACL 精确定位用户的流量再对它做事」。

H3C 官方文档把 user-profile 的机制说得很明确：每次用户认证通过，服务器把该用户的 user-profile 名字发给设备，设备把 user-profile 里的参数应用到该用户身上。这就是「属性驱动」在 H3C 上的具体实现。

华为的 UCL 机制则是：定义一个用户 ACL（编号 6000-9999），在 ACL 里引用「源用户组」，然后用流量策略对这个 ACL 匹配的流量做限速/丢弃等动作。UCL 分四类（user-to-network、user-to-user、network-to-network、network-to-user），靠 ACL 里是否指定源/目的用户组来区分。

35.1.6 计费的三种颗粒度与限速的联动

用户策略和计费是绑在一起的，典型的联动模式：

   包月 100M 套餐
   ├── 限速：上行 30M / 下行 100M
   ├── 计费：只记时长，不按量收费
   └── 超出：无（包月不限量）

   按流量 100GB/月
   ├── 限速：上行 30M / 下行 300M
   ├── 计费：记流量
   └── 超出 100GB → RADIUS 发 CoA 改速到 10M（达量限速）

   时长套餐 300 小时/月
   ├── 限速：上行 30M / 下行 200M
   ├── 计费：记时长
   └── 超出 300 小时 → 暂停服务或降速

第三种「超出后限速」依赖于第 33 章讲的 CoA（动态授权）：服务器主动向 BRAS 发指令改策略，用户无需重拨。这是现代运营商标配的能力。

35.1.7 令牌桶：限速背后的原理（理解它才能看懂参数）

所有限速命令背后都是同一个数学模型——令牌桶（Token Bucket）。理解它，你就知道 cir、cbs、pir、ebs 这些参数到底在干什么。

   想象一个桶：
   ┌─────────────────────┐
   │  ● ● ● ● ● ●        │  桶里装"令牌"，每个令牌允许发 1 比特
   │                     │
   └──────────┬──────────┘
              │
    令牌以 CIR 的速率持续注入桶里（比如每秒注入 100000 个令牌 = 100Kbps）
              │
              ▼
    包来了，查桶里有没有足够令牌：
    ├── 够 → 拿走令牌，放行（绿色）
    └── 不够 → 按策略处理：丢弃（红色）或降优先级（黄色）

关键参数就四个：

为什么需要 cbs（桶大小）？ 如果桶很小，那么网络一旦有突发流量（比如打开网页会瞬间发很多请求），包就会因为没有令牌而被丢——用户体验反而变差。桶大一点，允许多存一些令牌，突发流量可以「借」令牌发出去，用完再慢慢还。这就是「允许突发」的机制。

一个实用的配比经验：cbs 一般设成 cir 的 1/8 到 1/4（按时间换算，大约允许 125ms~250ms 的突发）。比如 cir 100000（100Kbps），cbs 可以设 12500 左右。具体单位各单位不同，这是需要查设备文档确认的地方。

理解了令牌桶，你就能看懂下面这些常见现象：

35.1.8 队列调度：拥塞时谁先走

限速解决「不超过多少」，队列调度解决「拥塞时先发谁」。四种常见算法：

优先级用户策略用的就是 PQ 或 WFQ：

   拥塞发生时：
   
   PQ 方式：  教师队列 → 全部发完 → 才发学生队列
             （学生可能长时间得不到发送机会）
   
   WFQ 方式： 教师队列和学生队列按 3:1 的权重轮流发
             （学生也能得到 25% 的带宽，不会被饿死）

为什么大网推荐 WFQ 而不是 PQ？ 因为 PQ 在极端情况下会让低优先级用户完全上不了网，投诉会非常集中。WFQ 至少保证了一个下限。

35.1.9 计费策略的完整分类

前面简单提了三种，这里给完整分类表，因为选计费模式直接决定 BRAS 要开哪些功能：

预付费是技术上最复杂的一种：用户先充值，每次使用实时扣费，余额不足立即断网。它要求：

1. BRAS 能发中间计费报文（周期上报用量）。
2. 服务器能实时扣费。
3. 余额不足时服务器能立刻发 CoA 断线。

这三条对应三个配置点：中间计费周期、计费属性完整性、动态授权开启。任何一条没配，预付费就跑不起来——表现为「欠费了但用户还在上网」，这是运营商最不能接受的事故。

35.2 华为设备配置详解

35.2.1 命令行基础速览

华为的用户 QoS 配置分散在几个视图里，先看清结构：

# 创建用户组（系统视图）——NE40E 上是 user-group
user-group group_student

# 用户 ACL（UCL），编号 6000-9999
acl 6001
# 在 ACL 里引用用户组，关键字是 source user-group
rule 1 permit ip source user-group group_student destination any

# 流量分类器 / 行为 / 策略
traffic classifier ...
traffic behavior ...
traffic policy ...

# 把策略应用到域（域视图下的绑定命令各版本不一，以 ? 为准）
aaa
domain isp_student

35.2.2 完整配置模板：按用户组限速

下面这份是华为「按用户组限速」的完整配置，采用 UCL 方式：

第一段，创建用户组：

# 进入系统视图
system-view

# 创建学生用户组
user-group group_student

# 创建教师用户组
user-group group_teacher

# 提交
commit

第二段，定义用户 ACL（UCL）——用「源用户组」来定位用户：

# 定义学生组的用户ACL，编号必须是 6000-9999
acl 6001

# 匹配源用户组为 group_student 的 IPv4 流量
rule 1 permit ip source user-group group_student destination any

commit
quit

已核实的语法（出处：NE40E 官方配置指南原文）：用户组用 user-group 创建，UCL 规则里用 source user-group 引用。 以下是华为 NE40E V800R022C00《User Access QoS Configuration》里「Example for Configuring a UCL-based Traffic Policy」的官方原文：

[~Device] user-group group1
[~Device] acl 6001
[*Device-acl-ucl-6001] rule 1 permit ip source user-group group1 destination any

URL：https://support.huawei.com/enterprise/en/doc/EDOC1100278545/a27a6eee/user-access-qos-configuration

⚠ 一个必须澄清的坑：华为在不同产品线上这条命令不一致——NE40E/ME60（BRAS 平台）用 user-group，而 CloudEngine 交换机用 ucl-group。本书讲的是 NE40E，所以一律用 user-group。网上搜到的 ucl-group 写法多半来自交换机文档，直接抄到 NE40E 上会报错。

第三段，定义流量分类器、行为、策略：

# 流量分类器：匹配上面的用户ACL
traffic classifier cls_student operator or
if-match acl name ucl_student
commit
quit

# 流量行为：对匹配的流量做限速
traffic behavior bh_student
car cir 100000
commit
quit

单位已核实：华为官方文档《流量监管和流量整形配置》明确写明——cir 与 pir 的单位是 kbit/s，cbs 与 pbs 的单位是字节（byte）。所以 cir 100000 就是 100000 kbit/s = 100Mbps。这一条是配限速时最容易翻车的地方，务必记牢。同时注意：CAR 带宽受单板芯片能力限制，配置值超过单板最大带宽时，按单板最大带宽生效（不同单板的上限从 40Gbit/s 到 1024Gbit/s 不等）。

第四段，组装流量策略并在系统视图下应用：

# 组装流量策略：分类器 + 行为
traffic policy pol_student
classifier cls_student behavior bh_student

# 打开统计，便于事后验证策略真的生效了
statistics enable

commit
quit

# 在系统视图下应用 UCL 流量策略（这就是"应用位置"）
traffic-policy pol_student inbound
commit

已核实：应用位置与命令（这是本章最关键的一条，之前一直标待核实）

华为官方原文（《User Access QoS Configuration》→ Applying a UCL-based Traffic Policy）： 「Run the traffic-policy policy-name { inbound | outbound } command to apply a traffic policy to online users. After a UCL-based traffic policy is applied in the system view, the traffic of all online users is classified based on the corresponding UCL rule.」

所以答案是：在系统视图下用 traffic-policy <name> { inbound | outbound } 应用——不是域视图，也不是 BAS 接口视图。 出处 URL：https://support.huawei.com/enterprise/en/doc/EDOC1100278545/a27a6eee/user-access-qos-configuration

还要记住一条优先级规则（官方原文）：「When traffic policies are configured in both the system view and the interface view, on the network side, the traffic policies that are configured in the interface view take effect, whereas on the user side, UCL-based traffic policies take effect.」——即网络侧看接口视图的策略，用户侧看 UCL 策略，两者各管一边，不冲突。

验证命令也一并给出（官方示例里就是这么查的）：

display traffic policy user-defined pol_student
display traffic policy statistics ucl slot 1 inbound

第五段，用户组绑到域：

# 把用户组绑定到域（该域下所有用户自动归入这个用户组）
aaa
domain isp_student
user-group group_student
commit
quit
quit

这一条不能漏（官方原文）：「Before applying a UCL-based traffic policy to users in a user group, add the user group to a domain.」——策略在系统视图应用之后，还必须把用户组绑到域，该域的用户才真正用上这套策略。

35.2.3 逐行讲解

三个必须展开的点：

① 为什么 ACL 编号必须是 6000-9999？ 因为华为把 ACL 分成几类：2000-2999 是基本 ACL、3000-3999 是高级 ACL、6000-9999 是用户 ACL（UCL）。只有用户 ACL 才能引用用户组。用 3000 段的 ACL 去引用用户组会直接报错。

② 为什么「对 UCL 而言分类器里的 and 逻辑不生效」？ 官方文档里明确写了这一条：当为 UCL 定义流量分类器时，匹配规则之间的 and 逻辑关系不生效。这意味着你在一个分类器里写多条 UCL 匹配规则时，它们之间是「或」的关系。这直接影响策略设计——如果你想表达「用户组 A 且 目的网段 B」，不能靠分类器里的多条规则叠加，得把条件写进 ACL 里面。

③ 限速数值的单位是最大的坑。 不同命令不同版本的单位可能是 bps、Kbps、Mbps，差 1000 倍。car cir 100000 如果是 Kbps 就是 100Mbps，如果是 bps 就是 100Kbps。配错单位的结果是用户要么完全用不了、要么完全没被限，而且很难从现象反推。每次配限速，都要在配完后实测一次（用测速网站或大文件下载），确认实际速率符合预期。

35.2.4 用户优先级与多播副本

除了限速，用户策略还有两项常用能力：

用户优先级：不同用户组享受不同的调度权重。官方文档把它称为「域内用户优先级映射」（Configuring User Priority Mapping in a Domain）。高优先级用户的包在拥塞时优先转发。

   教师组 → 高优先级 → 拥塞时优先发送
   学生组 → 普通优先级 → 拥塞时排队
   访客组 → 低优先级 → 最容易受影响

基于用户的多播复制：官方文档在 BAS 接口的可选能力里明确列了「user-based multicast replication」（基于用户组播复制）。这在校园网直播、IPTV 场景非常关键——一份视频流在 BRAS 内部分叉复制给多个用户，而不是为每个用户单独推一份。

   没有多播复制：
   服务器 → 推100份 → BRAS → 100个用户（浪费100倍带宽）

   有多播复制：
   服务器 → 推1份 → BRAS内部分叉 → 100个用户（节省99倍带宽）

对校园网来说这个功能几乎是必须的——一场在线讲座几千人同时看，没有多播复制会把上行链路打爆。

35.2.5 HQoS：运营商级的层次化调度

官方文档里还有一整套 HQoS（层次化 QoS，Hierarchical QoS）的内容，包括 qos-profile、service-profile、gq-profile 等概念。这套东西面向运营商，调度层次是：

   端口级（物理接口总带宽）
     └── 用户组级（一个楼栋/一个小区的总带宽）
           └── 用户级（单个用户的带宽）
                 └── 业务队列级（一个用户内部，语音/视频/普通数据分别排队）

为什么要这么复杂？因为简单限速只能保证「单用户不超速」，但保证不了「某个楼栋的总量不超」。举例：

   一个楼栋 500 户，每户限 100M
   如果 500 户同时满速 → 上行要 50G，但上行链路只有 10G
   → 链路拥塞，所有用户体验都崩
   → 需要"楼栋级"限速，比如整个楼栋总共限 5G

HQoS 就是解决「层次化限速」的问题。本书只做概念介绍，具体配置属于运营商专项，不在本书「零基础能配」的范围内，请勿照本章内容实施 HQoS。

35.2.6 华为侧「配了不生效」的六个检查点

华为的 UCL 方案链路很长（用户组 → ACL → 分类器 → 行为 → 策略 → 应用 → 域绑定），任何一环断了策略都不生效，而且大多数环节缺失时不会有任何报错。所以给一张「不生效」的逐环检查表：

第 ⑥ 环是最高频的问题：你把用户组、ACL、分类器、行为、策略全配齐了，但忘了「把策略应用到 UCL」或者「域里没绑用户组」，结果就是所有配置都不起作用，而且设备不会有任何告警。

这个特点让华为的 UCL 比 H3C 的 user-profile 更难调试——H3C 只要 display current-configuration configuration user-profile 就能看到整个模板，一眼看出缺什么；华为要分别查五个对象。

给华为用户的实用建议：配 UCL 时，倒着配。先确定「域里要绑哪个用户组」，再倒推「这个用户组需要什么 ACL」，再倒推「ACL 要用什么规则」。倒着配的好处是每一步都知道「我配这个是给谁用的」，不会配一堆孤儿对象。

35.2.7 用户优先级在华为上的落地位置

华为把用户优先级映射放在域这一层（官方文档称为「配置域内用户优先级映射」）。这意味着：

   同一个域内的所有用户优先级相同
   → 想让教师和学生有不同优先级 → 必须放在不同域里
   → 这也是前面强调"一个业务一个域"的又一条理由

带宽可以靠用户组区分，但优先级靠域区分——这是华为模型的一个隐含约束，做方案时要提前规划好域的数量。

这张表是做华为 BRAS 方案时最该贴在墙上的：它告诉你「什么能在同域内差异化、什么必须分域」。很多方案做不下去，就是因为在同一个域里想区分优先级。

35.3 H3C 设备配置详解

35.3.1 H3C 的 user-profile 模型

H3C 的 user-profile 比华为的 UCL 方案直观得多，因为它就是一个参数模板：

   user-profile up_student
   ├── qos car inbound  ...     ← 上行限速
   ├── qos car outbound ...     ← 下行限速
   ├── qos user-queue ...       ← 用队列方式限速
   ├── qos apply policy ...     ← 套用 QoS 策略（ACL 等）
   ├── connection-limit ...     ← 连接数限制
   └── qos weight ...           ← 调度权重

官方文档对 user-profile 的描述很清楚：它定义一个用户的参数集合（比如 QoS 策略），可以在用户从不同接口接入时复用；每次用户认证通过，服务器把 user-profile 的名字发给设备，设备把参数应用到用户。

35.3.2 完整配置模板：单用户限速

下面是 H3C 单用户限速的完整配置（基于已核实的官方命令）：

# 进入系统视图
system-view

# 创建 user-profile，名字 up_100m
user-profile up_100m

# 上行（inbound）：从用户进来的流量，限 30M
# cir = 承诺信息速率
qos car inbound any cir 30000

# 下行（outbound）：发往用户的流量，限 100M
qos car outbound any cir 100000

quit

如果要用「双速」（同时限定 CIR 和 PIR，即承诺速率和峰值速率）：

# 同时限定承诺速率与峰值速率
user-profile up_dual
qos car inbound any cir 30000 pir 60000
qos car outbound any cir 100000 pir 200000
quit

cir 与 pir 的区别：

• cir（承诺信息速率）：保证给你的速率。
• pir（峰值信息速率）：允许你突发到的最高速率。

举例：cir 100000 pir 200000 表示「保证 100M、允许突发到 200M」。这适合「下载瞬间可以爆发，但长期平均不超过 100M」的场景。

35.3.3 user-queue：更平滑的限速方式

qos car 是丢包式限速；如果想要更平滑，H3C 提供 qos user-queue（基于队列的限速）：

# 用队列方式限速：下行 100M，并指定队列缓存长度
user-profile up_queue
qos user-queue cir 100000 queue-length 100
quit

qos user-queue 本质是用队列调度代替简单丢包，超出的流量先进队列，有空闲再发。这就是前面讲的 Shaping 思路。

两者的选择建议：

⚠ 版本差异：qos user-queue 命令仅部分板卡（CSPEX 除 1204 型号、CEPC 板卡）支持，且参数形式较多。请以设备 ? 与《用户 profile 配置》文档为准。

35.3.4 把 user-profile 应用到用户

配置好模板后，有两种方式让用户「用上」它：

方式一：RADIUS 下发（运营商做法，最灵活）

RADIUS 服务器在 Access-Accept 里返回 user-profile 名字，BRAS 自动套用。这是官方文档描述的机制。

   RADIUS 返回：user-profile = "up_100m"
   → BRAS 找到 name 为 up_100m 的 user-profile
   → 把其中的限速参数应用到该用户

方式二：接口应用（园区做法，最省事）

# 在接口上应用 user-profile（该接口上的用户都用这个模板）
interface GigabitEthernet3/1/1
qos apply user-profile up_100m
quit

但接口应用有严格的限制，官方文档列得很明确：

最关键的那一条：如果按接口应用 user-profile，入方向（上行）限速对 PPPoE 用户不生效。这意味着：

   你想要的：上行 30M、下行 100M
   
   按接口应用 user-profile 的实际效果：
   ├── 下行 100M  ✓ 生效
   └── 上行 30M   ✗ 不生效（对 PPPoE 用户无效！）
   
   结果：用户上行不限速，可以跑满 BRAS 上行口

这是一个非常容易踩的坑——配了看起来有效，实际只限了下行。所以 PPPoE 场景下，必须用「RADIUS 下发 user-profile」的方式，而不是接口应用。

35.3.5 用户组级限速：user-group-profile

单用户限速之外，H3C 还提供「一组用户共享一个带宽池」的能力，用 user-group-profile：

# 创建用户组 profile
user-group-profile ugp_floor1

# 这个用户组的总带宽：下行 1G
qos gts any cir 1000000

# 调度权重
qos weight 10 outbound

quit

然后把 user-profile 和 user-group-profile 关联起来：

# 在 user-profile 里关联用户组 profile
user-profile up_100m
qos user-queue user-group-profile ugp_floor1 outbound
quit

这样就形成了层次化调度：

   用户级限速：每人 100M
        ↓
   用户组级限速：整层楼（比如 50 人）总共 1G  ← 防止总量超售

这就是运营商说的「超售比」控制：50 户每户 100M，理论最大 5G，但实际只给 1G——因为 50 户不可能同时跑满。1G/5G = 20% 就是超售比。

35.3.6 session-group-profile：按 VLAN 分组的限速

还有一种分组方式——按 VLAN 分组，用 session-group-profile：

# 先在接口上定义"什么算一个会话组"（按客户VLAN区分）
interface GigabitEthernet3/1/1
qos session-group identify customer-vlan
quit

# 创建会话组 profile
user-profile up_floor type session-group
qos gts any cir 1000000
qos apply qmprofile qm_floor
quit

user-group-profile 和 session-group-profile 的功能完全一样（官方文档明确说两者实现相同功能），区别只在关联方式：

• session-group-profile：与 user-profile 一起授权给同一个在线用户时自动关联。
• user-group-profile：由 CLI 命令把 user-profile 和它关联起来。

而且一个 user-profile 不能同时关联这两种（官方文档明确限制）。选一个用就行，别两个都用。

35.3.7 连接数限制：防单用户占满会话表

除了带宽，还有一种资源需要限制——连接数。一个用户如果开了大量 P2P 下载，会占用大量会话表项，影响其他用户。

# 限制单个用户的最大连接数
user-profile up_limited
connection-limit amount 2000
quit

两个参数：

只限带宽不限连接数是不够的：一个用户用 100 个小连接做 P2P，总带宽没超，但会话表项被占了 100 个，几万人同时这么干，BRAS 的会话表就满了——表现是所有人新建连接都变慢或失败，但带宽监控看起来一切正常。这是排错时极难定位的问题。

35.3.8 ACL 下发：按用户控制访问权限

H3C 的 ACL 下发同样走 user-profile：

# 先定义一个ACL（限制访问游戏服务器网段）
acl advanced 3000
rule 0 deny ip destination 10.200.99.0 0.0.0.255
rule 10 permit ip
quit

# 定义一个QoS策略引用这个ACL
traffic classifier cls_block operator and
if-match acl 3000
quit

traffic behavior bh_block
filter deny
quit

qos policy pol_block
classifier cls_block behavior bh_block
quit

# 把策略应用到 user-profile
user-profile up_student
qos apply policy pol_block inbound
quit

注意方向：qos apply policy ... inbound 是限制「用户发出去」的流量方向，outbound 是「发给用户」的方向。限制用户访问某个网站，两个方向都要考虑——只限制上行，用户还是能收到对方发回来的数据（在建连之后）。

35.3.9 多播副本与用户策略的配合

H3C 支持 IPoE 与多播的配合（官方 BRAS 配置举例里就有「Configuring BRAS services by using PPPoE, IPoE, and multicast」的完整案例）。核心思想是：

   一份组播流进入 BRAS
        ↓
   按用户逐个复制（而不是每用户单独走一遍组播加入流程）
        ↓
   每个用户看到的是独立的流，但链路带宽只占用一份

配置层面，多播复制和用户限速是独立的两件事，可以共存——每个用户复制出来的那份流，依然受该用户的限速策略约束。

35.3.10 一个完整案例：校园网三档套餐策略

把前面所有东西串成一个实际案例。需求：一所学校，学生、教师、访客三类用户，三档策略：

H3C 侧完整配置：

# 进入系统视图
system-view

# ===== 教师策略 =====
user-profile up_teacher
qos car inbound any cir 100000
qos car outbound any cir 500000
connection-limit amount 5000
connection-limit rate 200
quit

# ===== 学生策略 =====
user-profile up_student
qos car inbound any cir 30000
qos car outbound any cir 100000
connection-limit amount 2000
connection-limit rate 100
quit

# ===== 访客策略 =====
user-profile up_guest
qos car inbound any cir 10000
qos car outbound any cir 50000
connection-limit amount 500
connection-limit rate 50
quit

学生禁游戏段的 ACL 与策略：

# 定义禁止访问的网段（示例地址，实际按需填写）
acl advanced 3010
rule 0 deny ip destination 10.200.99.0 0.0.0.255
rule 10 permit ip
quit

# 引用该ACL的QoS策略
traffic classifier cls_nogame operator and
if-match acl 3010
quit

traffic behavior bh_nogame
filter deny
quit

qos policy pol_nogame
classifier cls_nogame behavior bh_nogame
quit

# 把策略套进学生 user-profile（两个方向都要限）
user-profile up_student
qos apply policy pol_nogame inbound
qos apply policy pol_nogame outbound
quit

域与策略绑定：

# 三个域分别对应三档策略（域里只绑定认证计费与地址池，已核实的写法）
domain name isp_teacher
authentication ppp radius-scheme rs1
authorization ppp radius-scheme rs1
accounting ppp radius-scheme rs1
authorization-attribute ip-pool pool_teacher
quit

domain name isp_student
authentication ppp radius-scheme rs1
authorization ppp radius-scheme rs1
accounting ppp radius-scheme rs1
authorization-attribute ip-pool pool_student
quit

domain name isp_guest
authentication ppp radius-scheme rs1
authorization ppp radius-scheme rs1
accounting ppp radius-scheme rs1
authorization-attribute ip-pool pool_guest
quit

user-profile 是怎么绑到用户身上的？三条路都成立，官方文档都支持：

路径 ② 是已核实存在的，上面那段配置是对的。H3C 官方《AAA 配置》明确列出了该命令及其完整参数集：

# ISP 域视图下发 user-profile（已核实）
authorization-attribute user-profile up_student

# 以及同样可作为授权属性下发的会话组模板
authorization-attribute session-group-profile <name>

官方 authorization-attribute 的完整可选参数包括：acl / callback-number / idle-cut / ip / ip-pool / ipv6 / ipv6-pool / ipv6-prefix / primary-dns / secondary-dns / session-group-profile / session-timeout / subscriber-id / url / user-profile / vlan / vpn-instance。出处：H3C CR16000-F《02-AAA configuration》第 8 步「Configure authorization attributes for the local user」，URL： https://www.h3c.com/en/d_202001/1262629_294551_0.htm

官方给出的一个实用约束（原文）：「To prevent users from failing to come online, make sure the idle timeout period is longer than 24 minutes and the session timeout timer is longer than 30 minutes.」——也就是说 idle-cut 要大于 24 分钟、session-timeout 要大于 30 分钟，否则用户可能起不来。这是配授权属性时很容易踩的坑。

⚠ 路径 ③ 仍受第 34.3.4 节的限制：入方向 policing 对 PPPoE 用户不生效，所以只想靠接口应用来限上行是行不通的。

华为侧对应的思路（同样三档）：

   华为的对应实现是"三个用户组 + 三套 UCL 与流量策略"：
   
   user-group ug_teacher  → ACL 6001 → classifier/behavior(car)/policy → 域 isp_teacher
   user-group ug_student  → ACL 6002 → classifier/behavior(car)/policy → 域 isp_student
   user-group ug_guest    → ACL 6003 → classifier/behavior(car)/policy → 域 isp_guest
   
   每个域下：domain isp_xxx / user-group ug_xxx

可以看到，同样三档策略，H3C 需要 3 个 user-profile 对象；华为需要 3 组（用户组 + ACL + 分类器 + 行为 + 策略）共 15 个对象。这就是两家模型差异带来的工作量区别——H3C 胜在对象少，华为胜在每个环节都能精细控制。

这个案例最值得学的不是命令，而是「三档策略的规划方法」：

   第1步：按人群分档（教师/学生/访客）
   第2步：给每档定带宽（上行/下行）
   第3步：给每档定优先级（拥塞时谁先走）
   第4步：给每档定连接数（防资源占用）
   第5步：给每档定访问权限（ACL）
   第6步：把每档落到一个域上

这六步和用什么厂商无关，先想清楚策略，再落到命令。反过来的顺序（先找命令再想策略）是做不出现场能用的方案的。

35.4 华为 / H3C 命令对照表

表格里最需要记住的是第一行和第二行：H3C 用一个 user-profile 就装下了所有参数，华为要把「用户组 + UCL + 分类器 + 行为 + 策略」五样东西拼起来。所以：

• 学 H3C：理解一个模板对象就行。
• 学 华为：要理解一整套 QoS 组件（classifier/behavior/policy）的组装逻辑，这套逻辑和交换机上的 QoS 是一样的，学过交换机 QoS 的人反而觉得熟悉。

35.5 配置验证

用户策略的验证必须实测，不能只看配置。三步走：

第一步：确认模板已创建且被引用

# 华为：查用户组是否存在
display user-group ug_student

# H3C：查 user-profile 配置
display current-configuration configuration user-profile

第二步：确认用户实际生效的策略

# 华为：查在线用户详情，看策略字段
display access-user username user1@isp_student

# H3C：查 user-profile 应用情况
display user-profile interface

display access-user 的输出里，应该能看到该用户被关联的用户组/策略名。如果这里是空的，说明策略没有下发到用户身上——这是配置了但没生效的最常见原因。

第三步：实测速率（最重要！）

   在用户终端上：
   ① 用测速网站测下载速率 → 应接近下行限速值
   ② 测上传速率 → 应接近上行限速值
   ③ 如果上下行反了 → 检查 inbound/outbound 配置
   ④ 如果完全不限速 → 检查策略是否真的应用到用户
   ⑤ 如果几乎上不了网 → 检查限速单位是否配错了 1000 倍

为什么必须实测？ 因为限速配错的表现，从配置上看完全正常：

• 单位配成 1/1000 → 用户几乎不能用
• 上下行配反 → 下载慢上传快
• 策略没应用 → 完全没限速

这三种情况配置检查都发现不了，必须靠实测。

第四步：验证 QoS 统计（能看出限速是否在真的丢包）

# 华为：查看接口/策略的 QoS 统计
display traffic policy statistics

如果被限速的流量在不断增长而丢弃计数也在增长，说明限速在起作用。如果丢弃计数是 0 但用户报告慢，说明瓶颈不在限速上（可能是链路或服务器端）。

35.6 排错与故障树

用户策略的排错有一条主线：先确认策略有没有生效，再看策略配得对不对。

   用户投诉"网速不对"
     │
     ├─ Q1: 用户身上有没有策略？（查 display access-user）
     │     │
     │     ├─ 没有 ──┬─ ① 域没绑用户组/模板
     │     │         ├─ ② RADIUS 没下发
     │     │         └─ ③ 接口应用方式对 PPPoE 用户不生效（H3C）
     │     └─ 有 ──→ Q2
     │
     ├─ Q2: 策略数值对不对？
     │     │
     │     ├─ 上下行反了 ──→ 改 inbound/outbound
     │     ├─ 单位错了1000倍 ──→ 改数值
     │     └─ 数值本身错 ──→ 核对套餐
     │
     └─ Q3: 实测速率对不对？
           │
           ├─ 达到限速值但用户嫌慢 ──→ 套餐问题，不是故障
           ├─ 远低于限速值 ──┬─ 链路瓶颈
           │                 ├─ 用户终端/网线问题
           │                 └─ 服务器端带宽不足
           └─ 完全没限速 ──→ 策略没真正执行

详细排查表：

几个高频场景的完整路径：

场景一：配了限速，但用户说完全没被限制，跑得飞快。

这是最典型的问题，按顺序查：

# 1. 确认用户身上有没有策略
display access-user username user1@isp_student
#    看输出里有没有 user-group / policy 相关字段

# 2. 如果没有，查域有没有绑
display domain isp_student
#    看 User-group-name 字段

# 3. 如果是 H3C 且用了接口应用方式
display current-configuration interface GigabitEthernet3/1/1
#    如果看到 qos apply user-profile，且用户是 PPPoE
#    → 确认这条官方限制：入方向 policing 对 PPPoE 用户不生效

场景二：用户在下载，速度是限速值的 1/1000，几乎不能用。

   原因：把 Mbps 当成了 Kbps 或 bps 配进去
   举例：想让用户 100Mbps，写成了 100（以为单位是 Mbps，实际是 Kbps）
        → 实际只有 100Kbps
   
   解决：确认命令单位，乘上正确的倍数
   100Mbps = 100000 Kbps = 100000000 bps

这是配 QoS 最高频的事故，且因为「用户就是慢」这个现象太常见，很容易被归咎于「网络就是差」而长期查不出来。每次配完限速都要实测一次。

场景三：所有人上网都变慢，但带宽监控显示正常。

# 1. 查会话表使用率
display access-user | count
#    对比设备规格

# 2. 查是否有用户占用海量连接
#    按用户查连接数（命令按版本）
#    找到异常用户

# 3. 给这类用户加 connection-limit 限制

这种「带宽没超但所有人都慢」的现象，八成是会话表被打满。少数用户用 P2P 占满了表项，导致其他用户新建连接失败。解法不是扩容带宽，是给用户加连接数限制。

35.7 新手踩坑与注意事项

1. 限速单位搞错 1000 倍——最高频事故。配完必须实测。
2. 上下行限速配反——用户投诉「下载慢上传快」就是这个。
3. H3C 按接口应用 user-profile，入方向对 PPPoE 用户不生效——官方明确的限制，PPPoE 必须用 RADIUS 下发模板。
4. 华为 UCL 的 ACL 编号用了 3000 段——必须是 6000-9999，否则引用用户组会报错。
5. 对 UCL 分类器写多条规则想表达「且」——官方明确：对 UCL 而言 and 逻辑不生效。
6. 以为配了 QoS 策略就生效——分类器/行为/策略三者缺一不可，且必须最后被引用。
7. 只限带宽不限连接数——用户会用大量小连接占满会话表，带宽没超但所有人变慢。
8. 接口应用 user-profile 与 MPLS/VSI/IPoE 互斥——同一接口上配了就冲突，报错时别怀疑设备。
9. 主接口上应用的 user-profile 对子接口不生效——官方明确的限制。
10. 超售比没算清——500 户每户 100M 而上行只有 10G，一定拥塞。需要组级限速。
11. 回收了限速但用户还是慢——可能是用户终端或链路问题，不要一直在 BRAS 上找。
12. 多播没配复制——几百人同时看直播会把上行打爆。

35.8 本章小结

• 用户策略 = 限速 + 优先级 + ACL + 连接数 + 计费策略 + 多播副本。
• 上行用 CAR（丢包），下行用 Shaping（队列）；上下行是分别限的，别配反。
• 华为用「用户组 + UCL + 流量策略」，H3C 用「user-profile 模板」。H3C 的模型更直观，华为的模型更依赖 QoS 组件组装。
• H3C 的 qos apply user-profile 应用在接口上时，入方向 policing 对 PPPoE 用户不生效——这是必须知道的关键限制。
• 华为的 UCL 必须用 6000-9999 段的用户 ACL，且对 UCL 而言分类器的 and 逻辑不生效。
• 策略分层的三个级别：用户级、用户组级、业务队列级（HQoS）。
• 限速数值的单位是最大的坑，配完必须实测。
• 只限带宽不限连接数，会导致会话表被占满、所有人变慢。

适用版本：华为 NE40E V800R023C10 系列《用户接入 QoS 配置》《ACL 配置》；H3C CR16000-F Release 795x《User profile 配置》。本章华为侧 UCL 的完整链路（user-group → source user-group → classifier → behavior → traffic policy → 系统视图 traffic-policy 应用 → 域内 user-group 绑定）与 car 参数单位均已于第二轮/第三轮核实，出处为官方《User Access QoS Configuration》配置举例。

自测题

1. 用户的「上行流量」在 BRAS 上对应哪个方向？该用 CAR 还是 Shaping？
2. 华为的 UCL 必须使用什么编号段的 ACL？为什么？
3. H3C 的 user-profile 应用在接口上时，有什么关键限制？
4. 只限带宽不限连接数会导致什么问题？
5. 为什么「配了限速但用户完全没被限速」要优先怀疑域没有绑定用户组？

1. 上行流量对应 BRAS 的 inbound（从用户侧进入 BRAS）方向。推荐使用 CAR（承诺访问速率），因为上行瓶颈在用户侧，超出的包直接丢弃、让用户端 TCP 自行降速即可。
2. 必须使用 6000-9999 编号段的用户 ACL（UCL）。只有用户 ACL 才支持引用用户组，使用 2000-2999 的基础 ACL 或 3000-3999 的高级 ACL 去引用用户组会直接报错。
3. 关键限制是：user-profile 应用在接口上时，入方向（inbound）的流量监管对 PPPoE、portal、L2TP 用户不生效。这意味着 PPPoE 场景下按接口应用无法限制上行速度，必须改用 RADIUS 下发 user-profile 的方式。
4. 少数用户可能用大量 P2P 小连接占满设备的会话表项，导致其他用户新建连接变慢或失败。此时带宽监控看起来正常，但所有人上网都变慢，且很难定位。
5. 因为策略是否真正应用到用户身上，取决于域是否绑定了用户组（或模板）。如果域没有绑定，无论 QoS 策略配得多正确，都不会应用到任何用户。验证方法是在 display access-user 中查看用户是否有策略字段，或在 display domain 中查看 User-group-name 是否为空。

关于本书：《华为 / H3C 网络设备典型功能配置详解》—— 面向国内高校/企业网络环境， 华为 VRP 与 H3C Comware 双厂商并排配置的实操教材，共 43 章。 全书所有命令尽量有官方出处，查不到的显式标注「待核实」。 返回系列目录