Aruba 70xx Master Redundancy配置与切换验证

1. 先搞清楚 70xx 上 Master Redundancy 到底在保什么

Aruba 无线控制器 70xx 系列，很多朋友是拿它当中小园区或者分支机构的"大脑"来用的。到 8.x 版本，AOS 的架构彻底转向了 Master / Local 分层，Controller 的角色被拆得更细。8.x 之前，一台 Master 基本就是唯一的大脑，配置、认证、策略、AP 上线全靠它；一旦它出问题，下面的 Local 和 AP 虽然还能靠转发面撑一小会儿，但控制面的事情基本停摆，客户端掉线、新 AP 上不来、Portal 页面打不开，现场一团乱。8.x 这套Master Redundancy（主控冗余），想解决的正是这个单点问题：两台 Master 互相盯着，一主一备（或者双主），谁的数据库新、谁的 VRRP 优先级高，谁就接管，另一台随时顶上。

我第一次在 70xx 上做这个配置，是因为一个客户的核心机房只有一台 7030 做 Master，机房里跳电一次，整栋楼的无线认证就瘫了二十分钟。那次之后客户拍板要加冗余，我就开始认真研究 8.x 的这套机制。这篇文章就把我当时踩过的坑、配过的命令、验证过的方法，完整地摊开讲一遍，从"为什么要做"讲到"怎么做、怎么验、怎么排错"，适合已经有一点 ArubaOS 基础、但没正儿八经上过 Master Redundancy 的朋友参考。

1.1 单台 Master 挂掉的后果比想象中严重

很多人觉得"AP 上有配置，Master 挂了照样能转发"，这话只对了一半。在 ArubaOS 8.x 的架构里，AP 的控制隧道是挂在 Local 或者 Master 上的，认证、AAA 交互、集中转发的隧道建立、策略下发这些，都离不开 Master。Master 一挂，已经认证过的客户端可能还能靠数据面继续跑一阵子，但只要涉及重新认证、AP 重连、策略更新，立刻卡住。更麻烦的是，8.x 里 Master 承担着数据库（本地用户、认证记录、AP 数据库）的统一下发职责，它一停，整个网就像大脑缺氧。

而 70xx 系列的定位本身就偏"轻量中枢"，一台设备要扛几十上百个 AP，CPU 和内存的余量并不算特别宽裕，硬件层面的老化、电源故障、人为误操作（比如改配置把管理口锁死）都是现实风险。所以给 70xx 做 Master Redundancy，不是为了炫技，是为了在真正的故障窗口里，把"整网失能十分钟"压缩成"抖一下、几秒恢复"。

我当时的判断很简单：客户既然用了 7030 扛核心，就没有理由不给它配一个备胎。这个备胎不一定非得是同样闲着的硬件，它可以同时承担一部分转发任务，关键时候才顶上来做主控。

1.2 Master Redundancy 的核心机制是"数据库 + VRRP + 心跳"

这套机制拆开看是三根支柱，理解了这三根，配置就不容易配错。

第一根是数据库同步。两台 Master 之间会同步配置数据库和本地数据库，包括 WLAN 配置、认证策略、本地用户这些信息。同步是增量的，谁手里数据新，谁就在主控位。8.x 里这部分由 Master 之间的对等关系来维护，配置一致是前提。

第二根是VRRP 虚拟 IP。这是整个方案里最关键的一个设计。真实的 Master 有各自的物理 IP，但对下（Local、AP、外部 AAA）暴露的是一个 VRRP 虚拟 IP，也就是虚拟主控地址。所有 Local 都指向这个虚拟 IP，这样无论哪台 Master 在主控位，IP 都不变，下面完全无感。Master 切换的本质，就是 VRRP 主备关系的切换，谁拿到虚拟 IP，谁就是 Master。

第三根是心跳链路。两台 Master 之间要有一条能互相探活的通道，通常就是它们直连的管理网段。这条链路会跑 IPSec 加密的对等通信，心跳断了对端就认为你挂了，触发抢占或者接管。

这三根支柱里，数据库同步决定了"切过去之后配置对不对"，VRRP 决定了"谁接管"，心跳决定了"什么时候切"。任何一根出问题，冗余就是纸糊的。

1.3 70xx 里哪些型号能玩这套

不是所有 70xx 都能无差别地上 Master Redundancy。7005、7010 这种入门型号，在 AP 容量和功能授权上都有取舍，做冗余前一定要先看 datasheet 和授权。7024、7030 这类中端型号，做 Master Redundancy 相对从容，也是我实操最多的型号。硬件上两台 Master 最好是同型号，如果不同型号，也要确认它们能组成冗余对，否则容易在数据库同步阶段报奇怪的错。

