做无线网络项目这些年，AC（Access 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不注册到备AC | AP配置的AC地址列表不完整 | DHCP Option 43或DNS解析结果 |
| 切换后终端掉线重认证 | 终端表项未同步 | user-table/portal会话同步开关 |
| 聚合链路流量不均衡 | 哈希因子不匹配 | 各成员口计数器、哈希因子 |
| 主AC恢复后反复切换 | 抢占开启且优先级差小 | preempt配置、priority差 |
| 配置不同步 | 备份配置未刷新 | 配置基线对比、同步状态 |
6. 后记：我在实际操作中的几点体会
做了这么多AC双链路和冷热备项目，最后分享几个可能教科书里不写、但现场很管用的体会。
第一，别把冷热备当作一个"配置项"看待，它更接近一套运维流程。冷备不是把备机放机柜里就完了，配置基线、切换预案、联系人名单，一样都不能缺。我见过最省心的冷备项目，靠的是一份写得很烂但每次变更都更新的Word文档，和一个每季度帮你拔插一次备机的网工。
第二，双机热备上线前，一定把"切换时要不要抢占"这个问题和业务方确认死。工厂产线半夜不希望AC自己回切，办公楼可能无所谓。很多事故不是设备不行，而是回切策略和业务窗口不匹配。
第三，混合组网里，"双链路备份"和"冷热备"永远要放在同一个拓扑里看。AC的双上联必须解决上游交换机单点，热备的心跳必须独立于业务链路，AP发现AC必须把两个地址都写进去。这个思路几年前我踩坑后总结为三个"必须"，之后设计高可用方案一直沿用，项目基本没有再被这种基础问题绊倒过。
希望这篇总结能帮大家少走点弯路。如果手头正在做AC高可用方案，建议先把上面的选型表和排查速查表存下来，到现场大概率用得上。
