做无线网络项目这些年ACAccess Controller接入控制器/无线控制器双链路备份与冷热备是绕不开的话题。很多人觉得链路备份就是多插一根网线冷热备就是多放一台设备真到故障切换那一刻AP批量掉线、终端认证失败、配置对不上场面那叫一个热闹。这篇把我做过的园区网、酒店、分支办公场景里围绕AC双链路备份和冷热备的踩坑经历、设计思路、核心知识点系统整理一遍给正在做方案规划或者要动手实施的同行做个参考。这篇主要覆盖双链路备份到底在备份什么、冷备和热备的本质区别、主备切换的核心机制、实操中的配置要点以及故障排查的真实案例。1. 项目概述与核心需求解析1.1 先说清楚这里讨论的AC是什么很多非网络专业的同事看到AC第一反应是空调遥控器或者电源适配器。但在无线网络里AC指的是Access Controller通常翻译为无线控制器或接入控制器。它的核心职责是集中管理网络里的AP无线接入点下发配置、控制漫游、管理接入认证、收集终端状态。简单说AP负责把无线信号发出去AC负责这批AP的大脑统一控制。因为AC管着成百上千个AP它也成了无线网络里典型的单点瓶颈。AC一宕机下面所有AP和终端都会受影响轻则新增终端无法接入、漫游失效重则AP全部离线整片办公区Wi-Fi瘫痪。所以做高可用方案时AC是必须重点保护的设备这就引出了两个方向一个是链路层面的冗余也就是双链路备份另一个是设备层面的冗余也就是冷备和热备。1.2 为什么非要做双链路备份和冷热备拆开看需求就很清楚双链路备份解决的是线断了怎么办冷热备解决的是设备坏了怎么办。这两个问题经常被混在一起实际上它们处在不同层面互相配合但不互相替代。我见过一个典型项目客户只给AC配了双网口以为万事大吉。后来交换机上联口坏了AC到核心的链路断开AP全部失联客户跑过来问我不是已经做了冗余吗——这就是只做了链路聚合没做设备冗余也没考虑到链路上游故障。反过来有人只做双机热备但两台AC接到同一台汇聚交换机时汇聚交换机一宕机两台AC一起失联热备形同虚设。所以正确的思路是AC双链路备份解决链路可用性冷热备解决设备可用性两者叠加才能端到端高可用。这篇博文后面所有内容都基于链路冗余设备冗余这个组合视角展开。2. 双链路备份机制拆解2.1 双链路备份的两种形态聚合与双上行双链路备份最常见的落地方式有两种看着像但原理不同。第一种是链路聚合也就是常说的Eth-Trunk、Port-Channel或Link Aggregation。把AC上两个甚至更多物理口绑成一个逻辑口和交换机对接。好处是带宽叠加一条物理链路断开后流量自动在剩余链路间重新哈希分配收敛速度很快一般是毫秒级到秒级。但它有个前提两条物理链路必须连到同一个交换机或者同一个堆叠系统否则跨设备的聚合就复杂了。它解决的是同一堆设备里单根线故障的问题。第二种是双上行主备链路AC分别用两条物理链路连接到两台不同的交换机。平时只有主链路转发流量备链路处于待命状态。主链路故障时通过VRRP、路由优先级或者BFD联动把流量切到备链路。这种方式的优势是抗单设备故障比如主交换机宕机备链路还能把流量带出去缺点是带宽不能叠加主链路闲着时备链路不跑业务资源效率比聚合低。实际操作中很多人会把这两种方式搭配用AC每条上行链路本身做成聚合口再分别上联到两台交换机这样任意一根线、任意一台交换机故障都能扛住。我给一个中型园区做方案时就是这么设计的AC用四个千兆电口每两个绑一个Eth-Trunk分别接到两台核心交换机效果很稳。2.2 链路检测与切换的核心逻辑链路备份光有冗余不叫高可用关键在检测和切换这两个动作。物理链路断开一般能靠端口状态检测感知但更麻烦的是链路通但业务不通的场景比如交换机转发异常、中间传输设备丢包严重。这时候物理口还是up的普通链路聚合检测根本没反应。所以要引入额外的检测机制。业界常用的是BFD双向转发检测报文按固定间隔从AC发往对端连续丢包几次就判定链路故障然后把路由/接口状态联动切换。也可以把BFD和VRRP、静态路由联动实现快速倒换。另一种是NQA或IP-SLA做端到端探测比如AC定时ping一个核心业务的IP连续失败就触发切换。BFD适合毫秒级快速检测NQA适合业务可达性探测两者不冲突关键场景可以同时上。我还遇到过一些项目客户要求备用链路一定要热备待命但实际做的是静态路由两个出接口主路由没带track。结果主链路故障后流量在备用接口上始终出不去因为主路由没有自动失效备用路由根本没机会启用。后来加了BFD与静态路由联动问题才解决。这就是检测和切换脱节的典型问题。2.3 设计中的关键参数与计算做双链路备份方案时几个参数要认真算带宽需求一个AP按20-100Mbps预留视并发终端和业务类型办公场景一般按每AP 30-50Mbps估。AC上行总带宽取所有AP同时在线时的峰值流量不建议按平均值算不然高峰期会丢包。链路数量需要带宽冗余时尽量做至少两条链路比如总需求800M用两条千兆聚合单条故障后还有1000M够用如果需求1200M两条千兆就不够需要升级到万兆口。BFD参数一般检测间隔建议100ms-300ms倍数2-3次也就是故障感知在0.3-1秒左右。有的设备支持30ms*3的高强度检测但消耗CPU资源不是万不得已不建议这么激进。切换时间预期链路聚合故障切换一般1秒静态路由BFD联动一般1-3秒VRRP切换3秒以内算常见。把这些预期写进SLA文档跟客户对齐免得事后扯皮。这里给个具体例子某酒店280个AP峰值在线并发1800终端按每终端2Mbps估算上行流量约3.6Gbps。AC用双万兆上行分别做Eth-Trunk各两个万兆口接两台核心交换机。单条万兆链路故障剩余带宽仍能满足峰值需求这就是把参数算透的意义。3. 冷热备机制深度对比3.1 冷备简单直接的备胎冷备的冷字很形象——备用AC平时不上电不接业务甚至放在机柜角落落灰。主AC故障了人工把业务切到备机备机加载配置后启动AP重新注册可能需要几分钟到几十分钟。切换期间网络基本是中断的。冷备的优势是成本低、结构简单、不引入双机同步的复杂度。对很多小型项目来说几十个AP业务容忍5-15分钟中断冷备完全够用。我见过一个连锁门店场景总公司采购了两台AC平时只运行一台另一台定期做配置备份故障时远程指导门店运维换线换机虽然折腾但总比没有备用机强。冷备的坑主要是配置漂移。主AC上线后不断被调优、加新AP、改认证策略而备AC还是出厂状态。真到切换那天备机上线后发现配置和当前网络差了一大截光恢复配置就得老半天。所以冷备的重点不在设备本身而在配置管理的纪律每次改完主AC的配置必须同步导出并更新备AC的配置基线。3.2 热备无缝切换的代价与回报热备是主备两台AC同时运行备机不仅在还实时同步主机的状态。同步的内容包括三类一是配置数据比如SSID、认证策略、无线参数保证备机能接管相同业务二是动态状态比如AP的注册信息、终端的关联表、漫游记录、Portal在线用户等这是热备和冷备最本质的差别三是链路状态主备之间的心跳和业务通道状态。主AC故障时备AC通过心跳超时感知主设备异常自动接管业务。接管方式可能是VRRP地址漂移备机拉起虚拟IP也可能是AP侧感知主AC失联后自动向备AC重新注册。理想情况下已关联的终端可能觉察不到变化AP重新注册过程在几秒内完成。热备的代价也很明显成本翻倍、配置复杂度高、还存在脑裂风险。脑裂是指主备之间心跳链路断了两台设备都认为对方故障都变成主设备争抢IP、争抢AP控制权导致网络混乱。这个问题在后面排查章节专门讲。热备适合医院、工厂、金融网点这类业务中断影响巨大的场景但选型时要用值不值来衡量而不是有没有。3.3 冷热备选型决策表为了帮大家做方案时少纠结我给一个选型表按项目规模、业务容忍度、预算三个维度来分维度冷备热备切换方式人工手动切换自动切换RTO恢复时间分钟级到十几分钟秒级通常3-10秒RPO数据丢失量配置有差异动态数据全丢动态表项可同步基本无丢失硬件成本一台备机无需高性能两台同配置可能还要加心跳口运维复杂度低但配置管理要求高高需定期演练和版本对齐典型场景连锁门店、小分支、SOHO医院、园区、工厂、大型商场AP规模建议几十到一两百两百以上或跨多区域部署这里补充一个实操建议如果AP数量超过150或者客户明确说断网五分钟就要投诉就不要再纠结冷备了直接上热备。相反项目预算有限且业务时段固定冷备配合完善的配置备份脚本是可以接受的方案。4. 实操落地从规划到验证4.1 环境规划与网络拓扑设计实际操作中AC的双链路和双机热备通常放在一起规划。我推荐的最稳拓扑是旁挂双机上行双链路两台AC分别接到两台核心交换机AC与核心之间用两个物理口绑定为一个聚合口作为双链路备份。两台AC之间专门接一根独立的直连线或走管理网作为心跳口用于热备状态同步。业务VLAN、AP管理VLAN、AC管理地址提前规划虚拟IP如果有VRRP放到业务网段。AP通过DHCP Option 43或DNS方式发现AC这里建议配置两个AC地址让AP知晓有多个AC可选。一个常见问题是AC旁挂时上联口怎么接如果只有一台核心交换机但想要热备两台AC都接到同一台核心那核心就成了新的单点所以有条件最好把核心做成堆叠或双机否则后端冗余做了也白做。这个我在项目评审里反复提过。4.2 配置实施要点含命令示意配置步骤按顺序做先链路再热备再验证。链路聚合属于二层基础配置这里以某主流厂商命令行风格为例演示核心思路不同设备命令略有差异但逻辑一致# 在AC上创建Eth-Trunk绑定两个物理口 interface Eth-Trunk1 port link-type trunk port trunk allow-pass vlan 100 200 # interface GigabitEthernet0/0/1 eth-trunk 1 # interface GigabitEthernet0/0/2 eth-trunk 1接着配置热备功能。热备通常分成两步建立主备关系、开启业务模块同步。# 配置AC间心跳与主备角色 hot-backup enable service-interface Eth-Trunk2 peer-ip 10.0.1.2 local-ip 10.0.1.1 priority 150 # 主设备优先级高 preempt disable # 关闭抢占避免回切引发二次震荡 # # 开启关键业务模块的实时同步 hot-backup module capwap hot-backup module user-table hot-backup module portal这里有几个细节很多人第一次踩坑。第一心跳口不要和业务口共用物理链路否则业务拥塞会把心跳报文也堵住导致误判主备故障。第二priority设置要拉开差距比如主150、备120防止网络抖动时备机误抢主。第三preempt建议默认关闭因为主设备恢复后如果自动抢回会引发毫秒级或秒级业务抖动业务窗口敏感时很尴尬如果不关抢占下文第5.4里还有配置同步的风险。配置完热备后再检查CAPWAP隧道和AP接入。AC双机在部署时需要注意STA终端关联表同步不然用户本来连着上网AC切换后终端列表全空会导致用户无法漫游甚至重新认证。4.3 故障演练与切换验证配置不等于完工热备必须演练。我第一次给某工厂做双机热备时配完自我感觉良好结果演练拔主AC电源时备AC没有按预期接管AP离线了一分多钟才回来。原因后面排查发现是心跳用了管理VRF管理链路切换时主备心跳互相不可达触发了一次误切换。从那以后我养成了一个习惯不管现场多赶必须做完整的故障演练并记录。演练项目建议按下面这个表格来做每条都记录预期值/实测值/是否通过故障模拟操作预期影响实测结果拔掉主AC的一根上联网线AP和终端无感知流量秒级重分布切换时间0.5秒无终端掉线断开主AC与核心的全部上联链路备AC接管主角色AP重新注册终端短暂感知但不断网4-8秒恢复视频会议卡顿无掉线直接关闭主AC电源同上还伴随终端重新认证情况恢复时间6秒部分终端重认证拔掉AC间心跳线不应出现双主备机不能抢占业务备机保持待命但日志报critical告警恢复主AC供电主备关系恢复业务不中断不应频繁切换主设备回归standby业务无感知每次演练后把两根链路摘除再插回还要测试链路恢复后的流量回切是否正常。注意双链路和热备的回切机制可能互相影响如果主链路恢复后自动回切加上热备的抢占可能瞬间出现路由抖动。所以我在很多项目里把链路回切设置为手动或延时尽量降低抖动窗口。5. 常见问题与排查实录5.1 主备切换失败的典型原因切换失败是热备最常见的坑排查顺序很重要。多数情况按以下优先级查心跳链路问题心跳口物理不通、对端地址写错、心跳报文旁路进业务口。表现是主备状态互相不可见日志刷peer unreachable。解决办法是单独拉一根直连心跳线并在AC日志里关注心跳丢包率。优先级配置不当主备priority差距太小网络抖动导致备机抢主来回震荡。建议差距至少30同时开启/关闭抢占要明确预期。检测机制和热备联动缺失只配了热备没配BFD或者track导致主AC已经和网络脱管但心跳还活着备AC没有触发切换。需要把上行健康状态的track结果和热备角色绑定。如果你在现场遇到主AC电源都关了备AC还不接管这类问题先查心跳是否还通再查备AC是否处于standby角色最后看接口状态和ARP表项。我遇到过最离奇的是两台AC心跳口都up但ARP是静态配置错误导致备机一直收不到对端的通告报文始终认为主AC活着。5.2 会话丢失与终端掉线问题热备不等于零感知。很多热备方案真正同步的是AP注册表但终端的Portal认证状态、DHCP租约不一定同步。结果AC切换后AP又上线了但用户需要重新认证视频通话中断。这在一些认证场景尤其明显。解决思路有三个方向一是确认热备配置里是否开启了user-table同步很多设备默认不同步终端表项需要手动打开二是把认证服务器的会话超时时间调长让备AC接管后能沿用原会话三是给无线SSID开启本地转发让终端的数据面流量在AP侧直接转发AC故障对用户数据的影响会小很多。但本地转发也有代价比如漫游和集中管控会弱化需要权衡。5.3 双链路负载不均问题链路聚合最常见的表现是两条链路一条跑满一条闲着。这通常不是链路故障而是哈希算法的问题。二层聚合按MAC、三层聚合按IP如果源/目的地址变化少哈希分不均匀。排查时可以看聚合口各成员的字节计数对比差距。如果长期不均衡尝试调整哈希因子比如从源IP目的IP换成源MAC目的MAC或者开启增强型的对称哈希。这里提醒一句不要看到主备链路上备链路没有流量就认为是故障如果设计就是主备非负载分担模式链路idle是正常的。设计文档里写清楚是聚合还是主备排查时心里才有数。5.4 配置同步与版本一致性热备系统最大的隐患往往不是切换失败而是主备配置漂移。比如主AC加了一个SSID备AC没有同步故障切换后这个SSID直接消失终端全失联。冷备场景尤其容易发生热备场景也会因为某些模块不在同步范围内导致差异。我的排查和预防经验是建立配置基线每次割接或变更前导出主备AC配置对比有差异先对齐再操作。固件版本严格一致热备对双机软件版本要求很严格不相同可能导致同步功能异常或切换时报错。升级时一定要先备后主或者按厂商指引走滚动升级。使用网管或脚本做定期备份很多项目我都是加个夜间的自动备份任务把两台AC的配置文件定时传到日志服务器出问题可以快速比较。恢复操作留痕如果备机临时接管过业务后续主AC恢复时配置可能已经被备机改过同步方向要弄清楚不要用旧配置把新配置覆盖掉。给一张速查表方便现场快速定位现象可能原因优先排查点两台AC同时显示Master心跳中断/心跳接口故障心跳线物理状态、心跳报文统计AP不注册到备ACAP配置的AC地址列表不完整DHCP Option 43或DNS解析结果切换后终端掉线重认证终端表项未同步user-table/portal会话同步开关聚合链路流量不均衡哈希因子不匹配各成员口计数器、哈希因子主AC恢复后反复切换抢占开启且优先级差小preempt配置、priority差配置不同步备份配置未刷新配置基线对比、同步状态6. 后记我在实际操作中的几点体会做了这么多AC双链路和冷热备项目最后分享几个可能教科书里不写、但现场很管用的体会。第一别把冷热备当作一个配置项看待它更接近一套运维流程。冷备不是把备机放机柜里就完了配置基线、切换预案、联系人名单一样都不能缺。我见过最省心的冷备项目靠的是一份写得很烂但每次变更都更新的Word文档和一个每季度帮你拔插一次备机的网工。第二双机热备上线前一定把切换时要不要抢占这个问题和业务方确认死。工厂产线半夜不希望AC自己回切办公楼可能无所谓。很多事故不是设备不行而是回切策略和业务窗口不匹配。第三混合组网里双链路备份和冷热备永远要放在同一个拓扑里看。AC的双上联必须解决上游交换机单点热备的心跳必须独立于业务链路AP发现AC必须把两个地址都写进去。这个思路几年前我踩坑后总结为三个必须之后设计高可用方案一直沿用项目基本没有再被这种基础问题绊倒过。希望这篇总结能帮大家少走点弯路。如果手头正在做AC高可用方案建议先把上面的选型表和排查速查表存下来到现场大概率用得上。 
长河君 · 2026/10/6 16:48:24 · 阅读 1.2k 无线AC双链路备份与冷热备：从原理到实战的高可用方案
做无线网络项目这些年ACAccess Controller接入控制器/无线控制器双链路备份与冷热备是绕不开的话题。很多人觉得链路备份就是多插一根网线冷热备就是多放一台设备真到故障切换那一刻AP批量掉线、终端认证失败、配置对不上场面那叫一个热闹。这篇把我做过的园区网、酒店、分支办公场景里围绕AC双链路备份和冷热备的踩坑经历、设计思路、核心知识点系统整理一遍给正在做方案规划或者要动手实施的同行做个参考。这篇主要覆盖双链路备份到底在备份什么、冷备和热备的本质区别、主备切换的核心机制、实操中的配置要点以及故障排查的真实案例。1. 项目概述与核心需求解析1.1 先说清楚这里讨论的AC是什么很多非网络专业的同事看到AC第一反应是空调遥控器或者电源适配器。但在无线网络里AC指的是Access Controller通常翻译为无线控制器或接入控制器。它的核心职责是集中管理网络里的AP无线接入点下发配置、控制漫游、管理接入认证、收集终端状态。简单说AP负责把无线信号发出去AC负责这批AP的大脑统一控制。因为AC管着成百上千个AP它也成了无线网络里典型的单点瓶颈。AC一宕机下面所有AP和终端都会受影响轻则新增终端无法接入、漫游失效重则AP全部离线整片办公区Wi-Fi瘫痪。所以做高可用方案时AC是必须重点保护的设备这就引出了两个方向一个是链路层面的冗余也就是双链路备份另一个是设备层面的冗余也就是冷备和热备。1.2 为什么非要做双链路备份和冷热备拆开看需求就很清楚双链路备份解决的是线断了怎么办冷热备解决的是设备坏了怎么办。这两个问题经常被混在一起实际上它们处在不同层面互相配合但不互相替代。我见过一个典型项目客户只给AC配了双网口以为万事大吉。后来交换机上联口坏了AC到核心的链路断开AP全部失联客户跑过来问我不是已经做了冗余吗——这就是只做了链路聚合没做设备冗余也没考虑到链路上游故障。反过来有人只做双机热备但两台AC接到同一台汇聚交换机时汇聚交换机一宕机两台AC一起失联热备形同虚设。所以正确的思路是AC双链路备份解决链路可用性冷热备解决设备可用性两者叠加才能端到端高可用。这篇博文后面所有内容都基于链路冗余设备冗余这个组合视角展开。2. 双链路备份机制拆解2.1 双链路备份的两种形态聚合与双上行双链路备份最常见的落地方式有两种看着像但原理不同。第一种是链路聚合也就是常说的Eth-Trunk、Port-Channel或Link Aggregation。把AC上两个甚至更多物理口绑成一个逻辑口和交换机对接。好处是带宽叠加一条物理链路断开后流量自动在剩余链路间重新哈希分配收敛速度很快一般是毫秒级到秒级。但它有个前提两条物理链路必须连到同一个交换机或者同一个堆叠系统否则跨设备的聚合就复杂了。它解决的是同一堆设备里单根线故障的问题。第二种是双上行主备链路AC分别用两条物理链路连接到两台不同的交换机。平时只有主链路转发流量备链路处于待命状态。主链路故障时通过VRRP、路由优先级或者BFD联动把流量切到备链路。这种方式的优势是抗单设备故障比如主交换机宕机备链路还能把流量带出去缺点是带宽不能叠加主链路闲着时备链路不跑业务资源效率比聚合低。实际操作中很多人会把这两种方式搭配用AC每条上行链路本身做成聚合口再分别上联到两台交换机这样任意一根线、任意一台交换机故障都能扛住。我给一个中型园区做方案时就是这么设计的AC用四个千兆电口每两个绑一个Eth-Trunk分别接到两台核心交换机效果很稳。2.2 链路检测与切换的核心逻辑链路备份光有冗余不叫高可用关键在检测和切换这两个动作。物理链路断开一般能靠端口状态检测感知但更麻烦的是链路通但业务不通的场景比如交换机转发异常、中间传输设备丢包严重。这时候物理口还是up的普通链路聚合检测根本没反应。所以要引入额外的检测机制。业界常用的是BFD双向转发检测报文按固定间隔从AC发往对端连续丢包几次就判定链路故障然后把路由/接口状态联动切换。也可以把BFD和VRRP、静态路由联动实现快速倒换。另一种是NQA或IP-SLA做端到端探测比如AC定时ping一个核心业务的IP连续失败就触发切换。BFD适合毫秒级快速检测NQA适合业务可达性探测两者不冲突关键场景可以同时上。我还遇到过一些项目客户要求备用链路一定要热备待命但实际做的是静态路由两个出接口主路由没带track。结果主链路故障后流量在备用接口上始终出不去因为主路由没有自动失效备用路由根本没机会启用。后来加了BFD与静态路由联动问题才解决。这就是检测和切换脱节的典型问题。2.3 设计中的关键参数与计算做双链路备份方案时几个参数要认真算带宽需求一个AP按20-100Mbps预留视并发终端和业务类型办公场景一般按每AP 30-50Mbps估。AC上行总带宽取所有AP同时在线时的峰值流量不建议按平均值算不然高峰期会丢包。链路数量需要带宽冗余时尽量做至少两条链路比如总需求800M用两条千兆聚合单条故障后还有1000M够用如果需求1200M两条千兆就不够需要升级到万兆口。BFD参数一般检测间隔建议100ms-300ms倍数2-3次也就是故障感知在0.3-1秒左右。有的设备支持30ms*3的高强度检测但消耗CPU资源不是万不得已不建议这么激进。切换时间预期链路聚合故障切换一般1秒静态路由BFD联动一般1-3秒VRRP切换3秒以内算常见。把这些预期写进SLA文档跟客户对齐免得事后扯皮。这里给个具体例子某酒店280个AP峰值在线并发1800终端按每终端2Mbps估算上行流量约3.6Gbps。AC用双万兆上行分别做Eth-Trunk各两个万兆口接两台核心交换机。单条万兆链路故障剩余带宽仍能满足峰值需求这就是把参数算透的意义。3. 冷热备机制深度对比3.1 冷备简单直接的备胎冷备的冷字很形象——备用AC平时不上电不接业务甚至放在机柜角落落灰。主AC故障了人工把业务切到备机备机加载配置后启动AP重新注册可能需要几分钟到几十分钟。切换期间网络基本是中断的。冷备的优势是成本低、结构简单、不引入双机同步的复杂度。对很多小型项目来说几十个AP业务容忍5-15分钟中断冷备完全够用。我见过一个连锁门店场景总公司采购了两台AC平时只运行一台另一台定期做配置备份故障时远程指导门店运维换线换机虽然折腾但总比没有备用机强。冷备的坑主要是配置漂移。主AC上线后不断被调优、加新AP、改认证策略而备AC还是出厂状态。真到切换那天备机上线后发现配置和当前网络差了一大截光恢复配置就得老半天。所以冷备的重点不在设备本身而在配置管理的纪律每次改完主AC的配置必须同步导出并更新备AC的配置基线。3.2 热备无缝切换的代价与回报热备是主备两台AC同时运行备机不仅在还实时同步主机的状态。同步的内容包括三类一是配置数据比如SSID、认证策略、无线参数保证备机能接管相同业务二是动态状态比如AP的注册信息、终端的关联表、漫游记录、Portal在线用户等这是热备和冷备最本质的差别三是链路状态主备之间的心跳和业务通道状态。主AC故障时备AC通过心跳超时感知主设备异常自动接管业务。接管方式可能是VRRP地址漂移备机拉起虚拟IP也可能是AP侧感知主AC失联后自动向备AC重新注册。理想情况下已关联的终端可能觉察不到变化AP重新注册过程在几秒内完成。热备的代价也很明显成本翻倍、配置复杂度高、还存在脑裂风险。脑裂是指主备之间心跳链路断了两台设备都认为对方故障都变成主设备争抢IP、争抢AP控制权导致网络混乱。这个问题在后面排查章节专门讲。热备适合医院、工厂、金融网点这类业务中断影响巨大的场景但选型时要用值不值来衡量而不是有没有。3.3 冷热备选型决策表为了帮大家做方案时少纠结我给一个选型表按项目规模、业务容忍度、预算三个维度来分维度冷备热备切换方式人工手动切换自动切换RTO恢复时间分钟级到十几分钟秒级通常3-10秒RPO数据丢失量配置有差异动态数据全丢动态表项可同步基本无丢失硬件成本一台备机无需高性能两台同配置可能还要加心跳口运维复杂度低但配置管理要求高高需定期演练和版本对齐典型场景连锁门店、小分支、SOHO医院、园区、工厂、大型商场AP规模建议几十到一两百两百以上或跨多区域部署这里补充一个实操建议如果AP数量超过150或者客户明确说断网五分钟就要投诉就不要再纠结冷备了直接上热备。相反项目预算有限且业务时段固定冷备配合完善的配置备份脚本是可以接受的方案。4. 实操落地从规划到验证4.1 环境规划与网络拓扑设计实际操作中AC的双链路和双机热备通常放在一起规划。我推荐的最稳拓扑是旁挂双机上行双链路两台AC分别接到两台核心交换机AC与核心之间用两个物理口绑定为一个聚合口作为双链路备份。两台AC之间专门接一根独立的直连线或走管理网作为心跳口用于热备状态同步。业务VLAN、AP管理VLAN、AC管理地址提前规划虚拟IP如果有VRRP放到业务网段。AP通过DHCP Option 43或DNS方式发现AC这里建议配置两个AC地址让AP知晓有多个AC可选。一个常见问题是AC旁挂时上联口怎么接如果只有一台核心交换机但想要热备两台AC都接到同一台核心那核心就成了新的单点所以有条件最好把核心做成堆叠或双机否则后端冗余做了也白做。这个我在项目评审里反复提过。4.2 配置实施要点含命令示意配置步骤按顺序做先链路再热备再验证。链路聚合属于二层基础配置这里以某主流厂商命令行风格为例演示核心思路不同设备命令略有差异但逻辑一致# 在AC上创建Eth-Trunk绑定两个物理口 interface Eth-Trunk1 port link-type trunk port trunk allow-pass vlan 100 200 # interface GigabitEthernet0/0/1 eth-trunk 1 # interface GigabitEthernet0/0/2 eth-trunk 1接着配置热备功能。热备通常分成两步建立主备关系、开启业务模块同步。# 配置AC间心跳与主备角色 hot-backup enable service-interface Eth-Trunk2 peer-ip 10.0.1.2 local-ip 10.0.1.1 priority 150 # 主设备优先级高 preempt disable # 关闭抢占避免回切引发二次震荡 # # 开启关键业务模块的实时同步 hot-backup module capwap hot-backup module user-table hot-backup module portal这里有几个细节很多人第一次踩坑。第一心跳口不要和业务口共用物理链路否则业务拥塞会把心跳报文也堵住导致误判主备故障。第二priority设置要拉开差距比如主150、备120防止网络抖动时备机误抢主。第三preempt建议默认关闭因为主设备恢复后如果自动抢回会引发毫秒级或秒级业务抖动业务窗口敏感时很尴尬如果不关抢占下文第5.4里还有配置同步的风险。配置完热备后再检查CAPWAP隧道和AP接入。AC双机在部署时需要注意STA终端关联表同步不然用户本来连着上网AC切换后终端列表全空会导致用户无法漫游甚至重新认证。4.3 故障演练与切换验证配置不等于完工热备必须演练。我第一次给某工厂做双机热备时配完自我感觉良好结果演练拔主AC电源时备AC没有按预期接管AP离线了一分多钟才回来。原因后面排查发现是心跳用了管理VRF管理链路切换时主备心跳互相不可达触发了一次误切换。从那以后我养成了一个习惯不管现场多赶必须做完整的故障演练并记录。演练项目建议按下面这个表格来做每条都记录预期值/实测值/是否通过故障模拟操作预期影响实测结果拔掉主AC的一根上联网线AP和终端无感知流量秒级重分布切换时间0.5秒无终端掉线断开主AC与核心的全部上联链路备AC接管主角色AP重新注册终端短暂感知但不断网4-8秒恢复视频会议卡顿无掉线直接关闭主AC电源同上还伴随终端重新认证情况恢复时间6秒部分终端重认证拔掉AC间心跳线不应出现双主备机不能抢占业务备机保持待命但日志报critical告警恢复主AC供电主备关系恢复业务不中断不应频繁切换主设备回归standby业务无感知每次演练后把两根链路摘除再插回还要测试链路恢复后的流量回切是否正常。注意双链路和热备的回切机制可能互相影响如果主链路恢复后自动回切加上热备的抢占可能瞬间出现路由抖动。所以我在很多项目里把链路回切设置为手动或延时尽量降低抖动窗口。5. 常见问题与排查实录5.1 主备切换失败的典型原因切换失败是热备最常见的坑排查顺序很重要。多数情况按以下优先级查心跳链路问题心跳口物理不通、对端地址写错、心跳报文旁路进业务口。表现是主备状态互相不可见日志刷peer unreachable。解决办法是单独拉一根直连心跳线并在AC日志里关注心跳丢包率。优先级配置不当主备priority差距太小网络抖动导致备机抢主来回震荡。建议差距至少30同时开启/关闭抢占要明确预期。检测机制和热备联动缺失只配了热备没配BFD或者track导致主AC已经和网络脱管但心跳还活着备AC没有触发切换。需要把上行健康状态的track结果和热备角色绑定。如果你在现场遇到主AC电源都关了备AC还不接管这类问题先查心跳是否还通再查备AC是否处于standby角色最后看接口状态和ARP表项。我遇到过最离奇的是两台AC心跳口都up但ARP是静态配置错误导致备机一直收不到对端的通告报文始终认为主AC活着。5.2 会话丢失与终端掉线问题热备不等于零感知。很多热备方案真正同步的是AP注册表但终端的Portal认证状态、DHCP租约不一定同步。结果AC切换后AP又上线了但用户需要重新认证视频通话中断。这在一些认证场景尤其明显。解决思路有三个方向一是确认热备配置里是否开启了user-table同步很多设备默认不同步终端表项需要手动打开二是把认证服务器的会话超时时间调长让备AC接管后能沿用原会话三是给无线SSID开启本地转发让终端的数据面流量在AP侧直接转发AC故障对用户数据的影响会小很多。但本地转发也有代价比如漫游和集中管控会弱化需要权衡。5.3 双链路负载不均问题链路聚合最常见的表现是两条链路一条跑满一条闲着。这通常不是链路故障而是哈希算法的问题。二层聚合按MAC、三层聚合按IP如果源/目的地址变化少哈希分不均匀。排查时可以看聚合口各成员的字节计数对比差距。如果长期不均衡尝试调整哈希因子比如从源IP目的IP换成源MAC目的MAC或者开启增强型的对称哈希。这里提醒一句不要看到主备链路上备链路没有流量就认为是故障如果设计就是主备非负载分担模式链路idle是正常的。设计文档里写清楚是聚合还是主备排查时心里才有数。5.4 配置同步与版本一致性热备系统最大的隐患往往不是切换失败而是主备配置漂移。比如主AC加了一个SSID备AC没有同步故障切换后这个SSID直接消失终端全失联。冷备场景尤其容易发生热备场景也会因为某些模块不在同步范围内导致差异。我的排查和预防经验是建立配置基线每次割接或变更前导出主备AC配置对比有差异先对齐再操作。固件版本严格一致热备对双机软件版本要求很严格不相同可能导致同步功能异常或切换时报错。升级时一定要先备后主或者按厂商指引走滚动升级。使用网管或脚本做定期备份很多项目我都是加个夜间的自动备份任务把两台AC的配置文件定时传到日志服务器出问题可以快速比较。恢复操作留痕如果备机临时接管过业务后续主AC恢复时配置可能已经被备机改过同步方向要弄清楚不要用旧配置把新配置覆盖掉。给一张速查表方便现场快速定位现象可能原因优先排查点两台AC同时显示Master心跳中断/心跳接口故障心跳线物理状态、心跳报文统计AP不注册到备ACAP配置的AC地址列表不完整DHCP Option 43或DNS解析结果切换后终端掉线重认证终端表项未同步user-table/portal会话同步开关聚合链路流量不均衡哈希因子不匹配各成员口计数器、哈希因子主AC恢复后反复切换抢占开启且优先级差小preempt配置、priority差配置不同步备份配置未刷新配置基线对比、同步状态6. 后记我在实际操作中的几点体会做了这么多AC双链路和冷热备项目最后分享几个可能教科书里不写、但现场很管用的体会。第一别把冷热备当作一个配置项看待它更接近一套运维流程。冷备不是把备机放机柜里就完了配置基线、切换预案、联系人名单一样都不能缺。我见过最省心的冷备项目靠的是一份写得很烂但每次变更都更新的Word文档和一个每季度帮你拔插一次备机的网工。第二双机热备上线前一定把切换时要不要抢占这个问题和业务方确认死。工厂产线半夜不希望AC自己回切办公楼可能无所谓。很多事故不是设备不行而是回切策略和业务窗口不匹配。第三混合组网里双链路备份和冷热备永远要放在同一个拓扑里看。AC的双上联必须解决上游交换机单点热备的心跳必须独立于业务链路AP发现AC必须把两个地址都写进去。这个思路几年前我踩坑后总结为三个必须之后设计高可用方案一直沿用项目基本没有再被这种基础问题绊倒过。希望这篇总结能帮大家少走点弯路。如果手头正在做AC高可用方案建议先把上面的选型表和排查速查表存下来到现场大概率用得上。