还有一个坑是授权（License）。Master Redundancy 相关的功能通常需要对应的高级授权，缺授权时你会发现命令能敲下去，但状态一直起不来。我的习惯是配置前先show license把该有的都确认一遍，宁可提前补，也别配到一半卡住。

2. 配置前的规划与准备：把地基打牢

Master Redundancy 这种"两台设备协同"的配置，最忌讳上来就敲命令。前期规划做扎实，后面能省一大半排错时间。我在客户现场踩过的坑里，至少一半是"IP 规划没想清楚""时间没对齐""对端地址填错"这类低级的规划问题，完全不涉及技术难度。

2.1 网络拓扑和 IP 该怎么分

先给两台 Master 划好地址。假设我们有 Master-A 和 Master-B 两台 70xx，管理网段是 10.10.10.0/24，那么规划大概是这样的：

这里要强调一点：虚拟主控 IP 是给下面设备指向用的，两台 Master 的物理 IP 是它们自己用的。很多人配完 VRRP 之后，忘记把 Local 上配置的 Master 地址从物理 IP 改成虚拟 IP，结果主备切了，下面的设备还在死盯着已经挂掉的物理 IP，切换等于没发生。这是最常见的"配了但没用"的原因。

另外，两台设备之间的 RTT 建议很低，最好在同一机房、同一交换机下，因为数据库同步和心跳对延迟比较敏感。如果有条件，给心跳留一条独立的链路更稳妥，管理网和心跳混跑也行，但要保证这条链路不会被 STP 收敛或者链路抖动频繁打扰。

2.2 时间和基础配置必须先对齐

两台设备的时间必须一致，我习惯在配冗余之前先把 NTP 配上，让两台 Master 指向同一个时间源。时间差太大的时候，数据库同步的版本判断会出现诡异的比较结果，轻则同步慢，重则主备角色反复横跳。顺手把 hostname、default-gateway 这些基础项也配好，hostname 最好和角色对应，比如 aruba-master-a / aruba-master-b，后面看日志时一眼就能分清是谁在说话。

具体的基础配置大概是这样：

(host) [mynode] (config) #hostname aruba-master-a (aruba-master-a) [mynode] (config) #ntp server 10.10.10.1 (aruba-master-a) [mynode] (config) #ip default-gateway 10.10.10.254 (aruba-master-a) [mynode] (config) #clock timezone Asia/Shanghai

对应地，Master-B 上把 hostname 换成 aruba-master-b，其余保持一致。配完之后用show clock和show ntp status确认两台时间对齐，这一步别嫌烦，我见过不止一次因为时间没对齐导致 master-redundancy 状态卡在 INIT。

2.3 型号、授权、版本三件套先检查

动手前把这三样确认清楚，能避免很多无用功：

• 型号：两台是否同型号或官方支持组成冗余对的型号；
• 授权：Master Redundancy 相关的 License 是否已经安装；
• 版本：两台 AOS 版本是否一致，或者至少是官方允许协同的版本。

版本这块我特别提醒一句，AOS 8.x 的小版本之间差异不算小，两台 Master 版本不一致时，虽然有时也能同步，但历史上出现过同步后行为不一致的情况。稳妥做法是先把两台刷成同一个版本，再配冗余。

检查命令：

(aruba-master-a) [mynode] #show version (aruba-master-a) [mynode] #show license (aruba-master-a) [mynode] #show switches

show switches能看到当前 8.x 集群里各个控制器的角色，为后面验证做准备。

3. VRRP 虚拟 IP 的搭建：冗余的命根子

VRRP 是 Master Redundancy 的核心，配置本身不难，但细节多，配错了就是"看起来有主备，实际不切换"。我一般先单独把 VRRP 配好验一遍，再叠加 master-redundancy，这样出了问题是哪一层的，一眼就能分清。

3.1 VRRP 基础配置的逐行拆解

在两台 Master 上，各自对管理所在的 VLAN 接口启用 VRRP。以 Master-A 为例，假设管理口在 VLAN 1：

(aruba-master-a) [mynode] (config) #interface vlan 1 (aruba-master-a) [mynode] (config-submode) #ip address 10.10.10.11 255.255.255.0 (aruba-master-a) [mynode] (config-submode) #exit (aruba-master-a) [mynode] (config) #vrrp 1 (aruba-master-a) [mynode] (config-vrrp) #ip address 10.10.10.10 (aruba-master-a) [mynode] (config-vrrp) #priority 110 (aruba-master-a) [mynode] (config-vrrp) #preempt (aruba-master-a) [mynode] (config-vrrp) #authentication aruba123 (aruba-master-a) [mynode] (config-vrrp) #exit

Master-B 上把接口地址改成 10.10.10.12，VRRP priority 改成 100（比 A 低），其余保持一致：

