问题描述：

客户的AP型号是AP32x/31x， 版本是 6.4.4.16 或者 6.4.4.0-wave2，所以无法注册到AOS 8.10.x的控制器上。但是之前这些AP32x/31x曾经注册到AOS8.6.x的控制器上，由于公司办公楼宇的迁移，这些AP32x/31x从老的控制器集群（8.6.x）挪到了新的控制器集群（8.10.x）上使用，中间经过了下线并被按压了factory reset按钮后被重置出厂值，然后在新的AOS8.10.x控制器集群上注册，发现MD上看到AP32x/31x的状态就是 Upgrading-Down,  Upgrading-Down   一直循环重复，AP32x/31x始终无法完成UP状态并释放信号。

这些AP32x/31x在被按factory reset 按钮之前，都是 8.6版本，且已经在控制器集群上使用过。由于这些AP32x/31x在老的控制器集群中有过配置，所以就有了环境变量nodelist 参数，且这些AP32X/31X已经从老的控制器集群下线了，为了能够在新的控制器集群中上线，必须要将AP Flash中的环境变量nodelist参数进行清空，才能通过DHCP Option 43 /ADP/DNS aruba-master 来发现控制器。

AP32X/31X被按factory reset 按钮（或者apboot 下 ，clear os）出厂重置后，会将第二个分区加载为running image，即AP会使用第二个分区镜像Flash（Provisioning/Backup）image，而此时第二分区镜像版本为 6.4.4.16 或者6.4.4.0-wave2. 采用该版本启动的AP32X/31X 无法和控制器下载新的版本AOS8.10.x，无法将8.10.x镜像文件下载到AP本地的第一个分区Flash（Production）中。

原因分析：

请注意，Aruba早期发布的AP32X/31X硬件，如果AOS版本在（版本是 6.4.x或者更早的），当升级到AOS8.10.x镜像时，会遇到固件文件大小限制问题，请需要将系统先升级到8.5.x或者8.6.x的版本,接着再升级到目标系统版本。经过验证，具体的结果如下：

• 1) AP32X/31X 从 6.4.4.0-wave2 或 6.4.4.16 或更早的版本无法直接升级到 8.10.x (含 8.10.0.15)
• 2) AP32X/31X 从 6.4.4.0-wave2 可直接升级到6.5.4.24/8.5.x（含8.5.0.14），但无法直接升级到 8.6.x（含8.6.0.18）
• 3) AP32X/31X 从 6.4.4.16 可直接升级到6.5.4.24或8.5.x （含8.5.0.14）或 8.6.x（含8.6.0.18）
• 4) AP32X/31X 从6.5.4.24或8.3.0.18-8.9.x   可直接升级到8.10.x （含 8.10.0.15）

另外早期AP32X/31X在出厂时，默认的第二分区镜像Flash（Provisioning/Backup）image 版本很多是 6.4.4.0-wave2 或者是 6.4.4.16, 通过CLI：show ap image version可以查看AP 两个分区的镜像版本。

控制器曾经过了几个中间版本的升级后，最终升级到了AOS8.10.x,都是很顺利的升级，但是无论你的控制器升级到哪个版本，你的AP32X/31X正常情况下是不会将第二个分区镜像Flash（Provisioning/Backup）image进行升级的，它只会将第一个分区Flash（Production）image升级到和控制器相同版本。

而当这些AP32X/31X 被 factory reset（通过apboot下的CLI or 按钮方式）或者 apboot下的clear os后，第一个分区Flash（Production）image镜像会被清空，那么AP32X/31X在启动时会加载第二分区镜像Flash（Provisioning/Backup）image 到Running Image， 此时就采用镜像版本6.4.4.0-wave2 或者6.4.4.16工作，那么在该版本下就无法升级到8.10.x，即无法下载8.10.x镜像到AP的第一个分区，AP启动信息中会提示下面的错误：

Checking image @ 0x0
Invalid image format version: 0x0
Checking image @ 0x2000000
Copying image from 0x44000000

