M9000带宽管理突破限制阈值

整机的话不能这样计算

✅ 你现在这个 traffic-policy + qos profile 带宽管理是单板独立计数、单业务板单独生效 你配置 bandwidth upstream maximum 15000000（15G），slot11、slot12 两块业务板各自独立维护一套令牌桶，每块板最多允许 15G，整机上限变成 15G+15G=30G，和你抓的统计现象完全吻合。

M9000 传统带宽管理（流量策略 profile）没有原生整机聚合令牌桶，默认按单板硬件独立管控，不跨板卡汇总统计。

两种实现【整机总共限 15G】的方案

方案 1：全局 CAR（推荐，全局 CAR 支持整机统一令牌桶）

传统 traffic-policy 带宽管理是板卡粒度；global CAR 是整机粒度共享同一个令牌池，可以实现整机总限速 15G

1. 删掉当前这条 traffic-policy 里的 qos profile 限流动作，改用全局 CAR；
2. 匹配同样的源 / 目的地址集 yunpan_obs /yunpan_obs_des；
3. 配置 CAR：CIR=15000000 kbps，PIR=15000000 kbps；

注意：全局 CAR 是主控统一做令牌计数，跨业务板流量共享这一个桶，两块业务板流量加起来触达 15G 上限就会丢包，达成整机阈值控制。 缺点：全局 CAR 的带宽保障（guaranteed）能力弱于带宽管理 profile，适合只做最大限速场景，如果你还需要保障带宽，这个方案不合适。

方案 2：出口侧接口聚合限速（适合流量都从同一个聚合出口出去）

如果云盘 obs 流量统一从一组上行接口（聚合组）出防火墙：

1. 在出口方向的聚合接口上配置 CBQ / 接口 CAR，在出接口做整形 shaping；
2. 接口 shaping 是在出口处统一管控整机从这个接口出去的总流量，不受业务板拆分影响；

适用前提：所有该云盘业务流量都从同一个出口接口 / 聚合转发；如果流量从多个不同出口分散出去，这个方案控不住。

方案 3：层次化带宽通道（新版本 M9000 带宽管道，优先推荐需要保带宽的场景）

M9000 新版本带宽管理支持带宽管道（line/channel）层级嵌套：

1. 先创建一条整机级顶层管道，设置上行 max 15G；
2. 再把你现在的 yunpan_obs_up/down 这个 profile，挂载在这条顶层管道下面；
3. 顶层管道是整机统一配额，所有业务板匹配这条策略的流量共享顶层 15G 配额；

优点：同时保留原有 guaranteed 保障带宽、区分上下行的能力，是官方推荐的整机带宽管控方案； ⚠️ 依赖版本：老版本 M9000 固件不支持带宽管道嵌套，需要确认版本是否支持 line-channel 层次化带宽。