企业官网建设流程全解析

凌晨两点半接到值班电话，说某片区几千户宽带集体掉线，拨号全部超时。赶到机房看监控，OLT侧光路正常，核心出口流量正常，问题卡在中间那台BRAS上——CPU利用率飙到九十多，PPPoE会话数在往下掉。那一刻我特别能理解为什么老网工都说：城域网里可以宕一台交换机，可以重启一台路由器，但BRAS不能出事，它一出事就是一片用户直接断网。

这篇内容围绕**电信运营商BRAS（Broadband Remote Access Server，宽带远程接入服务器）**展开，把它在运营商网络里的位置、干的活、用到的协议、实际部署和排障的坑，尽量讲透。如果你刚接触城域网、要做BRAS开局配置、或者被用户掉线问题折磨过，这篇应该能帮你少走些弯路。我会从拓扑位置讲起，一路讲到认证、地址池、限速、双机热备和云化演进，中间穿插我自己踩过的坑。

1. 从一条宽带账号说起：BRAS为什么是城域网里最不能停的那台设备

用户在家点一下"宽带连接"，输入账号密码，几秒钟后就能上网。这几秒钟里发生的事情，比大多数人想象的要复杂得多。而要理解BRAS，最好的切入点不是看它的硬件参数，而是顺着一个数据包往上走，看它到底在哪一层被"拦下来"处理。

1.1 用户按下拨号键之后，数据包走了哪条路

先理一条最简单的家庭宽带链路：光猫（ONT）出来一根网线接路由器，光猫通过PON口上联到小区机房的OLT，OLT再通过汇聚交换机把流量送到BRAS，BRAS往上是核心路由器（CR），再往外就是骨干网和互联网出口。

关键在于，用户在家发出去的第一个包，源IP往往是0.0.0.0——因为它还没拿到地址。这个包带着用户的MAC、VLAN标签，一路被送到BRAS。BRAS要做的第一件事就是：识别这个用户是谁。它通过PPPoE发现阶段或者DHCP的方式，跟用户侧建立会话，然后去RADIUS服务器验证账号密码，验证通过后再给用户分配一个IP地址，同时把这户人家的限速策略、VLAN信息、组播权限一起绑到这个会话上。

这整个过程就是BRAS存在的意义：它是运营商网络里唯一一台同时掌握"用户是谁、给了什么地址、限速多少、能访问什么"的设备。核心路由器只认IP前缀，不认用户；OLT只做二层透传，不关心业务；只有BRAS站在二三层交界处，把用户身份和IP转发绑定在一起。

1.2 BRAS在拓扑里的真实位置和它对接的上下层设备

行业里常说BRAS属于"业务控制层"（有的资料叫城域网业务接入控制层）。它的典型位置是在汇聚层和核心层之间。

往下看，BRAS对接的是汇聚交换机或者直接对接OLT。对接口通常是万兆或千兆以太网口，跑的是VLAN或者QinQ封装。外层VLAN（SVLAN）一般用来标识业务类型或者BRAS域，内层VLAN（CVLAN）用来标识具体用户或者OLT端口。这种双层标签的设计不是随便定的——它让BRAS可以用一个物理口对接多个OLT，同时还能精确区分到每一户。

往上看，BRAS对接核心路由器（CR）或者业务路由器（SR）。这里跑的是纯IP转发，路由协议常见的是OSPF、IS-IS或者BGP。BRAS上会有一张用户地址池的路由，通常是以32位主机路由或者聚合路由的方式发布给上游，这样回程流量才能找到对应的用户会话。

还有几个容易被忽略的对接面：

• RADIUS服务器：认证、授权、计费全靠它，BRAS和RADIUS之间走UDP 1812/1813（老设备可能是1645/1646）。
• DHCP服务器：在IPoE场景下，地址分配可能不由BRAS本地完成，而是relay给专门的DHCP Server。
• 网管和日志系统：SNMP、Syslog、NetFlow，用来做监控和用户行为溯源。
• 组播源：IPTV场景下，BRAS要跟组播源和上游PIM路由器对接，做组播复制。