Image is signed; verifying checksum... passed
Signer Cert OK
Policy Cert OK
RSA signature verified. 
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] 
[    0.000000] Aruba Networks
[    0.000000] ArubaOS Version 6.4.4.0-wave2 (build 49847 / label #49847) 
[    0.000000] Built by p4build@cyprus on 2015-04-30 at 14:49:32 PDT (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) )
[    0.000000] CPU: ARMv7 Processor [512f04d0] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine: Qualcomm Atheros AP148 reference board
[    0.000000] Flash variant: default
[    0.000000] msm_reserve_memory: 0x44600000, 0x200000
[    0.000000] memory pool 3 (start 5fc00000 size 400000) initialized
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] smem_find(137, 80): wrong size 72
[    0.000000] socinfo_init: v6, id=204, ver=2.0, raw_id=2313, raw_ver=2313, hw_plat=0,  hw_plat_ver=65536
============
[   85.299125] br0 address=a8:bd:27:cd:21:9c
[   85.299125] wifi1: AP type AP-325, radio 1, max_bssids 16
[   85.299343] Init the PCAP for radio1 offload 1.
[   85.307403] Initializing Pktlogs for 11ac
[   85.307435] Initializing Pktlogs for 11ac
AP rebooted Wed Dec 31 16:02:13 PST 1969; SAPD: Reboot after image upgrade failed: 65280
=========

解决办法：

针对客户的问题，根据场景不同，解决方法也有所不同。

场景1：

客户在现有的控制器集群下升级，帮助客户在升级前就做好规划方案，当前的AP32X/31X仍然注册在老版本的控制器上，需要将现有的控制器升级到目标版本AOS8.10.x，此时我们可以设计下面的方法，帮助客户平滑地升级到目标版本。

1. 步骤1：检查下当前控制器的版本，如果是6.5.4.24或8.3.0.18-8.9.x 的或者最新的，那么可以将此控制器直接升级到AOS8.10.x.
   • 如果是在6.4.4.x的或更早的版本，那么不可以直接升级到AOS8.10.x，推荐先升级到8.5.0.14，接着再升级到8.10.x。
2. 步骤2：采用标准的AOS升级步骤，对Aruba控制器的镜像分区进行升级，升级步骤请参考官方的AOS release note。
3. 步骤3：升级完成后，现有的AP32X/31X的第一个分区Flash（Production）image镜像会和控制器同步版本，并升级到AOS8.10.x，由于当前的AP32X/31X的第二个分区镜像Flash（Provisioning/Backup）image 版本仍然是老版本（例如6.4.4.0-wave2 或者6.4.4.16），如果后期需要清空nodelist参数或者其他原因，需要对该AP32X/31X做factory reset（通过apboot下的CLI or 按钮方式）后，那么该AP32X/31X就会采用第二个分区的镜像启动，从而无法和AOS 8.10.x的控制器完成版本同步，又变成最初的Upgrading-Down,  Upgrading-Down   一直循环重复的状态。
4. 步骤4：推荐客户在最终升级到AOS8.10.x后，在AP32x/31x被factory reset之前，我们需要在每台md控制器上（需要mdc到md控制器，并不是Mobility Conductor上）输入下面的CLI

#apflash ap31x-ap32x backup partition

将现有的AP32X/31X的第二个分区镜像升级到和当前控制器相同版本，最后再通过CLI：show ap image version 来确认。

注意：

1. 无论是CAP还是RAP部署模式下，只要使用下面的版本，你才可以使用CLI:apflash ap31x-ap32x backup partition来更新AP32x/31x的第二个分区的镜像版本

• ArubaOS 6.5.4.24 or higher
• ArubaOS 8.6.0.19 or higher （CAP 可以是ArubaOS 8.6.0.17）
• ArubaOS 8.7.1.10 or higher
• ArubaOS 8.10.0.4 or higher
• ArubaOS 8.5.x.x                        Upgrade to  ArubaOS 8.6.0.19 or higher
• ArubaOS 8.8.x.x and 8.9.x.x    Upgrade to ArubaOS 8.10.0.4 or higher 

因此，我们推荐你在AOS 8.10.x下，完成CLI:apflash ap31x-ap32x backup partition配置，将AP32x/31x的第二个分区镜像尽快升级到最新版本，从而避免了被出厂重置后无法注册的问题。

