Network Management

I had a network with several Aruba IAPs and they were connected to Airwave. This network spanned 2 buildings. I have since seperated the building into 2 different VLANs and now have essentially created 2 IAP clusters from 1. However now the IAPs in one of the building still tries to connect to Airwave as members of the original cluster. Is there a way to get those APs connected as their own cluster in Airwave?

We have had a similar issue and are currently working through a resolution for it.

In the interim, I would suggest that you factory default the IAPs (reset on back of IAPs) in one of your swarms and reconfigure them with the original config - see if that resolves the overlap in Airwave. You may need to delete the IAP's that you factory default, from Airwave too and allow Airwave to rediscover them.

If you decide to try this, let me know how this goes.

Cheers,

Jason

Thanks for the suggestion I'm trying to avoid resetting the APs for now as I don't want to take down my wireless system. I'm hoping another solution will come up otherwise I'll have to schedule some downtime. 

@nicksintros

What's the version of AMP you're running?

What's the firmware version on the IAPs?

Let's see if we have the same network design:

     We have 6 IAPs (A through F) on vlan 200.  IAP A is also the VC.

     This shows up in AMP as 7 devices, 6 IAPs, 1 VC.

     We want to split this cluster into two down the middle.

     We take IAP D, and convert it into a VC on vlan 300 and point it towards the AMP.

     AMP should now have 8 devices, 6 IAPs, 2 VCs.

     And 2 clusters -

          A (VC), A (IAP), B, C.

          D (VC), D (IAP), E, F.

At this point, the IAPs on VC D should update on their own to reflect the change having VC D as their controller.  This should happen regardless of folder and group.

Make sure you're on AMP version 7.5.x with VC/IAP firmware at least 6.1.3.x.  You should see the updates tracked in System -> Event Log.

@nicksintros

I believe that this issue is related to the GUID on the IAP.

Essentially, if you have a single swarm (lets assume 10 IAP's) then remove 5 of these to create a new swarm, if you did not factory default the first IAP connected, before all subsequent IAP's were connected into the new swarm, it will retain its original GUID that it received from the original single swarm.

As such, when discovered in Airwave, it will recognise this 'unique' GUID and associate all AP's with this GUID to a single folder.

This will not impact your on-site wireless (assuming that they are in different Layer 2 domains) and there will be no impact to the user experience. The issue is that you will not be able to effectively manage the two separate deployments.

The easiest way around this is to factory default one of your swarms, but note -  any resolution to this issue will require a reboot of one of your swarms - therefore an impact to service for the duration of the fix

If you have easy site access to one of your swarms, I would suggest that you turn off all the IAP's in one of the swarms only - with exception of the VC. You then have the option of either copying, editing and pushing this config back to the VC IAP or factory default - If site access is easy, I would suggest factory default of this VC device. Once rebooted, rebuild your configuration of this VC ( as prior to factory default) and then re-enable the remainder of the IAP's swarm.

Following this factory reset, a new GUID will be generated for this VC device and subsequently pushed out to all the other IAP's joining this swarm.

You will then be able to edit / correct the issue within Airwave as necessary.

Thanks,

Jason

I've initiated a process to have this tested and inspected more closely.  Will update once I have more information.