(aruba-master-b) [mynode] (config) #interface vlan 1 (aruba-master-b) [mynode] (config-submode) #ip address 10.10.10.12 255.255.255.0 (aruba-master-b) [mynode] (config-submode) #exit (aruba-master-b) [mynode] (config) #vrrp 1 (aruba-master-b) [mynode] (config-vrrp) #ip address 10.10.10.10 (aruba-master-b) [mynode] (config-vrrp) #priority 100 (aruba-master-b) [mynode] (config-vrrp) #authentication aruba123 (aruba-master-b) [mynode] (config-vrrp) #exit

几个关键参数说一下：vrrp 1里的 1 是 VRID，两台必须用同一个 VRID；ip address填的是虚拟 IP，不是自己的物理 IP；priority决定谁当主，数值大的当主，两台必须不同；preempt表示抢占，主挂了备接管之后，主恢复回来会重新抢回主控位。

注意：VRRP 的认证密码两台必须一致，否则会一直卡在认证失败状态，备机永远接管不了。

3.2 虚拟 IP 规划里最容易忽略的一个细节

虚拟 IP 必须是管理网段里空闲的地址，不能和任何设备冲突，也不能是网络号或广播号。我遇到过客户随手填了个地址，结果跟机房里某台打印机撞了，VRRP 起来了但 ARP 冲突，间接导致切换不稳定。配完 VRRP，一定要用show vrrp 1确认状态是 MASTER 还是 BACKUP，两台状态应该一主一备。

(aruba-master-a) [mynode] #show vrrp 1

输出里重点关注 State、Priority、Virtual IP 这几列。正常情况下，A 是 MASTER、B 是 BACKUP。如果两台都是 BACKUP 或都是 MASTER，说明 VRRP 通信没建起来，先查链路和认证。

3.3 把 Local 指向虚拟 IP

VRRP 配好之后，千万不要忘记这一步：所有 Local 控制器（以及需要指向 Master 的其他设备）上，原来指向物理 IP 的地方，全部改成虚拟主控 IP。8.x 里 Local 是通过master相关的配置指向主控的，改完之后它就会一直盯着 10.10.10.10，不管实际是哪台设备在主控位。

这一步是整个方案"无感切换"的关键。我当时在客户现场，就是因为漏改了 Local 的指向，第一次测试切换时下面完全没反应，排查了半天才发现 Local 还指着物理 IP。改完之后，切换瞬间就通了。所以我把这一步单独拎出来强调，别嫌啰嗦。

4. master-redundancy 的配置与数据库同步

VRRP 是前提，master-redundancy 才是让两台设备真正"结为冗余对"的动作。这部分的核心是配置对等地址、对等密钥，然后建立数据库同步。

4.1 配置对等关系与 IPSec 密钥

在 Master-A 上进入 master-redundancy 配置模式，指定对端（Master-B）的真实物理 IP，并配置对等密钥：

(aruba-master-a) [mynode] (config) #master-redundancy (aruba-master-a) [mynode] (config-master-redundancy) #peer-ip-address 10.10.10.12 (aruba-master-a) [mynode] (config-master-redundancy) #peer-ipsec-key aruba@123

在 Master-B 上做对称配置，对端指向 Master-A：

(aruba-master-b) [mynode] (config) #master-redundancy (aruba-master-b) [mynode] (config-master-redundancy) #peer-ip-address 10.10.10.11 (aruba-master-b) [mynode] (config-master-redundancy) #peer-ipsec-key aruba@123

两边的peer-ipsec-key必须完全一致，大小写、特殊字符都不能错。密钥不一致时，对等隧道建不起来，状态会停在类似 INIT 或失败的状态，日志里能看到 key mismatch 之类的提示。我一般会把密钥设得既有大小写又有符号，别用纯数字，减少被猜到的可能，但同时也记牢，因为输错一位就废了。

提示：具体进入 master-redundancy 后的子命令名称和可用选项，随 AOS 8.x 小版本可能有细微差别，敲之前先打问号看命令补全，确认当前版本支持哪些子命令。

4.2 数据库同步怎么触发和验证

对等关系建立后，数据库同步会被触发。8.x 里同步是基于版本的增量同步，正常会看到两台设备状态互相确认。可以手动触发同步来加速：

(aruba-master-a) [mynode] #database synchronize

执行后观察日志和状态。验证的常用命令：

(aruba-master-a) [mynode] #show master-redundancy (aruba-master-a) [mynode] #show database synchronize

重点看对等状态是否是 UP / established，同步是否有报错。数据库同步不是一次性的事，配置变更后会继续同步，所以两台设备的配置漂移不能太大，否则同步会一直报冲突。

