企业官网建设流程全解析

简介：由中国联通联合华为、中兴、新华三、诺基亚贝尔等厂商于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”这种模糊表述清楚得多。

落地时最容易被忽略的是“拆开之后，会话状态放哪里”。传统 BRAS 上每个用户的 PPPoE 会话只存在于那台设备上；BNC 要求 CP 保存全局会话视图，UP 只保存转发需要的内层会话表。这意味着 CP 必须高可靠，通常采用 1+1 或集群部署，否则用户拨号直接失败。我一般会建议第一步把 CP 当作核心网网元来规划，而不是当网管服务器，它的位置、电源、链路冗余都要按电信级要求来。

2.2 转发面池化与 BNG-UP 选路：会话再也不是“绑死一台设备”

控制面和转发面拆开后，转发面不再是一台台有独立管理 IP 的孤立设备，而是一个资源池。CP 为新用户选 UP 时，会考虑权重、在线用户数、剩余容量、链路质量等因素。这一层决定了 BNC 能不能真的利用好新增的多条接入链路，而不是让流量继续压在某一张旧板卡上。

传统 BRAS 的数据规则是“VLAN 绑设备”，BNC 则引入 VXLAN 或 SRv6 封装的隧道，把用户流量从接入层设备送到 UP。因此，选路不仅发生在 CP，还发生在接入层交换机或 OLT 上。接入设备要学习外层隧道路由，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 落地的组网设计与割接步骤：先旁路、再承载、最后收编旧 BRAS

3.1 三层组网模型：接入层、汇聚转发层、控制层怎么划

现网结构大多是 OLT → 汇聚交换机 → BRAS。BNC 组网建议改为接入层、转发层、控制层三层模型。OLT 或 SR 作为接入层，终结用户 VLAN 并完成外层隧道封装；BNG-UP 资源池作为转发层，终结 VXLAN/SRv6 隧道并执行用户线速转发；BNG-CP 集群作为控制层，只处理会话信令，不承载用户数据报文。

这个模型中，CP 逻辑上挂在转发层之上，物理上甚至可以放在中心机房，与 UP 不在同一个局点。接入层设备通过 underlay 路由到达 UP 的 loopback 地址，UP 之间建立隧道并学习内层主机路由。IP 地址规划要按三层来分配：用户侧地址段、隧道地址段、管理地址段分开，不要混用。

不建议直接复用现有汇聚交换机做 UP。通用交换机只有转发面，没有会话管理，也没有和 CP 的控制通道，堆叠上去最后还得单独接设备。BNC 里的 UP 即使硬件形态是一台白盒交换机，也必须配套厂商或自研的用户面程序，否则它仍然只是一台交换机。

3.2 关键参数：VXLAN 隧道、BFD 检测、会话保留时长的取舍

参数落地比架构设计更容易被卡住，因为每个参数背后都连着用户感知。VXLAN 隧道建立后，先不要急着放业务，用 ping 和 BFd 检查隧道质量。UP 和接入设备之间的 underlay 建议启用快速检测，3×3 是常用起步值；如果 underlay 本身经过多跳公网链路，3 次丢包就会触发切换，此时可以放宽到 5×2。

VXLAN 的 UDP 端口一般用 4789，underlay 的 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 三个维度聚合，就能得到真实用户视角的质量视图。昂贵商业网管可以做，但自建这套轻量系统的成本远低于反复被用户投诉拖垮的代价。

我常用的指标和阈值如下。

如果掉线率升高，先看是否集中在某台 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_output=True, timeout=30) 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、业务链之间的对应关系。

给个示例格式，实际字段按厂商补全即可。

三张表必须放进配置管理库，不要只存在于手机备忘录或个人笔记里。割接是团队行为，不是个人英雄主义，哪天负责割接的同事请假，新来的人拿到这三张表也能在十分钟内定位问题。

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 换个名字，而是把“单台设备的信任”转移到“控制面和转发面的协同”上；协同一旦没验证好，翻车是迟早的事。希望你按这套思路做完后，少走我走过的这段弯路，希望帮到你。

本文还有配套的精品资源，点击获取