我见过一些新手把BRAS当成一台普通的三层交换机来配，结果用户能拨上号但上不了网，或者上网正常但IPTV黑屏。根源就在于没理解BRAS这几个对接面各自承担什么职责。所以下面几节，我按"它到底干了哪些活"来拆。

2. 认证、地址、限速、计费：BRAS的四件核心差事

很多人第一次看BRAS配置，会被几百行命令吓到。但如果把它的功能归归类，其实就四件核心差事：认人、给地址、限速、记账。把这四件事理清楚，配置再长也能看懂每一段在干什么。

2.1 AAA与RADIUS交互的报文细节

AAA是Authentication（认证）、Authorization（授权）、Accounting（计费）的缩写。BRAS作为RADIUS客户端，跟RADIUS服务器之间通过几类报文交互。

用户拨号请求上来，BRAS先发Access-Request，报文里带用户名、密码（或者CHAP挑战响应）、NAS-IP-Address、NAS-Port等属性。RADIUS服务器查完数据库，回Access-Accept或者Access-Reject。如果接受，Accept报文里通常还会带一堆授权属性，比如：

• Framed-IP-Address：指定给用户的IP
• Framed-Pool：指定用哪个地址池
• Filter-Id：下发的ACL或者QoS策略名
• Session-Timeout：会话超时时间
• Acct-Interim-Interval：计费中间报文的上报间隔

用户上线后，BRAS发Accounting-Request (Start)；上网过程中按间隔发Interim-Update；下线时发Stop。运营商靠这些计费报文算出用户上了多久、用了多少流量。

这里有个实操坑特别常见：RADIUS超时和重传次数配置不合理。默认超时3秒、重传3次，在高并发上线时段，RADIUS服务器响应慢一点，BRAS就会认为认证失败，用户直接被拒。我一般会把超时调到5秒，重传次数根据RADIUS集群性能调整，同时在BRAS上配多个RADIUS服务器地址做备份，避免单点故障导致整片区拨不上号。

2.2 地址池的几种下发方式与踩坑点

用户地址从哪来？主要有三种方式：

1. BRAS本地地址池：在BRAS上直接配置地址池，用户上线时从本地池分配。
2. RADIUS下发：RADIUS通过Framed-Pool告诉BRAS用哪个池，池本身还在BRAS上。
3. DHCP Relay到外部服务器：IPoE场景常见，BRAS把DHCP请求relay给专门的DHCP Server。

本地地址池的配置看起来简单，但有几个细节值得注意。地址池要用network命令声明网段，用gateway指定网关，用excluded-ip-address排除掉不能分配的地址（比如网关地址、保留地址）。如果地址池配错网段掩码，会出现用户拿到地址但网关不通的情况。

我遇到过最典型的一次事故：某BRAS地址池扩容，工程师手抖把192.168.10.0/23写成了192.168.10.0/24，结果新扩的一半地址根本用不了。上线测试时因为只测了头几个地址，没发现问题，等真实用户分配到这个范围才陆续报障，排查了大半天。所以地址池变更后，一定要用命令验证池的范围和可用地址数，别只看配置有没有报错。

还有一个IPv6的坑。双栈场景下，BRAS要同时处理IPv4的IPCP和IPv6的IPCPv6/ND/DHCPv6。有些设备对IPv6地址池的prefix长度处理跟IPv4不一样，配成/64还是/56要提前规划好，否则用户拿到的PD前缀在上游路由不可达。

2.3 限速到底限在哪一层：CAR与HQoS的区别

运营商卖宽带给用户标称100M、500M、1000M，这个限速就是在BRAS上做的。但"限速"这两个字背后，技术实现差别很大。

