简介：面向无线网络运维人员与网络工程师的Aruba无线AP及AC配置学习文档，系统讲解以profile为单元的配置参数分解与复用机制。Aruba通过将不同功能拆分为独立profile，使下层profile可被多个上层profile引用，既减少了参数冗余，也方便批量维护和复用。包内为1个doc文档，大小约1.06MB，已有983人学习下载。文档重点梳理了AP组的分组管理方式，说明所有AP默认归属default组、一台AP只能属于一个组，修改组参数可批量生效，也允许对特定AP单独覆盖配置；同时介绍Virtual AP如何在同一物理AP上提供多个WLAN服务，例如为访客和员工分别配置不同SSID、认证方式与访问权限；随后详解Wireless LAN Profiles、AP Profiles、QOS Profiles等主要配置模块，覆盖SSID Profile、High-throughput SSID profile、802.11k Profile、AAA profile等常见子项。通过这份资料，读者可快速理解Aruba控制器与AP的配置层级，掌握从AP组划分、虚拟AP下发到具体Profile设置的完整思路，适合从零入门或系统梳理Aruba无线配置体系的工程师参考。
1. Aruba无线AP及AC配置：一份开局文档能省下多少现场调试时间
做无线集成和运维的同行应该都有这种体会：Aruba 的 AP 和 AC 配置，官方手册动辄几百页，实际开局却往往卡在最基础的那几步——AP 不上线、SSID 不广播、漫游粘滞。这份《Aruba-无线AP及AC配置.doc》不是官方文档的翻译，它把从 AC 初始化、AP 注册、SSID 下发到认证落地的完整配置链路按现场操作顺序整理了一遍，尤其把三层组网下 AP 跨网段发现 AC 的配置方法单独拉出来讲，这一块恰好是锐捷、华三工程师刚转 Aruba 时最容易翻车的地方。
适合谁看？即将接手 Aruba 无线项目交付的集成工程师、园区无线运维人员，还有那些手里拿着 AP 却不知道怎么让 AC 认账的弱电项目负责人。这份文档解决的不是"无线原理是什么"，而是"设备到手后先敲哪条命令、参数怎么填、出问题看哪里"。
2. 组网模型先行：AC、AP、交换机在三种转发架构里的角色
2.1 集中转发与本地转发：数据面走 AC 还是走交换机
Aruba 组网里最容易混淆的概念就是转发模式。很多新手以为 AC 是"管 AP 的"，所以所有流量都必须经过 AC，这是错的。在 Aruba 体系里，AC 同时承担控制面和数据面两种可能，取决于你配置的是集中转发（tunnel mode）还是本地转发（bridge mode，Aruba 里叫 direct forwarding）。
集中转发模式下，AP 和终端之间的无线流量会被封装进 CAPWAP 隧道，一路送到 AC，再由 AC 解封装后转发到有线网络。这个模式的好处是策略管控集中，AC 能看到所有用户流量，做访问控制和漫游判决都方便；代价是 AC 的吞吐成为瓶颈，AC 到 AP 之间的链路带宽也被隧道开销吃掉一部分。本地转发则相反，AP 直接把数据从自身的以太网口转出去，AC 只负责下发配置和控制信令。终端上网流量不进隧道，AC 负载小，延迟低，适合分支办公、门店这种对成本敏感的场景。
在 Aruba OS 的命令行里，这两种模式不是在 AP 上配的，而是在 AP group 的配置文件里定义的。常见的做法是先建一个 AP group，再把 virtual AP（也就是我们说的 SSID 配置）挂到这个组下，最后指定转发模式。切换转发模式的命令是no forwarding-mode或者forwarding-mode tunnel，很多人在这一步配完忘记保存配置，结果 AP 重启后回到默认模式，整个 SSID 直接消失。
2.2 AP 发现 AC 的四种方式：二层广播不是唯一解
AP 上电之后第一件事是找 AC。小规模场景里 AP 和 AC 在同一个二层，广播就能互相发现；但园区项目里 AP 和 AC 经常跨三层，这时候就必须给 AP 指路。Aruba AP 的发现顺序在官方资料里有明确优先级，但实际现场最常用的就是三种：DHCP Option 60/43、DNS 解析 aruba-master、以及静态指定 AC 的 IP。
用 DHCP 下发 AC 地址是最省事的做法。在 DHCP 服务器上给 AP 所在的 scope 配 Option 60，值为ArubaAP，这是告诉 AP"这个 DHCP 回应是给你的"；然后配 Option 43，十六进制格式里放 AC 的管理 IP。很多人在这一步翻车是因为 Option 43 的格式写错，Aruba 要求后面跟的是十六进制长度和 IP 的十六进制编码，不是直接填 IP 字符串。举例来说，AC 地址是 192.168.10.5，Option 43 应填0C C0 A8 0A 05，其中0C是后面八位十六进制数据的长度，C0 A8 0A 05是 192.168.10.5 的十六进制。
DNS 方式相对简单，把aruba-master这条 A 记录指向 AC 管理 IP 就行。静态指定适合 AP 数量少、懒得动 DHCP 的场景，登录 AP 的 console 口执行provision-ap相关命令，或者通过 USB 配置文件导入。实际项目里我一般优先用 DHCP Option 60/43，因为 AP 后续替换、新增都不用再上塔动 AP。
2.3 转发模式选型：一张参数对比表定场景
选集中还是本地，不是看哪个"高级"，而是看你的出口和管控需求。我把两者在项目选型时的关键差异整理成表，这张表在给甲方写方案时可以直接用：
| 对比项 | 集中转发（tunnel） | 本地转发（direct） |
|---|---|---|
| 用户数据路径 | AP → AC → 核心交换机 | AP → 接入交换机 → 核心交换机 |
| AC 负载 | 高，吞吐瓶颈在 AC | 低，AC 只跑控制信令 |
| 漫游切换效率 | 高，AC 统一判决 | 依赖 AP 间协商，需开 AMC 或 802.11k/v |
| 部署成本 | AC 需高规格型号 | AC 可用入门型号 |
| 适用场景 | 集中管控、安全审计、访客隔离 | 门店、分支、高吞吐业务 |
从这里也能看出，锐捷、华三设备上的"旁挂""直连"概念和 Aruba 的转发模式有一点对应关系，但不完全相同。锐捷的旁挂 AC 通常只做管理，数据本地转发；而 Aruba 的集中转发模式下数据必须穿隧道。从华三迁过来的同事常常默认 AC 可以"旁挂"就完事，结果用户数据没走隧道，审计策略全部落空。配置之前先确定转发模式，等于确定整张网的架构骨架，这一步省不得。
3. 初始化与 AP 上线：从 AC 首次登录到 AP 稳定注册的完整路径
3.1 首次登录 AC：管理地址、时钟与空配置开局
Aruba 控制器首次通电后默认管理 IP 是 172.16.0.1，电脑网口配同网段地址，浏览器访问 HTTPS 进入初始化向导。这里要提醒一点：Aruba AC 的管理口和业务口在默认状态下不是一个概念，初始化向导会让你选 VLAN 1 管理，这个选择后续改起来比较麻烦，建议一开始就规划好管理 VLAN 和业务 VLAN 分开。
初始化向导会要求设置管理员账户、时区和 NTP。时区这一项经常被忽略，但 Aruba 的证书校验、AP 上线时间戳、日志审计全依赖系统时钟。时钟不准的典型现象是 AP 注册后显示 down，控制器日志里刷时间不同步的报错。我一般会在向导里直接指定一个内网 NTP 服务器地址，如果现场没有 NTP，至少把时区调成 Asia/Shanghai，再用clock set手工校准一次。
向导走完后进入命令行或 Web 界面，第一件事是确认基础配置已经生效：
show running-config | include hostname show interface mgmt show clock show ip route这几条命令依次确认主机名、管理接口地址、系统时间和路由表。逻辑上是先把控制器的"身份"定下来，再往下配 AP 和 SSID。show clock这一条看似多余，实际上后面排 AP 上线问题时要反复用到，日志时间对不上，一切排查都是猜。
3.2 License 与版本核对：AP 注册失败的一半原因在这里
AP 不能上线，十次里有四五次不是配置问题，而是 License 不够或者 AP 固件和 AC 版本不匹配。Aruba 的 License 是绑定 AC 的，分 PEF（策略增强）、RF Protect（频谱安全）等不同功能授权，而最基本的 AP 接入数量授权决定了这台 AC 最多能管多少台 AP。License 不足时，AP 会显示为pending或者unlicensed，控制器日志会有明确提示。
版本匹配是另一个隐蔽问题。Aruba AP 从 8.x 开始用的是独立于 AC 的固件镜像，但 AC 侧有一个 AP 固件库，AP 注册时会从 AC 拉取匹配的镜像。如果 AC 版本太新、AP 固件太老，或者反过来，AP 会反复重启、注册不上。常见做法是先show ap active看 AP 状态，再用show ap debug查看 AP 和 AC 的版本协商过程。文档里给出的建议是开局前用show ap database核对 AP 型号和固件版本，并在 AC 上升级到统一版本包，而不是逐台 AP 手工刷固件。
检查 License 和版本的命令组合：
show license show ap database show imageshow license看授权数量和类型，show ap database看 AP 是否已被发现以及当前状态，show image看 AC 当前运行镜像。排错时按这个顺序走，能快速过滤掉一半的"假故障"。有一次我们在项目现场看到 AP 一直 Pending，查了半小时 DHCP 和路由，最后发现是 License 只买了 8 个 AP，现场却有 10 台，剩下两台一直起不来。
3.3 AP 上线确认：从 Pending 到 Up 的状态机
AP 物理接线、获得 IP、找到 AC、完成版本同步后，会进入注册流程。在控制器上观察 AP 状态，通常会经历pending→establishing→up三个可见阶段，这个过程从几十秒到几分钟不等，取决于 AP 固件是否需要从 AC 下载镜像。
AP 第一次上线耗时最长，因为要拉镜像。如果现场 AP 数量多，我一般会让 AP 分批上电，避免同时拉镜像把 AC 的 CPU 打满。AP 状态变为 up 后，还要确认它被归入了正确的 AP group。Aruba 默认所有 AP 都在default组，如果业务 SSID 是配在自定义组里的，AP 没进组就等于没有配置，状态再 up 也不广播 SSID。
确认 AP 正常在线的命令如下：
show ap active show ap monitor show ap associationshow ap active输出里能看到每个 AP 的 IP、型号、固件版本、在线时长和所属组。show ap monitor看 AP 的射频状态，show ap association看当前关联的无线客户端数量。我在交付检查单里固定要求这三条命令的输出截图，信息量足够判断 AP 是否真正"能用"，而不是仅仅"已上线"。
4. 业务下发：SSID、VLAN 与认证策略的配置顺序和参数
4.1 VLAN 与网段规划：管理、业务、访客三段隔离
无线业务配置的第一步不是写 SSID，而是先把 VLAN 规划定下来。Aruba 配置里涉及三类 VLAN：AC 管理 VLAN、AP 管理 VLAN、用户业务 VLAN。AP 管理 VLAN 决定 AP 获取 IP 的网段，AC 管理 VLAN 决定控制器管理口的地址归属，用户业务 VLAN 则是终端上网后所在的网段。
三层组网下，这三个 VLAN 通常分布在不同的网段。比如 AC 管理 VLAN 10，AP 管理 VLAN 20，员工业务 VLAN 30，访客 VLAN 40。VLAN 之间的互访由核心交换机上的三层路由控制，而 AP 和 AC 之间的 CAPWAP 隧道如果走集中转发，还需要确保 AC 能路由到 AP 管理网段和业务网段。很多人在这里忽略了一个细节：集中转发模式下，用户流量被封在隧道里到 AC 再解封装，所以 AC 需要能访问业务 VLAN 的网关，否则终端拿到了 IP 也出不了网。
一张典型的分段规划表可以这样列：
| VLAN 用途 | VLAN ID | 网段 | 网关 | 说明 |
|---|---|---|---|---|
| AC 管理 | 10 | 192.168.10.0/24 | 核心交换机 | 控制器带外管理 |
| AP 管理 | 20 | 192.168.20.0/24 | 核心交换机 | AP 获取 IP，发现 AC |
| 员工业务 | 30 | 192.168.30.0/24 | 核心交换机 | SSID 绑定，终端上网 |
| 访客业务 | 40 | 192.168.40.0/24 | 防火墙/AC | 隔离互访，限速 |
这张表的用意是让配置时有一个统一的参照系。实际配置中，用户业务 VLAN 必须先在交换机上创建并放行 trunk，AC 侧也要在 VLAN 配置里加入对应 VLAN ID。跳过交换机直接把 SSID 绑到 VLAN 30，AP 的本地转发流量到了接入交换机发现 VLAN 不存在，终端关联成功却拿不到 IP，这是最常见的低级错误之一。
4.2 SSID 创建与 VLAN 绑定：ESSID 与 SSID Profile 的关系
Aruba 的 SSID 配置逻辑和其他厂商不太一样，它把"无线网络名字"和"无线网络参数"分成两层。虚拟机 AP（Virtual AP）相当于一个 SSID 实例，里面绑定 SSID Profile、VAP 认证方式、VLAN 等参数。新建一个 SSID 的正确顺序是先建 SSID 配置文件，再建 Virtual AP 配置文件，最后把两者关联并应用到 AP group。
configure terminal profile ssid "Staff-WiFi" ssid "Staff-WiFi" essid "Staff-WiFi" auth-server "internal" wpa2-psk ascii "YourPassphrase" vlan 30 max-authentication-failures 3 exit profile virtual-ap "Staff-VAP" ssid "Staff-WiFi" vlan 30 ssid-profile "Staff-WiFi" forward-mode tunnel exit ap-group "default" virtual-ap "Staff-VAP" exit write memory这段配置的逻辑按顺序解释：第一部分创建 SSID 配置文件，定义了无线网络的名称和接入认证方式，wpa2-psk ascii后面的口令就是终端连接的密码。第二部分创建 Virtual AP 配置，关键参数是forward-mode tunnel，指定这个 SSID 走集中转发；如果前面规划的是本地转发，这里要改成forward-mode direct并且不要绑定 AC 侧的业务 VLAN 网关。第三部分把 Virtual AP 挂到 AP group，所有属于该组的 AP 都会广播这个 SSID。
参数上有两个容易忽略的地方。max-authentication-failures 3限制密码错误次数，超过后终端会被临时加入黑名单，这个参数在访客网络里特别有用，但员工网络里设得太小会导致误触发的终端被锁在门外。vlan 30在 SSID Profile 和 Virtual AP Profile 各出现了一次，两者的关系是 Virtual AP 里的 VLAN 会覆盖 SSID Profile 里的设置，如果两处不一致，终端拿到的 VLAN 以 Virtual AP 为准，排查时容易看晕。
4.3 认证落地：WPA2-Enterprise 与 Portal 的参数差异
员工 SSID 一般用 WPA2-Enterprise，访客 SSID 用 Portal 认证，这是园区项目的惯例。Aruba 配置 802.1X 认证时，需要指定 RADIUS 服务器或使用内置认证服务器。小规模项目用 AC 内置服务器可以省一台 RADIUS 设备，但用户数超过几百后，内置服务器的性能和灵活性都不够，建议接外部 RADIUS。
aaa authentication-server radius "OfficeRadius" host 192.168.50.10 key "radius-secret" aaa authentication-server "OfficeRadius" key "radius-secret" nas-ip 192.168.10.1 exit profile ssid "Staff-WiFi" ssid "Staff-WiFi" wpa2-enterprise auth-server "OfficeRadius" exitaaa authentication-server radius定义 RADIUS 服务器的地址和共享密钥，nas-ip指定 AC 发给 RADIUS 的源地址，这个地址必须在 RADIUS 服务器上登记为合法的 NAS，否则认证请求会被直接丢弃。wpa2-enterprise切换认证方式后，auth-server指向刚才定义的 RADIUS 服务器。
Portal 认证的配置链路更长，需要先启用 Web 认证、关联 Portal 页面资源，再指定认证后重定向的 ACL。文档里把 Portal 认证的常见参数列成了一个检查表，包括 Portal 服务器的 IP、端口、预共享密钥、用户闲置超时时间。实际项目里 Portal 认证掉坑最多的地方不是 AC 配置，而是 Portal 服务器上的回跳地址没写对，用户认证成功后跳不回原来的页面，被卡在一个奇怪的中间页。遇到这类问题，先在 AC 上用show web-auth state看用户的认证状态，确认用户已经通过认证，再回头查 Portal 服务的跳转配置。
5. 避坑排查：五类高频故障的现象、原因与解决记录
5.1 AP 反复重启：POE 供电不足与固件版本不匹配
现象：AP 上线后运行几分钟就掉线，然后又重新注册，循环往复，控制器日志里出现大量 AP 重启记录。现场看 AP 指示灯，一会儿绿色一会儿红色。
原因：大概率是 POE 交换机供电功率不够。双频 AP 的典型功耗在 15W 到 25W 之间，老型号 POE 交换机单端口只有 15.4W 输出，带不动双频加外置天线的 AP，AP 在射频启动瞬间电流拉高，交换机保护性断电。另一个隐蔽原因是被管理 AP 的固件版本和 AC 镜像库里的版本不匹配，AP 每次上线都触发固件重传，传一半就断。
解决：先用show ap active确认 AP 的 uptime，如果 uptime 一直上不去，基本可以断定是供电或固件问题。换用支持 802.3at 的 POE 交换机，或者用 POE 注入器单独供电。固件版本问题则到 AC 上用show ap debug查看版本协商日志，把 AC 的 AP 镜像库升级到和目标 AP 固件一致的版本。注意：一次只改一个变量，别同时换交换机又升固件，否则出问题不知道是哪一步治好的。
5.2 跨网段发现失败：DHCP Option 60/43 没下发对
现象：AP 通过 DHCP 获取到了 IP 地址，但迟迟找不到 AC，AP 状态卡在pending，控制台上看不到这台 AP 的任何注册记录。AP 距离 AC 跨了三个网段，二层广播方式已经不可用。
原因：DHCP 服务器上 Option 60 和 Option 43 没有配置，或者格式错误。很多网工第一次配 Option 43 时直接填了 AC 的 IP 字符串，比如192.168.10.5，但 Aruba 要求的是十六进制编码，格式不对 AP 会直接忽略这个选项。
解决：确认 DHCP 服务器支持 Option 60/43 的可视化配置，如果不支持就要在 DHCP 配置里手工写。Option 60 的值为ArubaAP，注意大小写敏感。Option 43 用十六进制格式，先算 IP 的十六进制，192.168.10.5对应C0 A8 0A 05，前面加上长度字节0C，最终填0C C0 A8 0A 05。配完后在 AP 上用show ip dhcp client确认收到的 Option 值，能直接看到 AC 地址是否被正确下发。
5.3 本地转发 SSID 不通：交换机 Trunk 没放行业务 VLAN
现象：SSID 能搜索到，终端能关联上，也能拿到 IP 地址，但 ping 不通网关，上不了网。改成集中转发模式后问题消失，换回本地转发又复现。
原因：本地转发模式下，终端的数据包从 AP 出来后直接进入接入交换机的 trunk 口，这个 trunk 口只放行了 AP 管理 VLAN，业务 VLAN 没放行。AP 管理 VLAN 的流量没问题，所以 AP 能上线、能注册，但终端业务 VLAN 的帧在交换机口上被丢弃了。
解决：到接入交换机上检查连接 AP 的接口配置，把业务 VLAN 加到 trunk 的 allowed vlan 列表里。常见命令是switchport trunk allowed vlan add 30,40。同时确认该 trunk 口的 native VLAN 是 AP 管理 VLAN，避免 AP 自身的 CAPWAP 流量被打上错误的 VLAN 标签。这个坑在锐捷、华三设备上同样存在，排查思路一致，先查链路放行，再查 AC 配置。
5.4 漫游粘滞与信道重叠：RRM 参数和最低速率设置
现象：用户拿着终端在办公区走动，信号显示满格但网速极慢，或者明明已经走到另一个 AP 旁边，终端还连着远处的 AP，视频会议频繁卡顿。漫游切换时 ping 网关的丢包率超过 20%。
原因：射频资源管理（RRM）默认参数没有针对现场调优，相邻 AP 工作在相同信道，互相干扰。终端侧的漫游决策是由终端自己做的，它倾向于保持当前关联，不会主动切换，这在无线业界叫"粘滞客户端"。如果 AP 的最低数据速率设得太低，比如允许 1Mbps 速率接入，终端即使信号很差也认为链路可用，加剧粘滞。
解决：在 AC 上开启 802.11k/v 辅助漫游，让终端获得邻近 AP 信息并主动漫游。RRM 的信道分配改成自动，并设定信道宽度为 40MHz 而不是 80MHz，减少重叠干扰。AP group 的射频配置文件里把最低基本速率提到 12Mbps，低于这个速率的终端直接不予关联。做完这三个调整后，用show ap rf summary观察相邻 AP 的信道分布，确保同一区域信道不重复。漫游问题排查起来像玄学，但多数情况下是这几个参数没配合好。
5.5 从锐捷、华三迁过来的习惯：配置下发与组网逻辑差异
现象：老手用锐捷或华三的思路配 Aruba，结果 AP 上线了却无论如何都广播不出 SSID，或者在 AC 上改了配置但 AP 迟迟不生效。
原因：锐捷、华三的 AC 里，SSID 配置往往直接挂在 AP 或 AP 组下，修改后即时生效。Aruba 的配置链是 SSID Profile → Virtual AP Profile → AP Group，三层嵌套，改了任何一层都需要确认是否已应用到目标 AP group。另一个差异是 Aruba 默认不会把配置变更实时同步到已上线的 AP，需要执行保存配置并等待下发生效。
解决：把习惯调成"先看配置文件层级，再下发"。修改配置后执行write memory，并观察 AP 是否收到新配置，可以用show ap active对比 AP 的配置版本号。版本号没变化的，到 AP group 里确认 Virtual AP 是否挂载成功。这个差异不是谁好谁坏，纯粹是管理模型不同，花十分钟把 Aruba 的配置分层逻辑过一遍，后面能少折腾半天。
6. 验证与进阶：把漫游体验从"能上网"做成"可量化"
6.1 漫游验证方法：ping 网关与连续漫游的量化记录
配置全部落地后，不能只看 SSID 能连就说交付完成。无线项目验收至少要验证两个维度：覆盖连续性和漫游切换时间。我的做法是在办公区走廊用一台笔记本持续 ping 业务网关，同时在 AC 上开启 debug 日志，人推着推车从走廊一端走到另一端，强制终端完成两三次漫游切换。
漫游丢包的合格线通常在 1 到 2 个 ping 包，也就是切换瞬间 100 到 200 毫秒的卡顿。如果丢包超过这个范围，重点检查 802.11k/v 是否开启、邻区列表是否为空。show ap association能看到终端关联的 AP 和信号强度，配合 ping 记录，基本能定位是哪个 AP 覆盖存在盲区。现场验收报告里我固定附一张漫游测试表，记录每次切换前的 AP、切换后的 AP、丢包数，这份记录在项目回款和后续维保扯皮时特别有用。
6.2 抓包确认转发路径：本地转发和集中转发的报文区别
验收阶段还有一个容易被忽略的动作：确认数据真实走了预期路径。集中转发模式下，抓包看终端到网关的流量，会在 AC 的入接口和出接口都看到源目地址不变的数据包。本地转发模式下，AC 上只有控制报文，看不到终端业务流量。
show datapath session | match <terminal-ip> show datapath bridgeshow datapath session查看 AC 上是否有该终端的数据路径条目，如果走集中转发，这里能看到终端的双向流量计数；走本地转发则没有业务流条目。这个验证不用抓包工具也能做，现场几秒钟就能得出结论。
从那以后我每次交付 Aruba 项目都会把转发路径验证纳入标准动作，不光是看配置怎么写，还要确认流量真的按配置在走。漫游测试表、转发路径确认结果、AP 状态截图这三样东西拉齐，项目才算真正闭环。这份《Aruba-无线AP及AC配置.doc》里把这些验证步骤和命令都写了进去，照着做一遍，能少走很多弯路，希望帮到你。
本文还有配套的精品资源，点击获取
