Network Management

Hi Guys,Take a look:

I notice something really strange in one of my small sites that using Instnat units (iAP-105) and i need your airheads assistance :)

• AMP™ 7.6.4
• All those ap's are on the same vc,same site.
• All those ap's are using ArubaInstant_Orion_6.2.1.0-3.4.0.1_39461   (from the 21/08/13)

As u can see the airwave written down that they all managed by INSTANT-CC:3F:00 , even due that the gray astriex in on 6c:f3:7f:cc:3e:6a (meaning he is the VC)

Antoher thing:

Even due I upgraded the firmware (and i can see on the ap units that the version is 6.2.1.0-3.4.0.1_39461- the Airwave still see those ap like they have:

6.2.1.0-3.3.0.2_38733 os... :(

please advise.

Thanks in advance.

Me

Does this behavior persist after an upgrade to the latest AirWave 7.7.4?  The reason I'm suggesting 7.7.4 is that 7.7.3 was the introduction of additional template support specific for IAP 3.4 code.

Yeah...upgrade to 7.7.4 as that's the official supported Airwave version for IAP 3.4.

"Instant-CC:3F:00" is AMP's desired name for the Virtual Controller.  It's what the VC's name was when it was first pointed at AirWave.  A common way to update that would be to update it on the VC's GUI under System -> General (if that hasn't happened already), then update it in AirWave by going to the VC's Manage page and clicking Import Settings.  

the import settings - dont fix it.

i wil try to upgrade my Airwave.

Thank u all for the tips/answers.

rgrds,

Me

Hi all,

today i finished all the upgarde process to 7.7.4 (like u guys told me to do )

and yet the issue is still hapnning (even after import settings) or deleteing all this group and reimporting it.

something is wrong with it.... and i must collect info - from that site.

please advise

thanks ,

me

Summarizing this thread, there's 2 items we're tracking right?

1. Firmware version of IAPs wasn't updating

2. Controller entry for APs

For part 1, is the firmware version still showing up incorrectly after the upgrade?  I didn't see a capture showing that column.

For part 2, I think we're confusing desired behavior.  The AP with the asterix '*' is the AP that's also acting as VC - we all agree on that.  The thing to know for instant deployments is that the VC AP gets 2 database entries.  One entry for the radios, and one entry for the VC (to maintain settings if/when another AP in the cluster has to takeover as VC).  Notice that if you mouseover the APs name, it will link you to the ID of the radios.  Then if you mouseover the asterix, it will link you to the ID of the VC (echoing the 2 database entry).  If you then mouseover the 'Instant-CC:3F:00' entry, it should match the ID of the asterix.  Keep in mind that the naming of the VC will match the initial AP that was acting as VC until the name is changed.  To do that, go to the VC entry's manage page and update the device name.

1. yes 6.2.1.0-3.4.0.1_39461

2.no it does not.. the astrix marking other ap..take a look:

(a completly diffrent ap - un related to the ap name... it's just not the VC :(    )

3.!!now im  facing a new issue - every few minutes the Airwave marking all this VC group as down - just by it look on the Airwave - the site itself keep running... :(  nothing changed except upgrade the AMP from 7.6.4 to 7.7.4 please advise

regarding the new issue (3) - everytime i delete this all group from airwave

and then add it back

it's shows as up and then going down (just by what Airwave 7.7.4 seeing) the site itself keep running and working..

Thanks for taking the time to show me what you're observing.  I'll try to replicate the usage behavior in the lab.

Item 1: firmware -> AirWave is reflecting correct current firmware

Item 2: VC name is reflective of the first AP that behaved as VC.  The name of the VC entry is embedded in the messages we receive from the VC.  To change, get VC into a good state with no mismatches, put into management mode, then update the VC's name from the VC manage page.  This will push out the new VC name.  The initial naming schema for a VC is that it becomes Instant-(last 3 octets of mac address).

Item 3: Let me know if you see the device reported as down again.  The message intervals were coming in every 2 minutes, so the change we made by updating the Group -> Basic -> Instant https timeout to be greater than 2 minutes should do the trick.

Yep.

(BTW: it's looks down agian :(  even with the 12 process + 5 min tweaks)

I would recommend opening a support case so one of our engineers can get a hands-on look at this.