最基础的是CAR（Committed Access Rate），基于令牌桶做流量监管，通常用在用户上行方向。它的特点是简单直接，超速的报文直接丢弃或降级。问题是它比较"粗暴"，多个业务共享一个物理口时容易互相影响。

稍微精细一点的是Shaping（流量整形），用缓存把突发流量平滑掉，通常用在用户下行方向，用户体验更平顺，但会引入额外时延，缓存也不能开太大。

再往上是HQoS（Hierarchical QoS），分层调度：物理端口一层，用户组一层，单个用户一层，甚至用户内不同业务（上网、IPTV、VoIP）再分一层。这样能保证IPTV这种对时延敏感的业务优先转发，同时限制P2P下载不把带宽占满。

实际配置时，限速方向经常被搞反。用户上行是指从用户到网络方向，在BRAS的入接口做CAR；用户下行是从网络到用户方向，在出接口做Shaping或者HQoS。如果配反了，会出现下载不限速、上传却很慢的怪现象。我的经验是：先在BRAS上确认业务流量的入接口和出接口，再决定限速策略挂在哪一侧，配完用打流仪或大文件下载双向验证。

3. PPPoE和IPoE两条接入路径的实际差异

BRAS接用户有两大流派：PPPoE和IPoE。这两条路径在协议栈、组网方式、适用场景上差别很大，很多故障的根因就是没搞清楚用户到底走的是哪条路。

3.1 PPPoE的会话建立过程与开销

PPPoE（Point-to-Point Protocol over Ethernet）是家庭宽带最经典的接入方式。它把PPP帧封装在以太网帧里，分两个阶段：

发现阶段：

• 用户发PADI（PPPoE Active Discovery Initiation）广播
• BRAS回PADO（Offer）
• 用户发PADR（Request）
• BRAS回PADS（Session Confirmation），分配Session ID

会话阶段：

• LCP协商（链路层参数）
• 认证（PAP或CHAP）
• IPCP协商（分配IPv4地址）
• 之后进入正常数据传输

PPPoE的好处是成熟、稳定、天然支持AAA和会话管理，每个用户一条独立会话，计量和限速都好做。缺点是有额外开销：每个以太网帧要加PPPoE头和PPP头，MTU从1500降到1492，部分应用需要做MSS调整。另外，PPPoE发现阶段的广播报文在用户量大时会对BRAS造成一定压力。

CHAP认证比PAP安全，因为它不传明文密码，而是传挑战响应。但CHAP需要RADIUS支持，配置上稍微复杂一点。我一般建议默认用CHAP，除非对接的老系统只认PAP。

3.2 IPoE在IPTV和智能组网场景下的优势

IPoE（IP over Ethernet，也叫DHCP接入）不走PPP，用户直接通过DHCP拿地址，或者通过ND/RA拿IPv6地址。它的优势很明显：

• 没有PPP封装开销，MTU保持1500
• 上线速度快，省掉发现阶段和LCP/IPCP协商
• 适合机顶盒、智能网关等设备，这些设备往往不擅长跑PPPoE
• 组播复制效率高，IPTV场景下BRAS可以直接用IGMP做频道切换

但IPoE也有代价：用户身份识别比PPPoE弱一些，通常靠VLAN、MAC地址或者option信息做绑定。如果只靠MAC，用户换设备或者MAC被伪造时会有安全隐患。所以实际部署中，IPoE一般会配合DHCP Option 82（携带接入设备信息）和源MAC+VLAN绑定来做认证。

现在很多运营商采用混合接入：上网业务走PPPoE（用户习惯、便于计费），IPTV走IPoE（组播效率高），VoIP可能单独走一条通道。BRAS要同时处理这几类业务，配置上要按VLAN或者端口区分。

3.3 混合接入时VLAN规划容易出的问题

混合接入最怕VLAN规划乱。我总结几个高频问题：