我实测下来的体会是：同步初始阶段最慢，尤其本地数据库里东西多的时候（比如一堆本地用户、证书），第一次全量同步可能要几分钟。耐心等一等，别急着判断失败。同步过程中如果中途断了心跳，会从头再来，所以初期一定要保证链路稳定。

4.3 让角色关系定型：谁主谁备

数据库同步完成、VRRP 角色明确之后，主备关系就定型了：拿到虚拟 IP 的那台（VRRP 优先级高的 A）同时是 Master 主控，B 是备控。此时用show master-redundancy应该能看到两端互相 recognize，角色清晰。如果 VRRP 主备和 master 主备不一致，说明配置哪里有矛盾，比如 VRRP 优先级和预期相反，或者两台都配了 preempt 导致争抢。

我建议配置完成后，按这个顺序验证一遍：先看show vrrp一主一备，再看show master-redundancy两端对等 UP，最后看show switches里主备角色清楚。三步都对，才算真正配好。

5. 切换测试与常见问题排查实录

配置完成不等于能用，一定会遇到"看着正常、切换却掉链子"的情况。把切换测试当成验收的一部分，是我做这套方案最大的心得。下面把我实测过的切换方法和典型问题整理出来。

5.1 手动验证切换的几种方法

最直接的验证方式是让主控"下线"，看备控能不能自动接管、下面是否无感。手法有几种，安全性从高到低排列：

• 正常重启主控：在主控上执行reload，等它起来的过程里观察备控是否接管、Local 是否无感。这种方式最接近真实故障，推荐。
• 断开主控的上行链路：拔掉主控管理/上行链路，模拟链路故障，观察 VRRP 是否切换。
• 调整 VRRP 优先级：临时把主控优先级调低、备控调高，触发切换，用于不中断业务的验证。

我的习惯是先做一次优先级调整的软切换（业务基本无感），确认机制通了；再找窗口做一次真重启，确认极端情况也可用。软切换如果都不成功，真重启也白搭，先修好再说。

切换后要验证的点：虚拟 IP 是否漂移到备控、Local 是否还在线、客户端是否重新认证、AP 是否正常。如果虚拟 IP 漂移了但客户端掉线，问题多半在数据库同步，说明备控拿到的配置和主控不一致，切过去后行为变了。

5.2 常见问题速查表

这张表是我自己排错时反复用到的，基本覆盖了八成以上的现场问题。每次遇到新的，我会补充进去，时间久了就成了自己的"急救手册"。

5.3 一个让我印象深刻的坑：心跳链路被管理网拖累

有一次客户的 Master Redundancy 老是偶发性地切换，日志里能看到对等关系短暂中断又恢复。查了半天，最后发现两台 Master 的心跳跑在了一个频繁 STP 收敛的管理网段上，链路每次收敛，对等心跳就丢一次，丢到阈值就触发切换，切完又恢复，来回折腾。

后来我把两台之间的心跳单独划了一条链路，或者至少保证这条路径足够稳定、不参与频繁的生成树变化，问题就消失了。这个坑给我一个很深的体会：冗余方案的稳定性，很多时候不取决于配置命令，而取决于底层网络的质量。心跳链路必须是"安静"的，任何频繁抖动的东西都会把它玩坏。

所以我现在做这套方案，一定会问一句："这两台之间的链路稳不稳？会不会有 STP 或者其它周期性抖动？"如果答案是"不太确定"，那就先解决链路问题，再配冗余。

5.4 数据库同步的独家避坑经验

数据库同步这块我踩的坑最多，总结几条实战经验：

• 配置变更尽量在同步完成后做。初始同步没完成就大改配置，容易导致两边版本判断混乱，同步反复失败。
• 本地数据库别塞太多东西。本地用户、证书这一类数据越多，同步越慢。能走外部 AAA 的就别全放本地。
• 同步不是实时的，有周期。别测完一个改动立刻就想看对端生效，给它几个周期的时间，或者手动database synchronize触发。
• 同步出问题先看日志。8.x 的日志里对同步失败的原因写得很细，key、版本、链路都会写清楚，比盲猜高效得多。

这几条没有一条写在官方文档的显眼位置，但每一条都来自真实现场，希望对你有用。

我个人在实际操作里的体会是，70xx 上做 Master Redundancy，命令本身半小时就能配完，真正花时间的是前期规划、链路准备和切换验证。千万别把"命令敲完状态是绿的"当成完工，一定要真真切切地切一次，看下面到底有没有感觉。最后再分享一个小习惯：我会把两台 Master 的 VRRP 状态、对等状态、同步状态做成一张核查清单，每次变更前后都过一遍，时间久了，这套东西就从"玄学"变成"确定性操作"了。