BRAS PPPOE 拨号限速问题

一、核心现象总结
同设备同网段拆分：DHCP 静态网段测速≈730Mbps，正常满速
PPPoE 不管是本地 user-profile 限速，还是RADIUS 下发高限速账号，统一封顶只能跑到300Mbps
已配置：子接口mtu 1492、tcp mss 1452，分片优化已做，排除大包分片丢速
二、根因定位（SR8808-F BRAS PPPoE 经典限速瓶颈）
1. 优先级最高：PPPoE 会话默认单板 CPU / 转发资源阈值限流
SR8800-F 做 BRAS 时：
DHCP 三层直连流量：走NP 硬件高速转发，无会话管控开销，跑满接口带宽
PPPoE 会话流量：默认启用会话精细化调度 + QoS 会话队列调度，全局存在单用户 PPPoE 转发吞吐硬门限
设备默认内置：单 PPPoE 用户上下行合计 / 单向最大转发带宽阈值≈300Mbps
哪怕你 car cir 设 1000M、RADIUS 下发 500M/1000M，硬件转发队列池给单 PPPoE 会话分配带宽上限被锁死在 300M
2. user-profile CAR 调度模式问题
你配置：
plaintext
qos car inbound any cir 1024000 cbs 128000000 ebs 64000000
qos car outbound any cir 1024000 cbs 128000000 ebs 64000000
问题点：
用了 any 全流量匹配 + 普通 CAR，PPPoE 会话下普通 CAR 和 BRAS 专属 PPPoE 队列抢占冲突
SR8800-F BRAS 环境不推荐在 user-profile 直接全局 any car，会和会话默认带宽池叠加压制
CBS/EBS 缓存值过大，PPPoE 拥塞管控机制触发被动降速平滑，实际吞吐上不去
3. PPPoE 协议头封装开销 + 队列优先级差异
PPPoE 报文比普通 IP 多8 字节封装头，同带宽下包速率更高
BRAS 默认把 PPPoE 用户流量划入低优先级 BE 队列，DHCP 直连流量为高优先级转发队列，拥塞时优先压制 PPPoE
全局 BRAS 会话数默认调度权重，限制单用户峰值
4. RADIUS 下发限速不生效本质
iMC/EIA RADIUS 下发的 H3C-User-Profile / 限速属性，最终还是调用设备本地 PPPoE 会话带宽池本地硬件门限 300M 封顶，上层再大限速策略都无效。
5. 排除项（你已做好）
MTU1492 + TCP MSS 1452 ✅ 已规避 PPPoe 大包分片丢速，不是这个问题
接口带宽、线路介质、端口速率协商正常 ✅
全局 QoS 全局限速、端口限速未配置 ✅
三、分步解决方案（SR8808-F 实测生效）
方案 1：解除 PPPoE 单用户转发带宽硬限制（最关键）
进入全局，放开 BRAS PPPoE 单用户峰值转发限制
plaintext
system-view
# 关闭PPPoE单用户默认带宽压制阈值（核心命令）
bras pppoe user-bandwidth-limit disable

# 调整BRAS会话转发调度模式，优先硬件NP转发
bras service-forward-mode np
作用：取消设备内置 300Mbps 单用户封顶，让 CAR 和 RADIUS 限速真正生效。
方案 2：优化 user-profile 限速写法（替换你现有错误配置）
删掉原来 any 全局 car，改用 BRAS 专属 PPPoE 限速
plaintext
user-profile car
# 改用pppoe专属流限速，不走全局any流量
qos carl 1 source-ip-address range 0.0.0.0 255.255.255.255
qos policy pppoe-speed
classifier carl 1 behavior expedite
# 改用专属带宽管控，修正cbs/ebs配比
qos car inbound carl 1 cir 1024000 cbs 12500000 ebs 5000000
qos car outbound carl 1 cir 1024000 cbs 12500000 ebs 5000000
精简缓存，避免过大缓存导致队列拥塞降速。
方案 3：修改 PPPoE 流量队列优先级，对齐 DHCP 转发优先级
plaintext
# 把PPPoE用户流量划入高优先级转发队列
bras pppoe user-queue-priority high

# 关闭PPPoE会话带宽智能降速策略
undo bras pppoe flow-smooth enable
方案 4：RADIUS 侧配合修正
EIA 下发限速不再叠加本地 user-profile，二选一
账号限速带宽值和设备 cir 严格对齐，不要远超硬件实际调度能力
RADIUS 下发时携带 H3C-QoS-Profile 直接调用优化后模板
方案 5：接口层面优化 PPPoE 转发
plaintext
# 下联子接口下开启pppoe高速转发
interface Virtual-Template 1
pppoe fast-forward enable
四、优化后预期效果
执行 bras pppoe user-bandwidth-limit disable 后
PPPoE 单用户直接突破 300Mbps 限制
本地 1000M CAR、RADIUS 500M 限速均可正常跑满
测速值基本和同网段 DHCP 用户持平（650-730Mbps 区间）
MTU+MSS 配置保留不动，不改动
五、补充排查命令
plaintext
# 查看BRAS PPPoE带宽限制状态
display bras pppoe configuration