问题一：内外层VLAN冲突。外层VLAN标识业务（比如VLAN 100走上网，200走IPTV），内层VLAN标识用户。如果某个OLT的内层VLAN范围跟另一台OLT重叠，BRAS上就可能把两个用户的会话搞混。解决办法是做VLAN归一化，或者在BRAS上按端口+外层VLAN区分。

问题二：QinQ终结位置不对。BRAS要终结QinQ，就要在接口上配qinq termination之类的命令，把两层标签都识别出来。如果只在汇聚交换机上透了外层标签，BRAS看不到内层，就无法精确识别用户。

问题三：广播域过大。一个外层VLAN下挂太多用户，PPPoE发现报文广播泛洪会消耗BRAS资源。通常会把一个外层VLAN下的用户数控制在合理范围，或者用PPPoE Intermediate Agent（PPPoE IA）来减少广播。

问题四：IPTV组播VLAN和上网VLAN混用。组播流量如果和单播走同一个VLAN，BRAS上的组播复制压力会传导到单播转发，影响上网体验。最好是物理口或者子接口分离。

这些问题在开局规划阶段就要想清楚，等用户上线后再改，往往要断网割接，代价很大。

4. 转控分离与vBRAS：传统单机架构的瓶颈在哪

BRAS设备天生就是"重"设备——会话数动辄几十万，表项庞大，对CPU、内存、转发芯片要求都高。传统单机BRAS用了很多年，但流量增长和业务灵活性的需求，把它推向了转控分离和虚拟化。

4.1 传统BRAS的三个硬瓶颈

瓶颈一：扩容粒度粗。一台BRAS槽位有限，扩容要加板卡甚至换整机，周期长、成本高。用户数增长是渐进的，但设备扩容是台阶式的，很容易出现"差一点不够用"的尴尬。

瓶颈二：资源利用率不均。城域网里各片区用户数、流量不均衡，有的BRAS跑满，有的闲着。传统架构没法把闲的资源调给忙的区域，只能靠人工割接。

瓶颈三：新业务上线慢。传统BRAS的功能和软件版本强绑定，想支持一个新的认证方式或者新的QoS策略，得等厂商出新版本，再全网升级，周期以月计。

这三个瓶颈，本质上是"控制面"和"转发面"绑死在一台机器上导致的。控制面负责认证、会话管理、路由计算，转发面负责实际报文处理。两者绑在一起，资源没法独立扩展。

4.2 CU分离后的报文转发路径变化

vBRAS的核心就是CU分离：控制面（CP，Control Plane）和转发面（UP，User Plane）分开部署。

控制面集中部署在云资源池里，负责认证、地址管理、会话控制、策略下发。转发面部署在城域网边缘，靠近用户，负责实际的报文转发、QoS执行、组播复制。

两者之间通过隧道（常见的是VXLAN或者GTP-U）连接。用户上线时，认证由CP处理；认证通过后，CP把会话表项下发给UP；后续用户的数据报文直接在UP上转发，不再绕到CP。

这样做的好处很直接：

• 转发面可以按需扩容：流量大的片区多放几个UP，流量小的片区少放
• 控制面统一管理：全网策略一致，新业务在CP上升级一次就生效
• 资源池化：闲的UP资源可以调给忙的区域

4.3 云化BRAS部署时容易忽略的细节

CU分离听起来很美，但实际部署有几个细节不能忽略。

第一，CP和UP之间的隧道质量。隧道如果经过拥塞链路，会话建立和下发的时延会变大，用户上线变慢。所以CP到UP的承载网络要有足够的带宽和低时延保障，最好走独立的DCN或者SR隧道。

第二，UP的本地存活能力。如果CP和UP之间的连接断了，UP不能立刻把所有用户踢下线，而应该进入"本地存活"模式，维持已有会话，只是不能新建会话和处理认证。这个能力在配置时要确认，否则CP一抖动就是大面积断网。

