尧图网站建设 
简介这份《中国联通宽带网络核心网BNC技术白皮书》由中国联通联合华为、中兴、新华三、诺基亚贝尔等单位编写面向通信网络规划、建设与运维工程师以及关注固定宽带架构演进的技术人员。白皮书围绕宽带业务的新机遇与新挑战系统阐述固定宽带网络架构的重构思路、BNC发展愿景与技术演进路径并深入拆解管理面、控制面、用户转发面及智能算力底座四大系统架构涵盖网元管理、业务编排、智能运维、数字孪生、接入控制、智能策略、服务化架构、转发控制、智能感知、安全自愈等模块。关键技术部分重点讲解转控分离、服务化架构、信令化业务控制、用户永远在线CP异地11热备、双CP中断极限逃生、UP异地温备池化以及内生网元智能等方向便于读者把握BNC整体技术脉络与设计要点。资源为1个PDF文件压缩包约1.84MB已有455人学习下载适合作为宽带核心网技术研究与方案参考的案头资料。1. 中国联通BNC白皮书到底在讲什么从家宽卡顿到城域核心网的那张网家里宽带一到晚高峰就转圈游戏延迟从 20ms 跳到 200ms视频会议声音断续——多数人第一反应是路由器不行、光猫太老但真正决定体验上限的往往在城域网更靠里的位置宽带网络核心网。中国联通宽带网络核心网BNCBroadband Network Core技术白皮书讲的就是这张把千万家庭宽带用户汇聚起来、做认证、做转发、做业务调度的网该怎么建、怎么演进。它面向的不是终端用户而是省市级网络规划、核心网运维、集采选型和设备研发的从业者。你如果正在做 BRAS 选型、城域云化改造、或者被用户投诉逼着找家宽质量根因这份白皮书值得逐章拆开看。它解决的核心问题是在用户数暴涨、4K/8K 视频和云游戏普及、IPv6 全面铺开的背景下传统 BRAS 竖井式组网撑不住了BNC 要给出一个可落地的新架构。2. BNC的架构底座从BRAS竖井到云化核心网的分层逻辑2.1 为什么传统BRAS组网必须改传统家宽组网里BRAS宽带远程接入服务器是绝对核心。每个 BRAS 管一片区域用户 PPPoE 拨号上来BRAS 做认证、分配地址、限速、转发。这套架构跑了二十年问题在近五年集中爆发。第一是容量瓶颈。单台 BRAS 的会话数有上限一个中等城市几十万宽带用户往往要堆十几台 BRAS每台都是独立竖井用户跨 BRAS 迁移要重新拨号。第二是业务僵化。想在 BRAS 上开个新业务比如家宽加速、家长控制、IPTV 组播优化得等设备厂商排期开发周期以季度计。第三是运维黑匣子。BRAS 是专用硬件转发面和控制面耦合出故障只能整机重启用户掉线一片。白皮书给出的判断很直接家宽业务已经从“能上网”变成“上网体验要好”核心网必须从“管道”变成“可编程的业务平台”。这就是 BNC 的出发点。2.2 BNC的三层架构拆解BNC 的架构可以拆成三层从下往上分别是转发层、控制层、业务层。这个分层不是纸面概念每一层对应不同的设备形态和部署位置。转发层是用户面负责实际的数据包转发、QoS 标记、流量统计。传统 BRAS 的转发功能被拆出来放到通用服务器或者专用转发设备上。白皮书里提到的转发层设备通常部署在城域核心机房上联 CR核心路由器下联汇聚交换机。控制层是控制面负责用户认证、地址管理、会话控制、策略下发。这一层从 BRAS 里抽出来变成独立的控制面集群。好处是控制面可以集中部署一台控制面设备管多台转发面设备用户跨转发面迁移时会话不中断。业务层是增值业务面负责家宽加速、内容缓存、安全防护这些增值功能。业务层通过标准接口调用控制层和转发层的能力不用改底层设备。三层之间用标准协议通信白皮书里重点提了 CU 分离控制面与用户面分离和云化部署。CU 分离让控制面和转发面独立扩容转发面不够加服务器控制面不够加虚拟机。云化部署让 BNC 可以跑在通用 x86 服务器上不再绑定专用硬件。2.3 云化BNC的最小部署单元如果你要在一个地市试点 BNC最小部署单元怎么搭白皮书没有给具体配置但根据常见做法一个最小单元通常包含2 台控制面服务器主备跑认证、地址管理、策略控制2 台转发面服务器主备或负载分担跑用户面转发1 套管理平台做配置下发和监控上联 2 台 CR下联 2 台汇聚交换机做冗余这个单元能带多少用户取决于转发面服务器的网卡性能和 CPU 转发能力。用 DPDK 加速的话单台双路服务器跑 10Gbps 转发问题不大对应大约 2 到 3 万宽带用户。如果用户量更大横向加转发面服务器就行控制面不用动。提示云化 BNC 的转发面性能对网卡和 CPU 绑定很敏感部署前一定要做基准测试别直接照搬厂商给的标称值。3. 从白皮书到机架BNC落地的四个关键步骤3.1 第一步把现网BRAS的会话模型摸清楚动手之前先把你现网 BRAS 的用户会话模型摸清楚。这一步不做后面容量规划全是拍脑袋。需要采集的数据包括每台 BRAS 的峰值会话数、平均会话数、PPPoE 拨号成功率、DHCPv6 地址分配成功率、每用户平均下行流量、忙时集中时段。采集方式看设备型号常见做法是通过 BRAS 的 CLI 或者 SNMP 拉数据。下面是一个用 Python 通过 SNMP 采集 BRAS 会话数的示例假设你已经知道 BRAS 的 OID# 通过 SNMP 采集 BRAS 当前 PPPoE 会话数 # 依赖 pysnmp安装pip install pysnmp from pysnmp.hlapi import * def get_pppoe_sessions(ip, community, oid): ip: BRAS 管理地址 community: SNMP 团体字 oid: PPPoE 会话数对应的 OID不同厂商不同 iterator getCmd( SnmpEngine(), CommunityData(community, mpModel1), # mpModel1 表示 SNMPv2c UdpTransportTarget((ip, 161), timeout3, retries2), ContextData(), ObjectType(ObjectIdentity(oid)) ) errorIndication, errorStatus, errorIndex, varBinds next(iterator) if errorIndication: print(fSNMP 错误: {errorIndication}) return None for varBind in varBinds: return int(varBind[1]) # 示例假设 OID 为 1.3.6.1.4.1.XXXX.1.1.1.0 sessions get_pppoe_sessions(192.168.1.1, public, 1.3.6.1.4.1.XXXX.1.1.1.0) print(f当前 PPPoE 会话数: {sessions})这段代码的逻辑很简单用 SNMPv2c 去读 BRAS 上表示会话数的 OID。参数说明ip是 BRAS 管理地址community是团体字oid需要查你所用 BRAS 型号的 MIB 文档。不同厂商 OID 不一样华为、中兴、新华三各有一套别抄错。采集周期建议 5 分钟一次连续采一周覆盖工作日和周末的忙时。拿到数据后画一张会话数随时间变化的曲线找出峰值。峰值会话数乘以 1.2 的安全系数就是 BNC 转发面要承载的目标容量。3.2 第二步控制面与转发面的容量配比BNC 的容量规划核心是控制面和转发面的配比。控制面管会话转发面管流量两者不是一比一的关系。控制面服务器的瓶颈通常在 CPU 和内存。每个用户会话在控制面上占多少内存取决于认证方式和策略复杂度。PPPoE 认证比 IPoE 重因为要维护 PPP 会话状态。白皮书里没有给具体数字但根据常见做法一台 16 核 64G 的控制面虚拟机跑 10 万 PPPoE 会话问题不大如果开了一堆策略可能降到 5 万。转发面服务器的瓶颈在网卡和 CPU 转发能力。用 DPDK 或者智能网卡加速的话单台双路服务器可以跑到 20Gbps 甚至 40Gbps 转发。但要注意转发能力和小包性能是两回事。家宽用户大量是小包游戏、网页小包转发性能才是真实瓶颈。测试的时候一定要用 64 字节小包测 PPS别只看大包吞吐。配比建议先按 1 台控制面配 2 台转发面起步跑一段时间看控制面 CPU 和转发面 PPS再调整。如果控制面 CPU 先到瓶颈加控制面如果转发面 PPS 先到瓶颈加转发面。3.3 第三步用户迁移与割接方案BNC 上线最大的风险不是技术是割接。现网几十万用户不可能一夜之间全迁过去。常见做法是分批次割接按区域或者按 BRAS 逐步迁移。割接前要准备几件事第一BNC 控制面和转发面要和现网 BRAS 互通用户迁移过程中可能需要在两套系统之间跳转。第二地址池要规划好BNC 的地址池不能和现网 BRAS 冲突。第三回退方案要准备好万一 BNC 出问题用户能快速切回原 BRAS。割接步骤通常是这样先选一个用户量小的 BRAS把它的用户迁到 BNC 上观察一周。没问题的话再迁第二个、第三个。每迁一个 BRAS记录用户投诉率、拨号成功率、平均时延。如果投诉率明显上升立刻回退。注意割接窗口选在凌晨 2 点到 5 点别选周末晚上那是用户在线高峰出问题影响面太大。3.4 第四步业务层的增值功能怎么接BNC 的业务层是它区别于传统 BRAS 的关键。传统 BRAS 也能做限速、ACL但业务层能做更灵活的东西比如基于用户标签的差异化加速、和 CDN 联动的内容调度、家长控制、游戏加速。业务层接入 BNC 的方式白皮书里提了标准 API。常见做法是业务层通过 RESTful API 调用控制面下发策略通过转发面的开放接口做流量牵引和标记。下面是一个用 Python 调用控制面 API 下发限速策略的示例# 调用 BNC 控制面 API 下发用户限速策略 # 假设控制面提供 RESTful 接口认证方式为 Token import requests def set_user_rate_limit(api_base, token, user_ip, down_kbps, up_kbps): api_base: 控制面 API 地址如 https://bnc-controller:8443/api/v1 token: 认证 Token user_ip: 用户 IP 地址 down_kbps: 下行限速单位 kbps up_kbps: 上行限速单位 kbps url f{api_base}/policy/rate-limit headers { Authorization: fBearer {token}, Content-Type: application/json } payload { user_ip: user_ip, downstream_kbps: down_kbps, upstream_kbps: up_kbps, priority: 5 # 优先级1 最高10 最低 } resp requests.post(url, jsonpayload, headersheaders, timeout5) if resp.status_code 200: print(f限速策略下发成功: {user_ip}) else: print(f下发失败: {resp.status_code}, {resp.text}) # 示例给用户 10.10.1.100 限速 100Mbps 下行 / 20Mbps 上行 set_user_rate_limit( https://bnc-controller:8443/api/v1, your-token-here, 10.10.1.100, 100000, 20000 )这段代码的逻辑是构造一个 JSON 请求通过 POST 发给控制面的限速接口。参数说明api_base是控制面地址token是认证凭证user_ip是目标用户down_kbps和up_kbps是限速值单位 kbps。priority是策略优先级数值越小优先级越高。实际部署时Token 要从认证服务获取别硬编码在脚本里。业务层接入后要重点验证策略下发时延。用户从拨号到策略生效如果超过 2 秒体验就会变差。测试方法是用脚本模拟用户拨号然后立刻调用 API 下发策略记录从拨号成功到策略生效的时间差。4. BNC部署避坑五条血泪经验4.1 坑一转发面小包性能不达标现象转发面服务器标称 40Gbps 转发实际跑家宽业务时忙时丢包率飙升用户游戏延迟抖动严重。原因标称转发能力通常是用大包1500 字节测的家宽业务大量是小包64 到 128 字节。小包转发靠的是 PPS每秒包数不是带宽。一台服务器大包能跑 40Gbps小包可能只能跑 5Gbps。解决采购前用 64 字节小包做基准测试要求厂商提供小包 PPS 数据。部署后用sar -n DEV 1或者ethtool -S监控实际 PPS如果接近测试上限提前扩容。4.2 坑二控制面会话同步延迟导致用户掉线现象控制面主备切换时部分用户掉线重新拨号才能恢复。原因控制面主备之间的会话同步不是实时的有延迟。切换时备机上的会话状态比主机旧导致部分用户会话丢失。解决选择支持会话实时同步的控制面方案或者把同步周期调到最小。割接前做一次主备切换演练记录掉线用户比例如果超过 1%要求厂商优化。4.3 坑三IPv6地址池规划不当现象IPv6 用户拨号成功但无法上网或者部分网站访问慢。原因IPv6 地址池规划时没有考虑前缀委派PD长度。家宽用户通常需要 /60 或 /56 的前缀如果只给 /64用户家里的多台设备就没法分配公网 IPv6 地址。解决规划 IPv6 地址池时给每个用户预留 /60 前缀。控制面要支持 DHCPv6-PD转发面要能转发 IPv6 流量。测试时用支持 IPv6 的终端验证别只用 IPv4 测。4.4 坑四业务层策略下发风暴现象业务层批量下发策略时控制面 CPU 飙升用户拨号变慢。原因业务层调用 API 没有做限流短时间大量请求打到控制面控制面处理不过来。解决业务层加请求队列和限流控制面加 API 网关做保护。批量操作时分批下发每批之间留间隔。监控控制面 API 响应时间超过 500ms 就告警。4.5 坑五割接回退方案没验证现象割接后 BNC 出问题想回退到原 BRAS发现回退脚本跑不通用户断网两小时。原因回退方案只在实验室验证过没在现网验证。现网 BRAS 的配置和实验室不一样回退脚本里的参数对不上。解决割接前在现网做一次回退演练用真实 BRAS 配置跑一遍回退脚本。回退脚本里的 BRAS 地址、团体字、地址池参数都要从现网采集别用实验室的。5. 用白皮书指导选型三个容易被忽略的验证点白皮书读完之后真正要落地还得落到选型和验证上。我一般会重点盯三个容易被忽略的点。第一个是控制面的会话建立速率。白皮书里可能只提了会话容量但没提建立速率。家宽用户拨号是突发的早上和晚上高峰大量用户同时拨号。如果控制面每秒只能建 1000 个会话而你的 BRAS 迁移过来 10 万用户高峰时拨号就要等 100 秒用户直接投诉。验证方法用脚本模拟 1000 个用户同时拨号记录从第一个拨号成功到最后一个拨号成功的时间。如果超过 30 秒控制面建立速率不够。第二个是转发面的 QoS 精度。白皮书里会提 QoS但精度怎么样要实测。家宽用户对限速很敏感说好 100Mbps实际跑 90Mbps 用户就会投诉。验证方法用 iperf3 打流同时用tc或者转发面自带工具做限速看实际限速值和配置值的偏差。偏差超过 5% 就要问厂商原因。第三个是业务层的策略生效时延。前面提过策略下发时延超过 2 秒体验就变差。验证方法写一个脚本模拟用户拨号拨号成功后立刻调用业务层 API 下发一个限速策略然后立刻用 iperf3 打流看限速是否生效。记录从 API 调用到限速生效的时间差。这个时间差包括 API 处理时间、控制面下发时间、转发面生效时间任何一段慢了都会影响体验。下面是一个用 iperf3 和 tc 验证限速精度的示例# 在转发面服务器上验证限速精度 # 假设用户 IP 为 10.10.1.100限速 100Mbps # 1. 在转发面服务器上配置 tc 限速示例实际用 BNC 控制面下发 tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:10 htb rate 100mbit ceil 100mbit # 2. 在客户端用 iperf3 打流持续 30 秒 iperf3 -c 10.10.1.100 -t 30 -P 4 # 3. 观察 iperf3 输出的带宽如果稳定在 95Mbps 到 100Mbps 之间说明限速精度合格 # 如果低于 90Mbps 或者高于 105Mbps需要检查 tc 配置和转发面 QoS 实现这段脚本的逻辑是先用tc在转发面服务器上模拟限速然后用 iperf3 打流验证。参数说明tc qdisc add添加一个 HTB 队列规则rate 100mbit是限速值ceil 100mbit是最大允许速率。iperf3 的-P 4表示开 4 个并发流模拟多连接场景。实际 BNC 部署时限速由控制面下发不用手动配 tc但验证方法一样。我自己的习惯是每次选型测试都建一个 checklist把会话容量、建立速率、小包 PPS、QoS 精度、策略时延、主备切换时间这六项列进去每项都有明确的通过标准。厂商来测试的时候一项一项过别听他们讲 PPT。有一次我差点被一个厂商的标称值忽悠他们标称小包 PPS 是 1000 万实测只有 300 万差了 3 倍多。后来问他们测试条件原来是用 128 字节测的不是 64 字节。这种坑只有自己测过才知道。希望帮到你。本文还有配套的精品资源点击获取 中国联通BNC白皮书解读：从BRAS竖井到云化核心网的架构与落地
简介这份《中国联通宽带网络核心网BNC技术白皮书》由中国联通联合华为、中兴、新华三、诺基亚贝尔等单位编写面向通信网络规划、建设与运维工程师以及关注固定宽带架构演进的技术人员。白皮书围绕宽带业务的新机遇与新挑战系统阐述固定宽带网络架构的重构思路、BNC发展愿景与技术演进路径并深入拆解管理面、控制面、用户转发面及智能算力底座四大系统架构涵盖网元管理、业务编排、智能运维、数字孪生、接入控制、智能策略、服务化架构、转发控制、智能感知、安全自愈等模块。关键技术部分重点讲解转控分离、服务化架构、信令化业务控制、用户永远在线CP异地11热备、双CP中断极限逃生、UP异地温备池化以及内生网元智能等方向便于读者把握BNC整体技术脉络与设计要点。资源为1个PDF文件压缩包约1.84MB已有455人学习下载适合作为宽带核心网技术研究与方案参考的案头资料。1. 中国联通BNC白皮书到底在讲什么从家宽卡顿到城域核心网的那张网家里宽带一到晚高峰就转圈游戏延迟从 20ms 跳到 200ms视频会议声音断续——多数人第一反应是路由器不行、光猫太老但真正决定体验上限的往往在城域网更靠里的位置宽带网络核心网。中国联通宽带网络核心网BNCBroadband Network Core技术白皮书讲的就是这张把千万家庭宽带用户汇聚起来、做认证、做转发、做业务调度的网该怎么建、怎么演进。它面向的不是终端用户而是省市级网络规划、核心网运维、集采选型和设备研发的从业者。你如果正在做 BRAS 选型、城域云化改造、或者被用户投诉逼着找家宽质量根因这份白皮书值得逐章拆开看。它解决的核心问题是在用户数暴涨、4K/8K 视频和云游戏普及、IPv6 全面铺开的背景下传统 BRAS 竖井式组网撑不住了BNC 要给出一个可落地的新架构。2. BNC的架构底座从BRAS竖井到云化核心网的分层逻辑2.1 为什么传统BRAS组网必须改传统家宽组网里BRAS宽带远程接入服务器是绝对核心。每个 BRAS 管一片区域用户 PPPoE 拨号上来BRAS 做认证、分配地址、限速、转发。这套架构跑了二十年问题在近五年集中爆发。第一是容量瓶颈。单台 BRAS 的会话数有上限一个中等城市几十万宽带用户往往要堆十几台 BRAS每台都是独立竖井用户跨 BRAS 迁移要重新拨号。第二是业务僵化。想在 BRAS 上开个新业务比如家宽加速、家长控制、IPTV 组播优化得等设备厂商排期开发周期以季度计。第三是运维黑匣子。BRAS 是专用硬件转发面和控制面耦合出故障只能整机重启用户掉线一片。白皮书给出的判断很直接家宽业务已经从“能上网”变成“上网体验要好”核心网必须从“管道”变成“可编程的业务平台”。这就是 BNC 的出发点。2.2 BNC的三层架构拆解BNC 的架构可以拆成三层从下往上分别是转发层、控制层、业务层。这个分层不是纸面概念每一层对应不同的设备形态和部署位置。转发层是用户面负责实际的数据包转发、QoS 标记、流量统计。传统 BRAS 的转发功能被拆出来放到通用服务器或者专用转发设备上。白皮书里提到的转发层设备通常部署在城域核心机房上联 CR核心路由器下联汇聚交换机。控制层是控制面负责用户认证、地址管理、会话控制、策略下发。这一层从 BRAS 里抽出来变成独立的控制面集群。好处是控制面可以集中部署一台控制面设备管多台转发面设备用户跨转发面迁移时会话不中断。业务层是增值业务面负责家宽加速、内容缓存、安全防护这些增值功能。业务层通过标准接口调用控制层和转发层的能力不用改底层设备。三层之间用标准协议通信白皮书里重点提了 CU 分离控制面与用户面分离和云化部署。CU 分离让控制面和转发面独立扩容转发面不够加服务器控制面不够加虚拟机。云化部署让 BNC 可以跑在通用 x86 服务器上不再绑定专用硬件。2.3 云化BNC的最小部署单元如果你要在一个地市试点 BNC最小部署单元怎么搭白皮书没有给具体配置但根据常见做法一个最小单元通常包含2 台控制面服务器主备跑认证、地址管理、策略控制2 台转发面服务器主备或负载分担跑用户面转发1 套管理平台做配置下发和监控上联 2 台 CR下联 2 台汇聚交换机做冗余这个单元能带多少用户取决于转发面服务器的网卡性能和 CPU 转发能力。用 DPDK 加速的话单台双路服务器跑 10Gbps 转发问题不大对应大约 2 到 3 万宽带用户。如果用户量更大横向加转发面服务器就行控制面不用动。提示云化 BNC 的转发面性能对网卡和 CPU 绑定很敏感部署前一定要做基准测试别直接照搬厂商给的标称值。3. 从白皮书到机架BNC落地的四个关键步骤3.1 第一步把现网BRAS的会话模型摸清楚动手之前先把你现网 BRAS 的用户会话模型摸清楚。这一步不做后面容量规划全是拍脑袋。需要采集的数据包括每台 BRAS 的峰值会话数、平均会话数、PPPoE 拨号成功率、DHCPv6 地址分配成功率、每用户平均下行流量、忙时集中时段。采集方式看设备型号常见做法是通过 BRAS 的 CLI 或者 SNMP 拉数据。下面是一个用 Python 通过 SNMP 采集 BRAS 会话数的示例假设你已经知道 BRAS 的 OID# 通过 SNMP 采集 BRAS 当前 PPPoE 会话数 # 依赖 pysnmp安装pip install pysnmp from pysnmp.hlapi import * def get_pppoe_sessions(ip, community, oid): ip: BRAS 管理地址 community: SNMP 团体字 oid: PPPoE 会话数对应的 OID不同厂商不同 iterator getCmd( SnmpEngine(), CommunityData(community, mpModel1), # mpModel1 表示 SNMPv2c UdpTransportTarget((ip, 161), timeout3, retries2), ContextData(), ObjectType(ObjectIdentity(oid)) ) errorIndication, errorStatus, errorIndex, varBinds next(iterator) if errorIndication: print(fSNMP 错误: {errorIndication}) return None for varBind in varBinds: return int(varBind[1]) # 示例假设 OID 为 1.3.6.1.4.1.XXXX.1.1.1.0 sessions get_pppoe_sessions(192.168.1.1, public, 1.3.6.1.4.1.XXXX.1.1.1.0) print(f当前 PPPoE 会话数: {sessions})这段代码的逻辑很简单用 SNMPv2c 去读 BRAS 上表示会话数的 OID。参数说明ip是 BRAS 管理地址community是团体字oid需要查你所用 BRAS 型号的 MIB 文档。不同厂商 OID 不一样华为、中兴、新华三各有一套别抄错。采集周期建议 5 分钟一次连续采一周覆盖工作日和周末的忙时。拿到数据后画一张会话数随时间变化的曲线找出峰值。峰值会话数乘以 1.2 的安全系数就是 BNC 转发面要承载的目标容量。3.2 第二步控制面与转发面的容量配比BNC 的容量规划核心是控制面和转发面的配比。控制面管会话转发面管流量两者不是一比一的关系。控制面服务器的瓶颈通常在 CPU 和内存。每个用户会话在控制面上占多少内存取决于认证方式和策略复杂度。PPPoE 认证比 IPoE 重因为要维护 PPP 会话状态。白皮书里没有给具体数字但根据常见做法一台 16 核 64G 的控制面虚拟机跑 10 万 PPPoE 会话问题不大如果开了一堆策略可能降到 5 万。转发面服务器的瓶颈在网卡和 CPU 转发能力。用 DPDK 或者智能网卡加速的话单台双路服务器可以跑到 20Gbps 甚至 40Gbps 转发。但要注意转发能力和小包性能是两回事。家宽用户大量是小包游戏、网页小包转发性能才是真实瓶颈。测试的时候一定要用 64 字节小包测 PPS别只看大包吞吐。配比建议先按 1 台控制面配 2 台转发面起步跑一段时间看控制面 CPU 和转发面 PPS再调整。如果控制面 CPU 先到瓶颈加控制面如果转发面 PPS 先到瓶颈加转发面。3.3 第三步用户迁移与割接方案BNC 上线最大的风险不是技术是割接。现网几十万用户不可能一夜之间全迁过去。常见做法是分批次割接按区域或者按 BRAS 逐步迁移。割接前要准备几件事第一BNC 控制面和转发面要和现网 BRAS 互通用户迁移过程中可能需要在两套系统之间跳转。第二地址池要规划好BNC 的地址池不能和现网 BRAS 冲突。第三回退方案要准备好万一 BNC 出问题用户能快速切回原 BRAS。割接步骤通常是这样先选一个用户量小的 BRAS把它的用户迁到 BNC 上观察一周。没问题的话再迁第二个、第三个。每迁一个 BRAS记录用户投诉率、拨号成功率、平均时延。如果投诉率明显上升立刻回退。注意割接窗口选在凌晨 2 点到 5 点别选周末晚上那是用户在线高峰出问题影响面太大。3.4 第四步业务层的增值功能怎么接BNC 的业务层是它区别于传统 BRAS 的关键。传统 BRAS 也能做限速、ACL但业务层能做更灵活的东西比如基于用户标签的差异化加速、和 CDN 联动的内容调度、家长控制、游戏加速。业务层接入 BNC 的方式白皮书里提了标准 API。常见做法是业务层通过 RESTful API 调用控制面下发策略通过转发面的开放接口做流量牵引和标记。下面是一个用 Python 调用控制面 API 下发限速策略的示例# 调用 BNC 控制面 API 下发用户限速策略 # 假设控制面提供 RESTful 接口认证方式为 Token import requests def set_user_rate_limit(api_base, token, user_ip, down_kbps, up_kbps): api_base: 控制面 API 地址如 https://bnc-controller:8443/api/v1 token: 认证 Token user_ip: 用户 IP 地址 down_kbps: 下行限速单位 kbps up_kbps: 上行限速单位 kbps url f{api_base}/policy/rate-limit headers { Authorization: fBearer {token}, Content-Type: application/json } payload { user_ip: user_ip, downstream_kbps: down_kbps, upstream_kbps: up_kbps, priority: 5 # 优先级1 最高10 最低 } resp requests.post(url, jsonpayload, headersheaders, timeout5) if resp.status_code 200: print(f限速策略下发成功: {user_ip}) else: print(f下发失败: {resp.status_code}, {resp.text}) # 示例给用户 10.10.1.100 限速 100Mbps 下行 / 20Mbps 上行 set_user_rate_limit( https://bnc-controller:8443/api/v1, your-token-here, 10.10.1.100, 100000, 20000 )这段代码的逻辑是构造一个 JSON 请求通过 POST 发给控制面的限速接口。参数说明api_base是控制面地址token是认证凭证user_ip是目标用户down_kbps和up_kbps是限速值单位 kbps。priority是策略优先级数值越小优先级越高。实际部署时Token 要从认证服务获取别硬编码在脚本里。业务层接入后要重点验证策略下发时延。用户从拨号到策略生效如果超过 2 秒体验就会变差。测试方法是用脚本模拟用户拨号然后立刻调用 API 下发策略记录从拨号成功到策略生效的时间差。4. BNC部署避坑五条血泪经验4.1 坑一转发面小包性能不达标现象转发面服务器标称 40Gbps 转发实际跑家宽业务时忙时丢包率飙升用户游戏延迟抖动严重。原因标称转发能力通常是用大包1500 字节测的家宽业务大量是小包64 到 128 字节。小包转发靠的是 PPS每秒包数不是带宽。一台服务器大包能跑 40Gbps小包可能只能跑 5Gbps。解决采购前用 64 字节小包做基准测试要求厂商提供小包 PPS 数据。部署后用sar -n DEV 1或者ethtool -S监控实际 PPS如果接近测试上限提前扩容。4.2 坑二控制面会话同步延迟导致用户掉线现象控制面主备切换时部分用户掉线重新拨号才能恢复。原因控制面主备之间的会话同步不是实时的有延迟。切换时备机上的会话状态比主机旧导致部分用户会话丢失。解决选择支持会话实时同步的控制面方案或者把同步周期调到最小。割接前做一次主备切换演练记录掉线用户比例如果超过 1%要求厂商优化。4.3 坑三IPv6地址池规划不当现象IPv6 用户拨号成功但无法上网或者部分网站访问慢。原因IPv6 地址池规划时没有考虑前缀委派PD长度。家宽用户通常需要 /60 或 /56 的前缀如果只给 /64用户家里的多台设备就没法分配公网 IPv6 地址。解决规划 IPv6 地址池时给每个用户预留 /60 前缀。控制面要支持 DHCPv6-PD转发面要能转发 IPv6 流量。测试时用支持 IPv6 的终端验证别只用 IPv4 测。4.4 坑四业务层策略下发风暴现象业务层批量下发策略时控制面 CPU 飙升用户拨号变慢。原因业务层调用 API 没有做限流短时间大量请求打到控制面控制面处理不过来。解决业务层加请求队列和限流控制面加 API 网关做保护。批量操作时分批下发每批之间留间隔。监控控制面 API 响应时间超过 500ms 就告警。4.5 坑五割接回退方案没验证现象割接后 BNC 出问题想回退到原 BRAS发现回退脚本跑不通用户断网两小时。原因回退方案只在实验室验证过没在现网验证。现网 BRAS 的配置和实验室不一样回退脚本里的参数对不上。解决割接前在现网做一次回退演练用真实 BRAS 配置跑一遍回退脚本。回退脚本里的 BRAS 地址、团体字、地址池参数都要从现网采集别用实验室的。5. 用白皮书指导选型三个容易被忽略的验证点白皮书读完之后真正要落地还得落到选型和验证上。我一般会重点盯三个容易被忽略的点。第一个是控制面的会话建立速率。白皮书里可能只提了会话容量但没提建立速率。家宽用户拨号是突发的早上和晚上高峰大量用户同时拨号。如果控制面每秒只能建 1000 个会话而你的 BRAS 迁移过来 10 万用户高峰时拨号就要等 100 秒用户直接投诉。验证方法用脚本模拟 1000 个用户同时拨号记录从第一个拨号成功到最后一个拨号成功的时间。如果超过 30 秒控制面建立速率不够。第二个是转发面的 QoS 精度。白皮书里会提 QoS但精度怎么样要实测。家宽用户对限速很敏感说好 100Mbps实际跑 90Mbps 用户就会投诉。验证方法用 iperf3 打流同时用tc或者转发面自带工具做限速看实际限速值和配置值的偏差。偏差超过 5% 就要问厂商原因。第三个是业务层的策略生效时延。前面提过策略下发时延超过 2 秒体验就变差。验证方法写一个脚本模拟用户拨号拨号成功后立刻调用业务层 API 下发一个限速策略然后立刻用 iperf3 打流看限速是否生效。记录从 API 调用到限速生效的时间差。这个时间差包括 API 处理时间、控制面下发时间、转发面生效时间任何一段慢了都会影响体验。下面是一个用 iperf3 和 tc 验证限速精度的示例# 在转发面服务器上验证限速精度 # 假设用户 IP 为 10.10.1.100限速 100Mbps # 1. 在转发面服务器上配置 tc 限速示例实际用 BNC 控制面下发 tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:10 htb rate 100mbit ceil 100mbit # 2. 在客户端用 iperf3 打流持续 30 秒 iperf3 -c 10.10.1.100 -t 30 -P 4 # 3. 观察 iperf3 输出的带宽如果稳定在 95Mbps 到 100Mbps 之间说明限速精度合格 # 如果低于 90Mbps 或者高于 105Mbps需要检查 tc 配置和转发面 QoS 实现这段脚本的逻辑是先用tc在转发面服务器上模拟限速然后用 iperf3 打流验证。参数说明tc qdisc add添加一个 HTB 队列规则rate 100mbit是限速值ceil 100mbit是最大允许速率。iperf3 的-P 4表示开 4 个并发流模拟多连接场景。实际 BNC 部署时限速由控制面下发不用手动配 tc但验证方法一样。我自己的习惯是每次选型测试都建一个 checklist把会话容量、建立速率、小包 PPS、QoS 精度、策略时延、主备切换时间这六项列进去每项都有明确的通过标准。厂商来测试的时候一项一项过别听他们讲 PPT。有一次我差点被一个厂商的标称值忽悠他们标称小包 PPS 是 1000 万实测只有 300 万差了 3 倍多。后来问他们测试条件原来是用 128 字节测的不是 64 字节。这种坑只有自己测过才知道。希望帮到你。本文还有配套的精品资源点击获取