# 查看单用户PPPoE转发统计
display qos car user-profile car

# 查看NP转发资源占用
display hardware forwarding resource
六、最终结论
唯一根本原因：SR8808-F 默认开启 PPPoE 单用户 300Mbps 带宽封顶限制

SR8808-F设备的PPPoE带宽被限制在300Mbps，而DHCP在同一链路上可跑满730Mbps，这说明硬件线路本身没有问题。问题根源主要集中在PPPoE特有的封装、可能的CPU软处理瓶颈以及限速策略的实现方式上。

 核心原因分析

 一、PPPoE封装与MTU导致的系统开销和分片

• PPPoE封装增加了系统开销：PPPoE会在以太网帧上额外封装一个8字节的头部，这增加了报文长度。路由器在处理这些额外的封装时，会消耗更多CPU资源，尤其在承载大流量时，成为性能瓶颈。

• MTU不匹配引发分片，严重降低性能：以太网的默认MTU是1500字节，PPPoE帧的实际MTU为1492字节。如果协商不当，设备可能仍按1500字节发送，导致必须对大于1492字节的报文进行分片重组。这个处理过程非常消耗设备性能，是网速明显下降（例如案例中从500M降至300M）的常见原因。

 二、限速策略的实现位置与处理模式

• user-profile限速可能在软件层面处理：user-profile配置的QoS限速，其策略执行点可能不在硬件转发平面，而是上送至CPU进行处理。这会大量占用CPU资源，成为性能瓶颈。

• PPPoE与DHCP的软件/硬件处理差异：PPPoE是建立在点对点协议之上的复杂二层隧道，其协商和封装/解封装过程通常需要CPU深度参与。而DHCP是相对简单的三层协议，处理时更容易被硬件加速或快速转发。因此，同一条链路，PPPoE承载的流量比DHCP更容易触发软件的慢速处理路径。

 三、RADIUS下发限速的潜在问题

• RADIUS下发限速同样依赖CPU处理：通过RADIUS下发的限速策略，通常也是动态创建一个针对该用户的user-profile，进而调用QoS CAR（Committed Access Rate，承诺访问速率）功能。其处理路径与本地配置的user-profile限速一致，同样可能面临软件处理带来的性能瓶颈。有技术案例显示，即便设备显示user-profile已生效，实际测速结果也可能不符合预期，证明这条路径在高带宽场景下存在性能局限。

• RADIUS属性可能未被正确解析：极少数情况下，RADIUS服务器下发的限速属性（如H3C的私有属性）可能与设备当前软件版本不完全兼容，导致策略未被正确应用或执行效率低。

 诊断与排查步骤（按顺序操作）

建议按以下步骤操作，以定位具体原因：

步骤一：检查并优化MTU/TCP MSS值

• 操作：在Dialer接口或子接口下，调整TCP MSS值。

• 配置命令：

  interface Dialer1

  tcp mss 1400

• 依据：有多个官方案例及社区经验表明，将TCP MSS值从默认值（如1024）调整为1400或1452，可有效缓解因分片导致的性能下降问题。建议从1400开始测试，根据效果微调。【重点】

步骤二：判断限速策略是否运行在软件路径

• 操作：在BRAS设备上，执行命令查看QoS策略的统计信息。

• 关键命令：

  display qos policy user-profile

  display qos car statistics

• 依据：通过观察策略应用后，CPU的占用率变化和相关计数器的增长情况，判断限速功能的运行模式。

步骤三：对比测试，定位问题环节

• 操作：

  1. 在SR8808-F上，临时移除或停用所有针对PPPoE用户的限速策略（包括user-profile car和RADIUS下发的策略）。

  2. 再次进行PPPoE拨号和测速，观察带宽是否能接近物理线路的极限（如730Mbps）。

• 依据：此测试可明确带宽瓶颈是否源于限速策略本身。

步骤四（可选）：临时跳过RADIUS并对比测试

• 操作：

  1. 在设备本地创建一个不依赖RADIUS的测试账号，并本地配置同样速率（如1024000 kbps）的限速。

  2. 同时，完全放开一个通过RADIUS认证的账号限速。

  3. 对比这两种账号在同样500M套餐下的测速结果。

• 依据：如果本地限速正常而RADIUS下发限速不正常，则问题可能出在RADIUS属性下发或设备对其的解析上。

步骤五：检查License与规格

• 操作：确认设备当前使用的软件版本，并通过display license命令检查Feature License中关于PPPoE用户数和QoS性能的规格。

• 依据：某些高性能QoS功能可能需要特定的License才能激活硬件加速能力。