简介由中国联通联合华为、中兴、新华三、诺基亚贝尔等厂商于2024年7月发布的《中国联通宽带网络核心网BNC技术白皮书》系统梳理固定宽带网络在业务新机遇下面临的架构挑战提出BNC发展愿景、四层系统架构管理面、控制面、用户转发面、智能算力底座并详解转控分离、服务化架构、信令化业务控制、用户永远在线等关键技术。内容面向电信运营商、网络架构师、通信专业师生及宽带技术研究人员可作为网络规划与技术选型的权威参考。资源包为1个PDF文档大小约1.84MB原文排版完整、目录与图表齐全便于离线查阅与重点标注目前已有455人下载学习。通过阅读读者可系统掌握固定宽带网络重构方向、BNC组网理念与演进路径理解运营商级宽带核心网的标准化思路与落地实践。1. 宽带网络核心网BNC白皮书不是新设备而是把 BRAS 拆开的一次实锤如果你在城域网一线维护过 BRAS大概都有过这种体验设备到寿、板卡停售、业务加不动每次扩容都像在旧楼里加电梯。中国联通宽带网络核心网BNC技术白皮书瞄准的正是这个存量包袱。它把传统 BRAS 的控制面和转发面拆开控制面统一管理用户会话转发面变成可以横向扩展的资源池并引入业务链让增值服务不再依赖物理插卡。这套方案解决的是宽带接入网的容量弹性、设备解耦和运维集中化问题。适合正在做宽带接入网规划、设备选型或者被存量 BRAS 扩容和割接折腾到没脾气的工程师阅读。2. BNC 的技术底座转控分离、转发面池化与业务链怎么选型2.1 从 BRAS 到 BNC控制面和转发面到底拆了什么传统 BRAS 一台盒子把 PPPoE/DHCP 会话管理、Radius 认证、路由计算、流量转发全部做完。用户一多CPU 和会话表项先到瓶颈想扩容要么换板卡、要么换整机而且任何一次软件升级都可能把成千上万个用户踢下线。BNC 的第一步就是把这个黑匣子拆成两层BNG-CP 负责会话生命周期、地址分配、认证授权和路由控制BNG-UP 只承担流量转发、QoS 和隧道封装。两层之间用标准接口通信各厂商实现方式略有差别但架构方向是统一的。把两者拆开后的差异列出来会比“省 CPU”这种模糊表述清楚得多。维度传统 BRASBNC 控制面BNG-CPBNC 转发面BNG-UP会话状态保存在单台设备集中保存在 CP 集群只缓存转发所需的最小表项扩容方式换板卡/换整机CP 横向扩展能力叠加UP 按资源池扩容新增节点即用故障影响单台故障整局用户掉线CP 主备切换会话尽量保持单 UP 故障秒级迁移或重拨升级维护需整机割接CP 灰度升级影响面小UP 升级可分批隔离流量落地时最容易被忽略的是“拆开之后会话状态放哪里”。传统 BRAS 上每个用户的 PPPoE 会话只存在于那台设备上BNC 要求 CP 保存全局会话视图UP 只保存转发需要的内层会话表。这意味着 CP 必须高可靠通常采用 11 或集群部署否则用户拨号直接失败。我一般会建议第一步把 CP 当作核心网网元来规划而不是当网管服务器它的位置、电源、链路冗余都要按电信级要求来。2.2 转发面池化与 BNG-UP 选路会话再也不是“绑死一台设备”控制面和转发面拆开后转发面不再是一台台有独立管理 IP 的孤立设备而是一个资源池。CP 为新用户选 UP 时会考虑权重、在线用户数、剩余容量、链路质量等因素。这一层决定了 BNC 能不能真的利用好新增的多条接入链路而不是让流量继续压在某一张旧板卡上。传统 BRAS 的数据规则是“VLAN 绑设备”BNC 则引入 VXLAN 或 SRv6 封装的隧道把用户流量从接入层设备送到 UP。因此选路不仅发生在 CP还发生在接入层交换机或 OLT 上。接入设备要学习外层隧道路由UP 要学习内层用户路由。两层路由互相独立又通过隧道的封装关系绑定任何一个环节对不上用户就上不了线。我做过的最小可用参数集如下初始值可以按现网实际调整但方向别偏。参数推荐初始值说明VXLAN VNI 划分按用户业务或区域划分建议一个汇聚环一个 VNIVNI 是广播域边界太大容易放大广播和组播流量UP 选路权重按容量权重而非单纯按在线数同厂商设备建议 1:1异构设备按能力折算CP 与 UP 之间 BFD3×3发送间隔 300ms连续 3 次太敏感会误切太迟钝拖累故障收敛会话老化时间PPPoE 1200 秒DHCP 600 秒用于清理异常下线不能比 Radius 会话超时短会话保持时间CP 掉电建议 300 秒给 UP 一个缓冲让用户不用重拨VNI 划分是上线后返工最多的地方。开始按整城一个 VNI 最省事但广播、组播、未知单播都会被放大后面按区域拆分时又要动接入设备配置。白皮书会给出原则但实际取值必须根据现网用户密度来。我建议新建网络直接按 OLT 汇聚环来划 VNI一个环一个不要嫌多。2.3 业务链与增值服务编排BNC 怎么接防火墙和 DPI传统方案里用户流量要过防火墙或 DPI常见做法是在 BRAS 上做策略路由把某些用户或业务引到外部设备。链路一变策略要跟着改碰到多 BRAS 时非常痛苦。BNC 的业务链把“流量去哪里”从转发设备上剥离开CP 为特定用户或业务组定义一条服务链比如“上网 → DPI → 上网行为管理 → 出口 NAT”转发面按链路上的顺序把报文送到对应服务节点服务节点处理完再返回 UP。好处很直接新增一台安全设备不用改接入层只要在控制面里加一个服务节点并把对应用户的业务链路径更新即可。但业务链也有边界服务节点本身可能成为性能和故障的集中点尤其是 DPI 这种深度处理的设备。如果服务链上的某个节点宕机用户流量是断开还是绕过要在设计阶段定清楚。我的建议是第一版只对指定用户群做业务链不要把全网流量都串进去否则排障时很难分清是转发问题还是业务链问题。业务链与地址规划强相关。服务节点与 UP 之间如果走三层路由所有用户内层 IP 都要求在服务节点上可达这个可达性在割接前要专项验证。很多项目把大量时间花在打通 DPI 的回程路由上而不是在 BNC 本身这一点要有心理准备。选型阶段问厂商三个问题业务链节点宕机时流量是否自动 bypass服务节点扩容时会话是否保持控制面下发的业务链路径是否有全局视图。三个都答得干脆的再往下谈。3. BNC 落地的组网设计与割接步骤先旁路、再承载、最后收编旧 BRAS3.1 三层组网模型接入层、汇聚转发层、控制层怎么划现网结构大多是 OLT → 汇聚交换机 → BRAS。BNC 组网建议改为接入层、转发层、控制层三层模型。OLT 或 SR 作为接入层终结用户 VLAN 并完成外层隧道封装BNG-UP 资源池作为转发层终结 VXLAN/SRv6 隧道并执行用户线速转发BNG-CP 集群作为控制层只处理会话信令不承载用户数据报文。这个模型中CP 逻辑上挂在转发层之上物理上甚至可以放在中心机房与 UP 不在同一个局点。接入层设备通过 underlay 路由到达 UP 的 loopback 地址UP 之间建立隧道并学习内层主机路由。IP 地址规划要按三层来分配用户侧地址段、隧道地址段、管理地址段分开不要混用。层设备关键职责关键资源接入层OLT、SR、接入交换机用户 VLAN 终结、外层隧道封装、DHCP Relay/PPPoE 透传上联带宽、隧道出口 hash 能力转发层BNG-UP 资源池2 台起步VXLAN 终结、内层路由、QoS、组播复制CPU/NPU 会话容量、VNI 数量、BFD 会话数控制层BNG-CP 集群PPPoE/DHCP 会话管理、Radius 交互、地址池管理、UP 选路集群数据库性能、南向接口通道、AAA 并发能力不建议直接复用现有汇聚交换机做 UP。通用交换机只有转发面没有会话管理也没有和 CP 的控制通道堆叠上去最后还得单独接设备。BNC 里的 UP 即使硬件形态是一台白盒交换机也必须配套厂商或自研的用户面程序否则它仍然只是一台交换机。3.2 关键参数VXLAN 隧道、BFD 检测、会话保留时长的取舍参数落地比架构设计更容易被卡住因为每个参数背后都连着用户感知。VXLAN 隧道建立后先不要急着放业务用 ping 和 BFd 检查隧道质量。UP 和接入设备之间的 underlay 建议启用快速检测3×3 是常用起步值如果 underlay 本身经过多跳公网链路3 次丢包就会触发切换此时可以放宽到 5×2。VXLAN 的 UDP 端口一般用 4789underlay 的 ECMP 哈希要包含内层 MAC/IP否则流量极化。外层 IP 对固定时大量用户流量会被扔到同一条物理链路上。开启 flow entropy 或等价配置后哈希会加入内层五元组链路分担才能均匀。上线前可以用一组通用命令确认隧道和检测状态设备厂商不同命令会有差异但思路通用# 在 UP 上确认 VXLAN 隧道状态 ip -d link show vxlan1 # 在接入设备上确认 BFD 会话 show bfd peers # 在 CP 上查看在线用户总数与分布 bnc-cp-cli show subscriber summary第一条命令看隧道是否处于 up 状态第二条看 BFD 会话是否满配且无 Down第三条是全局会话视图。如果隧道 up 但 BFD down多半是设备之间防火墙或策略路由阻断了检测报文如果 BFD up 但隧道 down优先查 VNI 配置和本端 source interface。会话保留时间是最容易拍脑袋的参数。CP 主备切换时UP 侧会话保留时间决定了用户是否重拨。设得太短CP 还在恢复用户已掉线设得太长地址池和会话表被异常占用新用户拨不上号。我一般按 Radius 会话超时的一半来设同时把 UP 侧老化时间设得比 CP 短让 UP 先清理CP 后核对。割接期间把保留时间临时调大可以缓解瞬断投诉但割接完成后必须调回来。3.3 割接步骤先旁路、再承载、最后收编存量 BRAS割接的顺序比速度重要。第一步先在现网旁挂 BNG-CP 和两台 UP与存量 BRAS 并行只接入测试 OLT。第二步打通 underlay让接入层设备能到达 UP 的 loopback 地址建立 BFD。第三步在 Radius 和地址池侧添加新 CP 的配置但只放测试 VLAN 的认证。第四步选一个用户量低于 5% 的 OLT把用户 VLAN 的网关引流到 UP观察拨号成功率、在线用户数、投诉工单。第五步逐台收编 OLT每台观察 24 小时。第六步全部用户迁移完成后再回收旧 BRAS 的端口和板卡。每一步都要留回退。BNC 的优势在这里体现因为旧 BRAS 的配置没有改动回退只需把用户网关切回旧设备并不需要重装任何东西。我最担心的是团队在割接第三天就开始清理旧 BRAS 配置结果新网络一个隐藏故障导致大面积掉线旧配置又找不齐。后悔药不是练出来的是提前留出来的。旧设备的配置和路由策略建议保留至少一个月不要急着退网。每台 OLT 收编前检查三个数字这台 OLT 下的在线用户数、认证成功率、Radius 平均响应时延。三者中有任何一个异常就停住当前批次不要继续切下一台。批量切换的快感会掩盖问题等第五台出事时前面四台都要回退。4. BNC 落地最容易翻车的四个位置现象、原因与排查路径4.1 拨号成功率出现“断崖式下降”用户会话在割接瞬间被踢现象割接某台 OLT 后在线用户数短暂下降重拨后恢复拨号成功率从 99% 跌到 90% 以下持续 10 分钟左右。时间点正好落在割接窗口内。原因有两个。一是 CP 给 UP 下发会话表项和接入设备引流之间有时间差用户终端还在发起 PPPoE 协商UP 还没有内层会话表导致 PPP LCP 协商超时。二是割接瞬间 CP 与 Radius 之间的认证并发量暴增响应超时用户端判定认证失败。解决先把单批次用户量调小比如每批不超过 500 户在 CP 上打开会话建立缓冲窗口等 UP 表项建立后再允许业务流量进入同时提升 CP 到 Radius 的并发连接数并缩小 Radius 超时判定。割接期间把拨号失败告警阈值调高避免误报淹没真实问题但认证超时日志必须保留事后复盘只看这一个指标。4.2 资源池利用率不均有的 UP 跑满有的空闲现象新 UP 加入后在线用户没有按预期分布。查 RRU 发现一台 UP 的 CPU 60%另一台只有 20%但两台在线用户数几乎一样。原因CP 的 UP 选择策略按在线用户数做最小连接而不是按实际带宽或流量。用户数量均衡不代表负载均衡视频大流量用户可能集中在一台 UP 上。另外用户源 IP 哈希导致同一 OLT 下的用户被分到同一台 UP负载分布跟着 OLT 走而不是跟着资源走。解决把选路权重改为容量加权和实时负载加权对小流量用户和大流量用户分开策略或者让 CP 定期统计每台 UP 的转发流量再按流量基线做二次分配。这里有个玄学不能只看在线用户数要看每台 UP 的出向带宽、会话表项和 CPU。上线一周后拉一次趋势图比割接当天看一小时数据有意义得多。4.3 多链路利用率上不去哈希极化还是负载不均现象接入层到 UP 之间做了 4×10GE 捆绑但实际只有一条链路跑满其余基本空闲。流量一上来单条链路先拥塞用户测速看到明显劣化。原因VXLAN 外层哈希使用源目 IP 和 UDP 端口。如果多台 OLT 的上行流量都封装到同一个外层 IP 对哈希结果会因为“熵不足”集中到同一条 ECMP 路径。简单说外层五元组里只有端口号在变而端口号变化范围有限极端情况下所有报文哈希到一个桶里。解决在接入设备和 UP 上开启内层五元组参与 underlay 哈希让哈希字段包含用户 MAC、内层 IP、端口把 VNI 分散到多个外层 IP 对增加熵来源检查 LACP 捆绑的 hash 配置不要只选源目 MAC。验证方法是用接口计数器对比各链路 5 分钟流量如果最大最小链路偏差超过 20%按上面的思路逐项排查。4.4 Radius/AAA 交互超时地址池回收不干净引发“幽灵会话”现象割接后在线用户数正常但地址池不可分配地址持续增长新用户拨号失败。查看 Radius 在线表发现大量已下线用户仍显示在线。原因CP 上会话已删除但 UP 的会话表没清干净或 Radius 收到 Acct-Stop 前地址还占着。BNC 的会话和地址分配由 CP 控制但如果 UP 没有及时上报会话释放CP 不知道地址该回收形成了“幽灵会话”。解决统一设置 UP 侧老化时间小于地址池租期确保异常下线能被兜底清理。更关键的是做三方比对CP 在线表、UP 会话表、Radius 在线表三方应该在同一时间点对齐。中间可以用命令导出对比# 分别导出 CP 在线表、UP 会话表、Radius 在线表比对 IP 和 MAC bnc-cp-cli show subscriber | sort cp_online.txt up-cli show session | sort up_online.txt radius-cli show online | sort radius_online.txt diff cp_online.txt radius_online.txt | head命令字面会随厂商不同而变但思路一致。三方不一致时优先看 UP 侧会话表如果 UP 里有、CP 里没有是会话释放上报丢失如果 CP 里有、Radius 里没有是计费停止报文没送到。两边的超时参数都要留日志不能只靠设备面板上的在线数下结论。5. 白皮书没写的验证手段用户级遥测与流量镜像5.1 用户级遥测把拨测下沉到会话级指标常规拨测只能验证“拨号通不通”测不到 BNC 内部的转发质量。白皮书讲架构和组网但没告诉你割接后拿什么证明系统是健康的。我的做法是建一套用户级遥测从 CP 和 UP 按用户维度采集上线、下线、认证时延、异常掉线等事件。数据源不复杂CP 的 syslog 或 Kafka 流里已有用户上线/下线日志UP 每隔一段时间上报会话状态。把这些事件写入 ClickHouse 或 PostgreSQL再按 UP、OLT、VLAN 三个维度聚合就能得到真实用户视角的质量视图。昂贵商业网管可以做但自建这套轻量系统的成本远低于反复被用户投诉拖垮的代价。我常用的指标和阈值如下。指标采集位置建议阈值PPP 建立时延CP 会话日志P95 1.5 秒认证时延RadiusCP 与 AAA 之间P95 2 秒UP 异常掉线率CP 会话日志 0.5%地址池回收时延CP 地址池模块 60 秒如果掉线率升高先看是否集中在某台 UP再查那台 UP 的 BFD 状态和隧道抖动。如果地址池回收时延变大优先查 Radius 计费停止报文而不是查 UP 配置。这套指标在割接后要连续跑一周别只在割接当天看。5.2 流量镜像与模拟拨测验收新老设备的一致性割接前用流量镜像把真实用户流量从旧 BRAS 复制到测试 UP新老并行对比是成本最低的验收方式。镜像流量只能用于测试不能真正影响现网用户。在汇聚交换机上配置 SPAN把上行口流量镜像到测试口测试 UP 和现网 BRAS 分别接不同 VNI避免地址冲突。用模拟拨测工具在测试环境重放认证流程再对比新旧设备的关键表项用户 ARP/ND 表、路由属性、QoS 队列映射。这一步能提前发现很多白皮书不会写的差异比如新 UP 默认把用户放到 low-priority 队列而旧 BRAS 放到 normal-priority用户测速直接砍半。拨测采集可以用一段简单脚本模拟 PPPoE 拨号并统计成功率与建立时延import subprocess, time, statistics def dial_once(interface): # 通过 pppd 发起一次拨号返回成功与否和建立耗时 start time.time() result subprocess.run([pppd, call, test, unit, interface], capture_outputTrue, timeout30) cost time.time() - start return result.returncode 0, cost if __name__ __main__: results [dial_once(eth0.100) for _ in range(20)] success sum(1 for ok, _ in results if ok) costs [c for ok, c in results if ok] print(f成功率 {success}/{len(results)}平均建立时延 {statistics.mean(costs):.2f}s)脚本里的 pppd 只是拨号发起工具真正的会话由 UP/CP 处理。测试 DHCP 场景时可以换成 dhclient逻辑类似。注意每次拨号间隔不要太短否则 Radius 侧的防重复认证策略会拒绝会话制造假失败。我一般单次间隔 3 秒20 次拨测大概一分钟跑完。真实用户流量镜像和模拟拨测组合起来能验证“新设备在真实负载下不丢用户状态”这一条这是单测永远给不了的保证。6. 守住割接边界三张表和两条命令6.1 割接前必填的三张表端口、IP、VNI 映射割接期间最多的事故都源于“这条链路到底对应哪台设备”。我的习惯是先填三张表再动手。第一张是端口映射表记录 OLT 上联口、接入交换机端口、UP 下行口与外层 IP 的对应关系。第二张是 IP 规划表记录用户网关、UP loopback、CP 南向 IP、Radius IP每个地址都要有用途说明。第三张是 VNI 映射表记录用户 VLAN、VNI、业务链之间的对应关系。给个示例格式实际字段按厂商补全即可。OLT上联口接入交换机口UP 口VNI用户 VLANOLT-010/110G-3UP-1/0/11001101-110OLT-020/210G-4UP-2/0/11002101-115三张表必须放进配置管理库不要只存在于手机备忘录或个人笔记里。割接是团队行为不是个人英雄主义哪天负责割接的同事请假新来的人拿到这三张表也能在十分钟内定位问题。6.2 两条命令一条看会话分布一条看隧道抖动日常巡检不需要开一堆网管页面两条命令足够。第一条看会话在哪些 UP 上分布判断负载是否均衡第二条看 VXLAN 隧道健康度判断 underlay 质量。# 看会话在哪些 UP 上分布 bnc-cp-cli show subscriber count by up # 看 VXLAN 隧道抖动基于 BFD 的丢包率和时延 up-cli show tunnel health vxlan1第一条发现会话分布不均第二条发现转发面链路质量。两条命令的输出如果都和预期一致大部分夜间故障可以等早上再处理如果任一输出异常立刻进入排查流程。厂商没有这两个命令时可以通过 netconf/yang 接口自己拉数据格式不同指标含义相同。我做 BNC 验收时吃过一次亏所有常规指标都通过结果割接后组播电视黑屏原因是 UP 的组播复制模式配错了。后来我在三张表之外又加了一项“业务专项验收”把组播、IPTV、专线、VoIP 都走一遍。这些血泪经验挺零散但核心就一句话BNC 不是把 BRAS 换个名字而是把“单台设备的信任”转移到“控制面和转发面的协同”上协同一旦没验证好翻车是迟早的事。希望你按这套思路做完后少走我走过的这段弯路希望帮到你。本文还有配套的精品资源点击获取