Aruba Networks, Configuration Example
Migrate RAP from AOS 6.x to AOS 8.x
I guess something that many HPE Aruba wireless engineers have to do these days is migrating the “old” AOS 6.x environment to the new AOS 8.x with Mobility Masters. I am not going to explain what the differences between both are and what a Mobility Master does, but I have a tip when you need to migrate remote access points (RAPs).
Yesterday evening I had to perform a migration from 3 7030 controllers to a environment with redundant Mobility Masters. The solution contains 35 campus APs and 20 remote APs. The migration should be relatively simple…….
I installed the Mobility Masters, added the
I was able to add one controller to the Mobility Masters by distributing the APs in the 6.5 environment over the remaining 2 controllers. So the old environment had 2 controllers left, one for the campus APs and one for the RAPs. I wanted to migrate the campus APs first. Can’t be that difficult……. just provision the campus AP with the IP address of the AOS 8.4 controller and wait for the magic to happen. All campus AP came online, so I added the second controller to the Mobility Master.
Since I now have two controllers I started with the lc-cluster configuration. I configured the lc-cluster group-profile, added the two controllers, including the vrrp-ip and rap-public-ip, like shown below.
lc-cluster group-profile “lc-booches”
controller 10.1.1.1 priority 128 mcast-vlan 0 vrrp-ip 10.1.1.11 vrrp-vlan 1 group 0 rap-public-ip 22.214.171.124
controller 10.1.1.2 priority 128 mcast-vlan 0 vrrp-ip 10.1.1.12 vrrp-vlan 1 group 0 rap-public-ip 126.96.36.199
Only two more steps left to add the RAPs:
- Add the correct NAT and firewall configuration to the firewall environment
- Add a LC-RAP-pool to the Mobility Master >> /mm level
BAM, ready to migrate the RAP. I converted the first by reprovision the AP in the old controller and configure the new public IP. Here we go!! You only need to wait and wait and wait and wait……. but the RAP didn’t come online!!! What can go wrong??
- Created a whitelist entry? – yes,
export / importand I see the entries via show whitelist- dbrap
a LC-RAP-pool? – yes, show lc-rap-pool on /mm level
- Correct LC-cluster config? – yes, rap-public-
ipis configured correctly
- Firewall config? – Config is correct. Firewall policy is matched and packet sniffer shows that packets are forwarded to
- Controller har
dware limit reached? No, there are currently 35 campusAPs and the limit of a 7030 is 64 APs
Time for some deeper troubleshooting. The RAPs gets stuck at the logon role in the user-table. Time for some crypto debugging. Lets get started with logging security process crypto level debugging to check if a VPN tunnel establishment.
Hhhhmmmm, there is a strange error message!!!
|ike| HMAC_SHA1_96 ESN_0 <– R Notify: INTERNAL_ADDRESS_FAILURE (ESP spi=ea87a200)#SEND 80
Seems like the RAP IP pool isn’t configured correctly. So double check, but the pool is definitely configured correctly. Okay, another test. One RAP is onsite, so factory default the RAP and convert it from scratch. SAME RESULT AND SAME ERROR message. Hhhhmmm, I am AMFX certificated, but can’t even get a RAP connected?!?!?! So it is time to ask another AMFX’er, my colleague Peter (AMFX#36). Luckily he was willing to power up his RAP and provision it to the customer’s environment.
Okay, let’s add the RAP to the whitelist, let Peter do the conversion magic from IAP to RAP and check what happens. BAM, RAP connects, updates software and is online……. Difference, other hardware. Our RAP is RAP303-H, the
So what is another difference…. THE WHITELIST. Our RAP was added manually after the configuration was completely done and wasn’t imported at the beginning. So let’s check the whitelist again and there it is!!!! I didn’t really check all columns from the show whitelist-db rap, but one of the columns on the right is called Cluster-InnerIP. The output below shows the column, normally there are even more columns, so you have to scroll to view the Cluster-InnerIP.
You notice that the manually added entry gets an IP address assigned from the LC-RAP-pool and all imported RAPs don’t get an IP address. This definitely reflexes the error INTERNAL_ADDRESS_FAILURE error message. The cert-type is changed to factory-cert after the RAP is converted and online.
So I removed one of the imported entries and added it again (manually) to the whitelist db and guess what. The Cluster-InnerIP is assigned to the RAP and the RAP connects directly and without any problem.
So in my opinion there could be two reasons why this issue arrises:
- I imported the whitelist-
dbto early,because I hadn’t configured the LC-RAP-pool yet;
- The import from 6.5 to 8.4 doesn’t work for RAP entries;
To be sure, I removed all entries from the whitelist
TIP of the WEEK: when migrating from 6.5 to 8.4 MANUALLY add the whitelist-
Or does someone have a better way to import the whitelist for remote APs?!?!?!
Latest posts by René Jorissen (see all)
- MacOS Big Sur and SSLKEYFILELOG - November 23, 2021
- ClearPass, Azure AD, SSO and Object ID - August 12, 2021
- ClearPass – custom MPSK - July 20, 2021
For us, to Get the 6.x RAPs to successfully migrate required the creation of a dedicated “migration” AP group that contains a Provisioning Profile under “Remote-AP” (on 6.x MM). In the Master IP-masterstr field enter the IP address of the Target 8.x Lead Controller. Then “whitelistdb RAP modify” the RAP to new migration AP group. Of course that RAP is already in 8.x whitelist-db..
I just exported my RAP Whitelist from my 7210 6.x controller into my 7210 8.x controller and my RAP worked fine. The brick wall I ran into was the RAP address pool not being deployed up at the MM level. I had it down in the Managed Network level. Great article though. Appreciate someone else being in the trenches and writing about it. Thanks!