2. 该CLI仅仅更新AP的第二分区，最大同时更新5颗AP32x/31x,如果AP数量多的话，请耐心等待，直到确认所有AP的第二分区镜像都更新完成。该操作对控制器和AP都不需要硬重启，但是为了保证业务的可靠性，请尽可能在运维窗口期来操作。
3. 该CLI仅针对AP32x和AP31x系列AP且受影响的第二个分区镜像版本是6.4.4.X的任何版本，（第二个分区镜像是6.5.x的不受影响），其他的型号AP不会被更新第二个分区镜像。更新的状态可以监控的，通过CLI：show ap database，所有的AP32x/31x的状态提示 upgrading。
4. 原则上要求Mobility Conductor和Mobility Controller处于相同的AOS版本下，如果版本不同，那么必须相差在两个修订版本内，且Mobility Conductor是最新的。

除了批量地将AP31x/32x的第二个分区镜像升级到和控制器版本相同外，那么其他的AP型号，如何将第二个分区镜像进行升级呢？ 具体步骤请参考 https://arubase.club/archives/5336 如果你的环境下，AP能够发现控制器且注册成功，那么我们需要手动地对其他AP型号进行操作，直接电脑连接AP Console 口，进入到apboot状态下输入（前提是AP能够发现控制器且注册成功）：

先查看下当前AP型号的启动镜像文件名：

apboot> printenv 
bootdelay=2
baudrate=9600
autoload=n
boardname=Octomore
servername=aruba-master
bootcmd=boot ap
autostart=yes
bootfile=ipq806x.ari      (AP325的启动镜像文件名，存放在控制器上)
mtdids=nand0=nand0
ethaddr=b4:5d:50:c6:93:4c
ethact=eth0
name=b4:5d:50:c6:93:4c
a_antenna=0
g_antenna=0
usb_type=0
…………

apboot> upgrade os 1 ipq806x.ari   //将新版本镜像导入到AP的第二个分区镜像

AP的两个分区分别对应OS 0 和OS 1， 目前还没有发现其他AP型号的第二个分区镜像版本需要批量升级（主要是6.4.4.x的版本），如果大家想要升级，可以手动操作。

场景2：

客户需要将现有的AP32x/31x从老的控制器集群迁移的另外一个新版本控制器集群，当前AP32x/31x仍然在老控制器集群上是在线的，新控制器集群的目标版本是8.10.x，此时我们可以设计下面的方法，帮助客户平滑地迁移到目标版本集群。

1. 步骤1：检查下当前控制器集群的版本，如果是6.5.4.24或8.3.0.18-8.9.x 的或者最新的，那么现有的AP32x/31x可以直接迁移到AOS8.10.x的集群.

如果是在6.4.4.x的或更早的版本（其他型号AP如果也是该版本，可能也会受到影响），那么不可以直接迁移到新的AOS8.10.x集群，推荐先升级到8.5.0.14，接着再迁移到8.10.x。

2. 步骤2：在老的控制器集群上，AP32x/31x还在线时（当然其他的AP型号也参考该配置步骤），我们需要批量地对AP进行provision配置操作，可以是GUI 图形化或 CLI命令行 （推荐GUI操作，有关CLI的操作方式，本文不再描述，可以联系原厂SE沟通）。

原因：此时由于新集群的控制器版本不同于现有集群，所以考虑到AP启动时会优先考虑环境变量nodelist参数（该参数存储在AP Flash中，即使硬重启，仍然存在），该环境变量参数要优先于静态或者DHCP option43的，那么我们就不能采用Apmove或更改DHCP option 43 或者更改ap system-profile中的LMS来迁移集群，因为一旦AP注册到新的集群，先更新OS版本接着重启（此时还没有拿到新集群的配置），在AP重启后又会以nodelist参数来发现控制器，而此时的nodelist仍然使用的是老集群的node ip，所以AP又重新注册到老集群下，再次同步版本后重启，启动后获取老集群的配置，又回到了老集群。 如果是采用的是LMS配置，就会导致AP在两个集群间来回的更新OS，来回注册，总是无法上线成功。

步骤2-1 在AP Provision页面，我们需要批量勾选相同型号的AP32x/31x（当前其他型号也是同样操作），点击Provision按钮，进入到配置页面 （此方法可以批量地更改AP配置）

步骤2-2  将Controller discovery设置为 Static，将Controller IP/DNS Name 设置为x.x.x.x (即新控制器集群的vrrp ip，也就是用于AP上线的DHCP option 43 IP )，点击Submit 保存，并将MCR配置推送给MC后，AP会批量重启。

