做无线网络运维的最怕半夜手机响。不是家里那位查岗是公司几百个AP同时掉线领导在群里连发三个问号。AC作为无线网络的“大脑”一旦出问题整片办公区、厂房、仓库的Wi-Fi全部瘫痪业务直接停摆。所以AC的高可用方案从来不是“要不要做”的问题而是“怎么做才真正靠谱”的问题。这篇内容只聊一件事AC的双链路备份与冷热备机制。我会把双链路备份和冷热备这两个概念彻底拆开讲清楚——它们各自解决什么问题、底层怎么工作、部署时有哪些坑、切换时到底会发生什么以及我在实际项目里踩过哪些雷。适合刚接触无线网络建设的朋友也适合正在做AC高可用方案选型或割接的运维同行不管你是用华为、华三、锐捷还是其他企业级AC原理都是相通的。先说结论双链路备份解决的是“路通不通”冷热备解决的是“脑子好不好使”。两者不是二选一而是要配合起来才能真正扛住故障。1. AC在无线网络中的角色以及为什么要做高可用1.1 AC到底在网里干什么AC全称Access Controller接入控制器。早期胖AP时代每个AP自己独立工作配置分散、管理混乱、漫游体验差。后来变成瘦AP架构AP只剩射频收发功能所有控制逻辑全部上收到AC统一处理。AC的核心职责有三个一是下发配置包括SSID、密码、认证方式、VLAN、限速策略这些二是处理CAPWAP隧道AP和AC之间通过CAPWAP协议建立控制隧道和数据隧道AP只管抓空中的无线信号抓完的数据包封装进隧道丢给AC转发三是集中认证和漫游管理用户在AP之间移动时由AC协调切换保证业务不中断。我把AC比作无线网络的交通指挥中心。AP是路口的摄像头和红绿灯真正的调度和决策全部在指挥中心。指挥中心一旦宕机路口摄像头虽然还能通电但没人指挥了所有车辆用户数据就全堵在路上。1.2 单点故障的真实代价很多项目在规划阶段都会问AC挂了会怎样答案分两种场景。AC直连式部署AC旁挂或者网关模式AP与AC之间的CAPWAP隧道断开后AP会进入独立工作模式也叫逃生模式。已经关联的用户可以继续上网但新用户无法关联上网漫游失效认证和策略控制全面失效。如果网络设有802.1X认证或Portal认证用户掉线后根本无法重新认证体验直接归零。AC串联式部署AC做网关转发数据AC挂了不只是无线控制失效整个网段的数据转发全部中断所有依赖这个AC转发的业务全部停摆包括有线业务。我之前接过一个工厂项目因为施工方偷懒AC没有做任何冗余保护结果某天下雨打雷AC的电源模块被浪涌打坏整片车间的PDA扫码枪全部失联物流系统瘫痪了两小时。最后算下来直接和间接损失够买好几台AC了。这就是单点故障的代价平时看着节省了成本故障时全部还回去。1.3 高可用的两个维度链路冗余与设备冗余AC高可用方案本质上围绕两个维度展开。第一个维度是链路冗余解决AC“上下班路上”的问题。AC要正常工作必须和AP保持隧道通信还要和上游核心交换机互通业务。如果AC和AP之间的链路断了或者AC到上行核心的链路断了AC本身再健康也没用。双链路备份就是在这个层面做文章保证AC和网络其他部分之间的通道有备份路径。第二个维度是设备冗余解决AC“脑子坏了”的问题。链路全通但AC设备本身宕机、被雷劈坏、系统崩溃业务照样完蛋。冷热备就是在这个层面做文章用一台备用的AC随时顶上接管所有AP和业务。这两个维度不是互相替代的关系。双链路备份扛不住AC宕机冷热备也解决不了上行链路被误删的问题——除非你同时做好了两者并且让它们能协同工作。下面分别展开讲。2. 双链路备份的设计与实现2.1 双链路备份的几种形态有些人一听“双链路”脑子里就是两根网线插在同一个AC上。其实AC场景里的双链路备份分三种层次很多人只做了最浅的那层。第一种是物理链路冗余。AC的上行口分别接到两台核心交换机或者一个口接核心、一个口接汇聚做成链路聚合Eth-Trunk/Bonding。这种方案解决的是单条物理线路或单个接口故障的问题。但要注意链路聚合本质上还是“一台AC 一台对端设备”如果对端交换机整机故障链路聚合毫无办法。更稳妥的做法是跨设备链路聚合让AC的上行链路接到两台核心设备上同时配合交换机侧的堆叠或虚拟化技术从物理上消灭单点。第二种是隧道链路冗余。AC和AP之间走CAPWAP隧道这条隧道承载在IP网络上。如果AC和AP之间的路由路径是冗余的——比如AP有两张上行网卡接到不同交换机或者网络中有多条可达路径——CAPWAP隧道本身就能在链路故障时重新建立路径。现在的企业级AC基本都支持AP通过配置多个AC地址或通过DNS解析AC地址在隧道断开后自动切换到备用AC。第三种是业务链路冗余。AC同时接入两个上游网络或者AC和AP之间有两条独立的三层路径业务流量在主路径故障时切换到备路径。这种方案依赖底层路由协议的收敛能力比如OSPF、静态路由联动BFD等。配置复杂度最高但可靠性也最强。我遇到不少项目客户拍着胸脯说做了双链路结果一看拓扑就是从AC两个口分别拉了根线到同一台交换机的同一块板卡上。这连单点故障都算不上消除只能说把端口故障的坑填了一半。真正的双链路从接口、板卡、设备、路径四个层面都不该有交集。2.2 链路聚合与上行冗余的取舍链路聚合Link Aggregation是AC双链路里最常用、也最容易做错的部分。链路聚合的作用有两个一是带宽叠加把两条物理链路合成一条逻辑链路总带宽翻倍二是负载均衡与故障转移其中一条物理链路断开时流量自动跑到另一条链路上感知不到断线。但在AC场景里链路聚合有个坑必须注意CAPWAP隧道是UDP协议AP和AC之间的数据隧道封装的是用户业务报文控制隧道封装的是管理报文。如果链路聚合的负载均衡算法配置不当可能导致某个隧道的所有报文全部命中同一条物理链路另一条链路线空闲这条链路带宽又不够用产生拥塞丢包。配置链路聚合负载均衡算法时建议基于源MAC地址和目的MAC地址做哈希或者基于源IP和目的IP做哈希保证不同AP的流量能相对均匀地分布到两条链路上。还有一个更隐蔽的问题是链路聚合的Peer Link必须使用专门的堆叠/集群链路不能把AC的普通业务口拿来当Peer Link用。有些没经验的工程师在配置跨设备链路聚合时把两台核心交换机的堆叠口当成普通业务口配置结果堆叠分裂后AC的两条上行链路同时失效还不如单条链路。链路聚合的配置本身不复杂但有几个检查项必须逐条过检查项正确做法常见错误两端速率/双工强制速率/双工一致一端自协商导致速率不匹配聚合模式静态或LACP统一两端模式不一致无法聚合所属VLAN两边Trunk配置一致一边Access一边Trunk负载均衡算法源目的MAC/IP哈希默认算法导致流量不均对端设备核心侧需堆叠/集群单台交换机插两根线2.3 隧道层面的链路切换机制CAPWAP隧道是AC和AP之间最核心的逻辑通道。隧道一切断AP立刻变成“无主孤狼”整片无线网络失去控制。隧道层面的双链路备份核心靠AP侧的多AC配置。AP启动时会按照优先级顺序去尝试联系AC先尝试配置的主AC失败后自动尝试备用AC。运行过程中主AC和AP之间的隧道异常断开AP也会主动去找备用AC重新建立隧道。这里有两个关键点必须理解。第一AP和AC之间有保活机制。AC和AP通过心跳报文维持隧道状态心跳超时才是断线判据。常见的心跳间隔是30秒超时次数3次共约90秒才能确认隧道中断。也就是说即使物理链路早就断了AP也可能要等一分半才能发现“和主AC失联”并开始切换。这个时间在无线漫游场景下用户可以接受但对实时性要求高的业务比如工厂AGV小车调度就太久了。可以通过调小心跳间隔和超时次数来加速切换比如把心跳间隔改成10秒、超时改为3次切换时间能压到30秒内。第二AP的逃生机制优先级。很多AC支持AP逃生配置规定隧道断开后AP是否继续转发业务。这个要考虑清楚如果允许逃生那么AC故障期间无线网络还有基础覆盖但新用户无法认证、老用户的策略会失效如果不允许逃生AC一挂AP直接停止服务无线业务全断好处是策略控制绝对严格坏处是故障影响范围巨大。金融、医疗场景建议禁止逃生宁可停服务也不能让用户在没有认证的环境里接入内网办公、工厂场景建议允许逃生保留基本业务。2.4 双链路下的负载分担策略双链路备份不等于一条线干活一条线睡觉。真正的双链路应该让两条链路在平时都承担流量故障时才能快速切换同时带宽利用率更高。在AC场景下负载分担有几个层次。链路聚合层面通过哈希算法把不同AP或不同用户流量分布到两条物理链路上隧道层面可以配置AC集群让不同AP接入不同的AC成员设备实现AC间的负载分担路由层面通过等价路由实现流向AP的不同子网流量走不同路径。但负载分担要注意会话一致性问题。CAPWAP隧道要求同一个AP的所有流量必须走同一条物理路径如果负载均衡算法把同一个AP的控制报文和数据报文哈希到了不同链路上隧道直接建立不起来。所以AC上配置链路聚合时负载均衡的哈希粒度要精确到“会话”或“AP维度”而不是简单按包轮询。我习惯的做法是如果AC只有两个上行口做聚合哈希算法选基于源MAC 目的MAC如果AC有多个上行口可以考虑基于源IP 目的IP因为IP地址能更均匀地分散在不同链路上。配完之后用流量统计命令观察两条链路的负载偏差超过30%就要调整算法。3. 冷热备设备级冗余的核心知识点3.1 热备的真正含义状态同步很多人以为热备就是“两台AC开着一台挂了另一台顶上”。这个理解太粗糙。热备的价值核心不在于“有没有备用机”而在于“备用机是否记得主机的状态”。AC热备主备模式通常需要承载三个同步内容。第一是配置同步。主AC上做了任何配置变更比如新增SSID、改认证服务器、加限速策略都要实时同步到备AC。不然主AC故障后备AC接管的是一个旧的配置很可能出现新用户无法认证、旧策略缺失的问题。第二是状态同步。状态包括已关联的AP列表、AP的隧道信息、在线用户的会话状态、用户的认证状态等。无线网络和有线网络最大的不同是用户随时在漫游AP的动态关联状态随时在变化。如果备AC不知道当前有哪些AP在线、哪些用户已认证接管后所有用户都要重新认证所有AP都要重新建立隧道等同于一次全网重启。第三是ARP/路由/表项同步。AC如果是网关模式还需要同步ARP表、路由表等三层转发表项否则备AC接管后用户的网关地址是同一个虚拟IP但ARP表是空的数据转发会出问题。热备的心跳机制是核心命脉。主备AC通过心跳线实时探测对方存活状态一般用专用的心跳口直连也可以通过业务网络走独立VLAN。心跳超时阈值要谨慎配置太短网络抖动可能误判对方故障导致双主太长真故障时切换太慢业务中断时间过长。常见的推荐值是1秒心跳间隔、3次超时约3秒判定故障。3.2 冷备最朴素也最容易被低估的方案冷备简单说就是备用AC平时关机或者只通电不承载任何业务故障时人工上电、导入配置、接管AP。冷备不追求“秒级切换”它的目标是RTO恢复时间目标在分钟级甚至小时级但投入成本最低。冷备的部署方式主要有两种。第一种是纯离线冷备准备一台同型号同版本同硬件规格的AC定期比如每周把主AC的配置手工备份出来存到本地或网管服务器上。故障时人工换上导入配置修改IP地址然后把AP的AC地址重新指过去。RTO取决于运维人员到场和操作的时间快则半小时慢则按天算。第二种是温备备用AC保持通电配置定期同步但不接业务流量AP不会主动连它。故障时人工介入备机启动服务。温备比离线冷备好一些因为硬件状态是活的配置也是最新的但切换还是要人盯着。我见过一些企业舍不得买两台同规格AC做热备但会用一台低配或者二手的AC做冷备。这种思路不能说错但有个致命问题冷备AC的型号、版本、License如果和主AC不一致主AC故障后你根本没法顺利接管。比如主AC支持256个AP冷备AC License只够128个故障发生时一半AP联不上等于没备。所以冷备AC的硬件规格、软件版本、License容量必须和主AC保持一致。冷备还有一个被忽视的点配置备份的周期。如果你每周只备份一次主AC故障前几天的配置变更全部丢失接管后要重新补齐。最好能自动化备份比如在AC上配置定期备份到TFTP/FTP服务器或者通过网管平台做配置采集至少保证每天一份关键时刻才有的用。3.3 冷备与热备的选型对比经常有人问我到底选冷备还是热备我的回答是先算账再选型。具体对比可以看这张表对比项热备主备模式冷备离线/温备RTO恢复时间秒级到分钟级自动切换分钟级到小时级人工介入切换方式自动探测故障自动切换人工上电、导配置、指AP状态同步配置、会话、AP状态实时同步仅定期备份配置成本两台同规格设备 心跳链路一台同规格设备 备份服务器运维要求需要维护心跳、同步状态、版本一致性需要定期备份和版本核对适用场景核心生产网络、实时业务、高密办公非核心分支、预算有限、可接受短暂中断预算充足、业务影响大闭眼选热备预算紧张、业务可以接受半小时以上的中断冷备是务实的选择。但不论冷备还是热备都建议对AC做版本和License的严格管理这是成败的关键。还有一点必须强调热备不是万能药。我做过的项目里热备AC在切换后经常出现“备机接管了但业务还是不通”的情况——原因是备机的上行链路不在同一台交换机上或者备机的网关VLAN没放通或者License超规格导致部分AP拒绝接入。热备只是“设备冗余”链路、网络、认证等外部依赖一样要做全面检查。3.4 AP逃生与业务降级AC故障后AP进入逃生模式这时要提前设计好“业务降级”的策略而不是让所有业务还在同一水平上硬扛。我一般建议客户做好三个策略。第一逃生模式下开放的SSID范围。主AC上可以区分办公SSID、访客SSID、IoT设备SSID。AC故障时建议只保留核心办公SSID和有线回传的SSID能被逃生访问其他临时访客网络自动关闭。这样可以减少逃生模式下AC故障引起的安全风险。第二逃生模式下用户认证策略。默认逃生模式下不认证或者采用简易认证。如果是办公内网建议逃生模式下禁止新用户接入只放行已认证用户。具体做法是配置AP的逃生策略指定逃生时长和最大逃生用户数。第三逃生后的恢复机制。AC恢复正常后AP需要重新和AC建立隧道、同步配置、更新策略。这个恢复过程会出现一波“隧道重建风暴”所有AP同时向AC发起CAPWAP连接AC的CPU和连接数会被瞬间打满。解决办法是提前配置AP的连接限速或者让AC支持隧道建立的连接调度避免大量AP同时接入导致AC起不来。4. 配置实施与验证要点4.1 热备部署的关键参数与配置流程热备部署不是把两台AC开机连根心跳线就能完成的参数错一个切换就是一场事故。我梳理一下部署的核心步骤和参数。第一步规划主备角色。建议通过AC的优先级参数指定优先级高的为主AC低的为备AC。注意主备角色在心跳中断时可能会出现“双主”状态——两台AC都认为自己是主同时争抢管理AP和虚拟IP。解决双主的机制是配置“故障检测 抢占延迟 设备间协调”心跳恢复后优先级低的自动让位。第二步规划虚拟IP。热备AC对外通常提供一个虚拟IP地址AP和用户都指向这个虚拟IP。虚拟IP和心跳地址必须规划单独的管理VLAN避免业务流量冲击心跳链路。第三步配置同步组。主备AC需要加入同一个热备组并指定同步哪些内容——包括配置、AP状态、用户会话等。有些平台支持“配置集中管理”即只在主AC上配置备AC自动同步全部配置推荐开启。第四步检查License和版本。主备AC必须使用相同版本软件License容量必须足够覆盖全部AP数量。最好让主备AC的License容量大于实际AP数预留20%冗余防止AP增加后备机License不够。配置流程的示意如下以常见企业级AC配置风格为例具体命令以厂商为准# 主AC配置示例 wlan ac protect enable ac protect keepalive interval 1 ac protect keepalive retry 3 ac protect role master ac protect virtual-ip 192.168.100.254 ac protect bind-vap all ac protect track interface GigabitEthernet0/0/1 ac protect track ip 10.0.10.2# 备AC配置示例 wlan ac protect enable ac protect keepalive interval 1 ac protect keepalive retry 3 ac protect role standby ac protect virtual-ip 192.168.100.254 ac protect bind-vap all ac protect track interface GigabitEthernet0/0/1 ac protect track ip 10.0.10.3注意上面只是示意真实设备命令差异很大但参数逻辑是通用的——心跳间隔控制探测灵敏度虚拟IP控制对外服务地址track对象控制“双主抑制”的来源。4.2 冷备实施步骤与检查项冷备虽然简单但实施时最容易遗漏细节。我总结了一套冷备落地的检查流程可以直接抄作业。第一准备一台与主AC同型号、同版本、同License容量的备用AC。如果买不到同型号至少要保证硬件规格不低于主AC软件版本经过兼容性验证。第二定期备份主AC配置。推荐配置自动化备份脚本每天自动将主AC的配置文件备份到FTP服务器并保留最近7份备份文件。检查配置备份时重点看几项所有SSID配置是否完整、认证服务器的IP和密钥是否一致、AC自身的IP和路由是否匹配、License信息是否写在配置里。第三提前把备用AC的“静态参数”配置好。IP地址、掩码、网关、管理VLAN这些不随业务变化的参数可以事先在冷备AC上配好。这样故障时只要导入动态配置即可不用现场敲大量命令。第四冷备切换演练。每季度至少做一次冷备切换演练模拟主AC故障按照应急预案把冷备AC上电、导入备份配置、把AP的AC地址切换到备机、验证业务恢复。演练记录要保存每次演练后更新应急预案。4.3 切换演练与验证方法冷备、热备部署完不演练等同于没部署。我见过太多项目热备部署了三年从没做过切换测试结果真故障时备机接管后一堆问题。切换演练应该纳入日常运维计划每半年至少一次。演练要覆盖以下场景主AC宕机、备AC宕机、心跳中断、上行链路中断、AP批量掉线、部分AP重新上线。每个场景都记录切换时间和业务恢复时间。验证方法有几个关键观察点虚拟IP是否能够漂移主备角色切换是否自动完成AP是否全部上报到备ACAP列表是否完整在线用户的会话是否保持已经认证的用户是否不用重新认证业务转发是否正常用终端持续ping网关和测试内网域名解析。切换演练中我常用的一个快速检查命令是查看AC上的AP在线数量和隧道状态。如果AP在线数量在切换完成后少于主AC故障前的数量说明有AP没成功切换到备机要马上排查是AC地址配置问题还是License不足问题。5. 常见问题与排查经验5.1 备AC不接管备AC不接管是热备部署中最常遇到的问题。原因通常是心跳配置错误或角色配置错误。排查思路先ping主备AC之间的心跳地址确认心跳链路通不通再检查主备AC上的热备状态确认主备角色是否正常最后检查虚拟IP是否在主AC上绑定。如果心跳链路物理通但状态显示异常大概率是心跳报文被防火墙或ACL拦截了或者心跳VLAN的配置不一致。我之前处理过一个案例主备AC心跳直连但中间隔了一台接入交换机交换机上配置了端口隔离把心跳报文全挡了。主备AC之间状态一直显示Down备机永远不接管。最后把心跳口划到同一个未隔离VLAN状态立刻恢复正常。5.2 双主与心跳线故障心跳线故障是热备最怕的问题主备AC都认为对方挂了自己是主开始同时争抢虚拟IP、管理AP。轻则AP频繁切换隧道重则两台AC同时管理同一批AP导致隧道重建风暴。解决双主问题的核心机制是“Track链路检测 备用抑制”。主备AC除了检测对方心跳外还要检测自己到上行核心的链路状态。如果备AC检测不到主AC心跳但自己的上行链路也是Down那就说明网络已经挂了备机不应该抢占主角色而应该保持Standby状态。配置上建议把AC的上行物理接口、核心交换机的网关地址都加入Track检测。一旦心跳丢失且上行链路DownAC禁止激活虚拟IP宁可让整个网络保持“无主”状态等人工介入也不能让双主把网络搞得更乱。5.3 隧道重建风暴切换完成后所有AP几乎同时向备AC发起隧道连接备AC瞬间收到大量CAPWAP请求CPU使用率飙升可能导致备AC处理失败、部分AP隧道建立失败。预防办法有几种一是提前配置AP的隧道重连策略让AP在AC切换后延迟几秒到几十秒再重新发起连接分散建连压力二是备AC上配置连接数限制防止并发连接数超过设备处理上限三是备AC的硬件性能在选型时留足余量CPU和内存都要比主AC的实际负载高出至少50%。有一次演练中150台AP同时向备AC发起隧道请求备ACCPU直接跑到90%部分较老的AP因为隧道建立超时反复重试形成了恶性循环。最后在AP侧配置了随机延时重连问题才解决。5.4 配置漂移与版本不一致主AC变更配置后如果同步机制异常备AC的配置和主AC不一致。等到真故障切换时备AC带着一份过期的配置上场用户认证、VLAN、策略全都对不上恢复时间被无限拉长。排查配置漂移建议定期在主备AC上导出Running Config做diff对比尤其关注SSID、认证模板、AP组、Radius服务器这几类配置的差异。配置同步异常的常见原因有三个一是热备同步组里的配置项没勾选完整只同步了部分内容二是主AC上的配置是在备AC离线状态下改的离线期间产生的配置变更没有自动补同步三是主备AC的版本不一致导致某些配置项无法同步。版本不一致的问题最隐蔽。有些运维图省事给备AC升了个小版本觉得“差不多能跑”结果主AC的某些配置项在备AC上被自动忽略同步成功了但功能不生效。AC热备必须做到主备版本完全一致别抱侥幸心理。5.5 冷备切换现场实录最后分享一次真实的冷备切换现场供参考。某分支工厂的AC因为雷击损坏现场只有一台离线冷备AC。当时的情况主AC配置只备份到了前一天晚上当天上午新增了一个访客SSID和两条限速策略这部分配置会丢失。切换过程先给冷备AC上电等待系统启动完成导出最近的备份配置检查备份时间和配置完整性把冷备AC的IP改成主AC的IP注意要同步修改管理地址、网关、路由导入配置后重启或使配置生效把AP的AC地址指向新AC等待AP逐台上线最后验证用户认证和访客SSID是否恢复。整个过程用时约40分钟业务中断可以接受。后续复盘时补了一个自动化配置备份任务把备份频率从每周一次改成每天两次。这个案例说明冷备不是万能方案但做好了“定期备份 版本一致性 切换预案”紧急情况下完全能撑住场面。在AC高可用这件事上我的经验是不要迷信任何单一方案也不要因为“预算不够”就完全不设防。双链路备份和冷热备是两套独立又互补的机制双链路保证AC和网络的“路”永远有退路冷热备保证AC的“脑子”挂了还有人顶上。真正可靠的方案是冗余设计、配置规范、版本管理和定期演练四件事一起做少哪条都可能在关键时刻掉链子。