Network Management

Hi All,

I'm currently deploying a customer's AMP-8.0.9.2, with IAPs on v6.4.2.6-4.1.1.10_51810.

We're also using the Instant-GUI-Config in the groups.

And, we're using DHCP options to allow IAPs to discover AMP.

This is a two-part question.

1. I've configured "Automatic Authorization" in the AMP setup general settings, to add EVERYTHING (controllers, autonomous, thin-APs etc.) to a specific folder. My assumption was that this would (when a new Instant VC connects), move that VC straight into that group rather than putting it into the "New Devices" position. Should it do what I assumed? If not, what does it do? If it should do that, what might I have missed?

2. As I say, I'm using Instant-GUI-Config in the groups. In there (System>Admin), I needed to make the IAPs aware of the failover/backup AMP. I did that, and noted above that the Organization field is available too. I assumed that this is likely to be the same as that which you could configure in the DHCP options (or IAP GUI directly). In a follow-up test, I entered the same value in here as is contained in our DHCP options. Immediately, the IAP went "down" from AMPs perspective and never came back. The only way to get it back, was to factory reset it at the console port (it's on a desk next to me). Can anybody explain this? Is this normal? Why?

1. By default new IAP's that connects to an existing cluster will automatically be approved and won't show up as New Device. I'm usually using default settings here. Now - you are also saying that the devices are automatically moved to "a specific folder". Do you also try to move it to a specific group? My experience is that when you are using DHCP options you can not override the Organization settings used (Group or Group:Folder), so trying to force this for your IAP scenario through "Automatic Authorization" won't do you much good.

When using DHCP option 43 you do something like groupname:foldername:sub-foldername,amp-ip,amp-key . This can not be changed in Ariwave - you can only approve the VC as valid device.

Just so we're on the same page on this.. Group is Config Container - Folder is for security/reporting/logical placement.

2. Did you note the entries that popped up in the amp event log at this time? When doing factory reset you also ensure that it will show up as a new VC (due to new virtual-controller-key) and not be in conflict with old amp settings. But no - I can't explain/guess on what happened without more info ;)

I logged these with the TAC.

My wording was initially a bit poor, but in terms of the first query, you're right in that any new APs that join an existing VC automatically move to the group that VC is in, which is fine and what I expected. Let's forget folders completely for the minute. What I checked with the TAC was in specifically related to NEW VC behaviour. What they've told me, is that with auto-auth on, the new VCs should move to that group, but they don't. Note that to keep it simple, my auto-auth group is the one that matches the DHCP org string. TAC are investigating.

The second query is a suspected bug too, and since posting I've found it's worse that I first thought. Basically, if you put ANYTHING in the ORG, AMS IP or backup-AMS IP fields, the IAPs become completely unstable. Again TAC are investigating.

Just thought I'd finish this thread with a final post.

In terms of the auto-group-auth for totally new IAP-VCs moving to a "provisioning" group, it turns out that what is needed, is to leave at-least 1 VC in the auto-group at all times. I.e. the group aligned to the org-string the VC initially uses, must at all times have a VC in it. The VC that remains in that group at all times can be up-or-down. It simply acts as the "key holder" in terms of letting other VCs in. I left one in there, called "anchor", turned it off and put it in a cupboard in our case!

The second part of the query was indeed a bug. Resolved by upgrading to AMP 8.0.10.