第三，会话表项的同步。CP要把会话信息实时同步给UP，UP也要把流量统计回传给CP做计费。同步频率和批量策略要平衡：太频繁占带宽，太稀疏会导致计费不准或者倒换后会话丢失。

第四，运维习惯的转变。传统BRAS上，网工习惯telnet上去敲命令看会话。vBRAS时代，会话分散在多个UP上，得靠集中管理平台查。这对排障思路是个不小的挑战。

5. 双机热备与故障倒换：会话同步到底同步了什么

BRAS是最不能停的设备，所以双机热备几乎是标配。但"配了热备"和"热备真的能无缝倒换"是两回事，中间差的就是对同步机制的理解。

5.1 主备模式与VRRP的配合

最常见的部署是主备模式：两台BRAS，一台主用，一台备用，通过VRRP虚拟出一个网关IP。用户拨号时看到的是虚拟网关，主设备处理业务，备设备待命。

VRRP负责检测和切换。主设备定时发VRRP通告，备设备收不到就认为主设备故障，自己升为主。这里有个细节：VRRP的检测间隔决定了倒换速度。默认1秒通告间隔，加上切换时间，用户可能感知到几秒断网。如果对倒换速度要求高，可以配BFD（Bidirectional Forwarding Detection）做毫秒级检测，配合VRRP快速切换。

但VRRP只管网关层面的切换，用户会话能不能续上，取决于会话同步做得好不好。

5.2 会话同步的本质是同步哪些表项

热备同步不是简单地把配置文件复制一份，而是实时同步运行时的会话数据。核心表项包括：

• 用户会话表：用户名、IP地址、MAC、VLAN、PPP Session ID
• 认证授权信息：用户能用什么策略、限速多少
• 地址池状态：哪些地址已分配、哪些空闲
• 组播组信息：用户加入了哪些组播组
• 计费状态：用户上线时间、流量计数

同步通常分两种：批量同步（设备启动时全量同步一次）和实时同步（会话建立、删除、状态变化时增量同步）。实时同步的通道可以用专用心跳线，也可以走业务口，但独立心跳线更可靠。

我踩过一个坑：某次热备倒换后，大部分用户正常，但一部分IPTV用户黑屏。排查发现是组播组信息没有纳入同步范围。单播会话同步了，组播状态没同步，倒换后用户还在原来的组播组里，但备设备不知道，就不给复制流量了。后来把组播组状态加入同步表，问题解决。所以配置热备时，一定要确认业务涉及的所有状态是否都在同步清单里。

5.3 倒换过程中的用户感知

理想状态下，热备倒换用户应该无感知。但实际能做到什么程度，取决于几个因素：

• 会话同步是否完整：缺什么状态，倒换后就丢什么业务
• 切换速度：BFD+VRRP可以做到毫秒级检测加快速切换，但会话恢复还需要时间
• 地址池一致性：备设备如果不知道哪些地址已分配，可能把已用地址再分配给别人，造成IP冲突
• 上游路由收敛：备设备升主后，要向上游发布用户路由，路由收敛时间也会影响体验

我的经验是：热备配置完必须做真实的倒换测试，不能只看主备状态显示正常。测试时用真实用户拨号、看视频、下载，然后在主设备上断电或者拔线，观察用户业务中断时间和恢复情况，记录哪些业务受影响。有条件的话，每季度做一次倒换演练，别等真出事才发现热备是摆设。

6. 排障实录：用户拨不上号、上网慢、限速不准怎么查

BRAS的故障现象往往很"集中"——一出现就是一片用户，排查压力大。我把常见故障分成三类，讲一下我的排查链路。

6.1 拨号失败的四段排查链路

用户报"拨不上号"，别急着上BRAS看配置，先按四段排查：

第一段：线路和光路。确认OLT侧光功率正常，用户光猫在线。如果光路有问题，BRAS上根本看不到会话请求，这时候查BRAS是白费功夫。