步骤2-3  一旦AP被provision且重新设置了静态的Master IP，那么当前AP的环境变量nodelist参数也会被同时清空，当AP注册到新集群并下载新的OS版本，再次重启后，AP会采用静态的Master IP来发现控制器（因为AP 发现控制器的优先级是 静态>DHCP option 43 >ADP>DNS aruba-master，此时的AP环境变量nodelist参数已经被清空了）， 等AP注册成功并同步配置后，就会拿到新集群的nodelist 参数，写入到AP Flash中。

此时的AP如果再次重启，那么会优先使用环境变量nodelist 参数来发现控制器，而静态设置的Masert IP优先级降低。

如果客户希望以后还是会用到DHCP option 43 ，那么再次批量地对AP进行provision配置，将Controller discovery 再次更改回 Use AP discovery protocol（ADP） 即可。

场景3：

客户需要将现有的AP32x/31x从老的控制器集群迁移的新版本控制器集群，当前AP32x/31x已经下线了，且物理位置上已经迁移到新的办公楼有线网络，且在新办公楼里AP都已经吊顶安装完成。新控制器集群目标版本是8.10.x，此时我们可以设计下面的方法，帮助客户平滑地迁移到目标版本。

1. 步骤1：检查下当前控制器的版本，如果是6.5.4.24或8.3.0.18-8.9.x 的或者最新的，那么现有的AP32x/31x直接迁移到AOS8.10.x的集群。

如果是在6.4.4.x的或更早的版本（其他型号AP如果也是该版本，可能也会受到影响），那么不可以直接迁移到AOS8.10.x，推荐先升级到8.5.0.14，接着再迁移到8.10.x。

2. 步骤2：在老的控制器集群上，AP32x/31x还在线时（当然其他的AP型号也参考该配置步骤），会获得环境变量nodelist参数，且该参数会保存在AP Flash中，即使重启也不会被清除（如果老的控制器不是集群配置，请忽略该步骤。）。现在所有的AP都已经在新办公楼 吊顶安装好，全部再次拆下和一颗一颗重新配置也不现实，因为之前集群的环境变量nodelist参数仍然会存在AP Flash中，那么我们推荐一个变通的方法：

• 因为AP Flash中环境变量nodelist一直存在，我们需要让AP能够重新注册到控制器上，可以部署一台虚拟控制器（即VMC，版本推荐8.5.0.14，单台即可，部署模式standalone），VMC的controller ip设置和老集群中的一台MC一样，DHCP option 43 指向该VMC的controller ip，等AP重新加电并注册到VMC后，会先下载版本，重启后并重新同步配置，此时由于Standalone模式会清除AP原有的环境变量nodelist参数，即使之后AP再次重启，但是我们还有DHCP option 43 保证AP能够继续注册到VMC上，我们需要在VMC上等待所有的AP都下载好镜像版本。
• 当VMC上看到所有AP版本更新好且都up成功后，我们就可以变更DHCP option 43 指向新的控制器集群，然后在VMC上重启所有AP，那么AP重启后，又再次经过DHCP options 43 就注册到新的控制器集群，AP下载镜像后再次重启，仍然采用DHCP option 43 注册到新的控制器集群，接着就会同步新的配置，获得新的环境变量nodelist参数.此时就可以下线VMC控制器了。
• 该方法可以大批量地对所有AP型号进行重新上线新集群，避免手动地，繁琐地卸下每颗AP来一个一个进入到AP Console 下去清空配置 purgeenv或者按压factory reset按钮，当然这些也是我们不想遇到的，尽可能去满足场景1和2 。

总结：

针对客户的控制器升级需求，目标版本是8.10.x，我们一定要提前介入到客户的升级方案设计中，尤其是遇到了AP型号是AP32x/31x,当然还有其他的AP型号，如果目前版本就是6.4.4.x或更早的版本，或者其他AP型号的第二个分区镜像Flash（Provisioning/Backup）image版本是6.4.4.x的或更早的，这些AP很可能无法注册到AOS 8.10.x的控制器上，请一定要提前规划客户的升级方案，按照上述的场景1 或者场景2来完成部署，否则一旦这些AP32x/31x 或者其他型号AP被factory reset按钮重置出厂后（或使用了apboot> clear os 或 apboot> factory_reset），将AP的第一个分区镜像给清空了，接着AP会使用第二个分区镜像来启动，那该AP就再也无法注册到AOS 8.10.x的控制器上了，这个并不是AP硬件问题，而是软件镜像版本升级问题，请大家参考和使用。