第二段：二层可达性。确认用户VLAN能透传到BRAS，中间汇聚交换机没有把VLAN过滤掉。可以在BRAS上抓包，看有没有收到PADI或者DHCP Discover。收不到就是二层问题。

第三段：认证。看到请求但认证失败，就要查RADIUS。看BRAS上RADIUS是否可达，看RADIUS服务器日志里有没有对应的Access-Request，看返回的是Accept还是Reject。Reject通常是账号密码错、欠费停机、或者并发数超限。

第四段：地址分配。认证通过了但拿不到地址，查地址池是不是耗尽、配置的网关是否正确、DHCP relay是否可达。地址池耗尽是很常见的原因，尤其是用户增长快但没及时扩容的片区。

这四段排查下来，90%的拨号问题能定位。关键是按链路顺序走，别跳步，否则容易在无关的地方浪费时间。

6.2 上网慢但测速正常的排查思路

"用户说上网慢，但测速软件跑满带宽"——这种问题最让人头疼，因为链路和带宽都没问题，问题出在体验上。

常见原因有几个：

DNS解析慢。测速软件大多直接用IP，不依赖DNS，所以测速正常。但用户访问网站要先解析域名，如果BRAS下发的DNS服务器响应慢，打开网页就会觉得卡。排查方法是在用户侧用nslookup测解析时间。

TCP建链慢。如果BRAS上配了会话老化时间过短，或者NAT表项太小（部分场景BRAS要做NAT），用户频繁建链会变慢。

限速策略造成突发受限。有些限速配置对突发流量不友好，网页加载时的大量并发连接瞬间触发限速，用户感觉卡顿。可以适当放宽突发桶大小。

IPv6优先导致的回退。双栈场景下，如果用户优先走IPv6但IPv6路径质量差，会出现访问慢甚至超时后回退到IPv4的情况。可以用ping6和traceroute6验证IPv6路径质量。

上游路由抖动。BRAS到核心的路由如果频繁变化，用户访问不同目标可能走不同路径，体验不稳定。看BRAS的日志和路由表变化频率。

这类问题没有一招鲜，得结合用户具体反馈（打开什么网站慢、什么时间段慢）来缩小范围。

6.3 限速不生效的常见原因

用户投诉"我买的是500M，怎么只有100M"，或者"限速根本没起作用，我能跑满千兆"，都属于限速问题。

原因一：策略挂错位置。前面说过，上行CAR、下行Shaping，配反了就不生效。检查限速策略是挂在用户会话上还是物理口上，方向对不对。

原因二：策略没被引用。配置了限速模板，但用户上线时RADIUS下发的Filter-Id跟模板名不一致，或者模板没绑定到域（domain）上，导致策略根本没生效。这个坑很隐蔽，配置看着都对，就是不起作用。

原因三：多业务共享导致测量偏差。如果用户同时跑上网和IPTV，而限速只针对上网业务，用户测出来总带宽可能超过限速值，但那是IPTV的流量，不是上网被放行了。

原因四：硬件转发能力不足。低端BRAS在满配限速策略时，转发芯片可能达不到线速，导致实际限速值偏低。这种情况要看设备规格，必要时升级硬件或者减少单板用户数。

排查限速问题，最直接的方法是用打流仪从用户侧发包，同时在BRAS上看策略命中计数和接口流量统计，两边对照就能看出策略到底有没有生效。

关于BRAS这个话题，还有太多细节可以展开——比如组播复制怎么优化、IPv6过渡方案怎么选、网管系统怎么对接。我在实际工作中最大的体会是：BRAS的配置本身不难，难的是理解每一行配置背后的业务逻辑和故障影响。你把用户上线想象成一条流水线，认证、地址、限速、计费每个环节都可能卡住，排障就是顺着流水线找卡点。另外，任何变更之前先在测试环境验证，尤其是地址池和限速策略这种影响面大的配置，宁可多花半天测试，也别在生产上赌运气。