APs do not preserve a new profile upon restart

[Tiago_Juliano_F]

Hello! I need to migrate APs from one native Vlan to another (from VLAN 1 to 10). I make the settings for Wing 5.8 by creating a new profile (ap-7532-new) and setting the VLAN settings. Everything seems to work, the AP adopts the correct IP but when it restarts it goes back to the previous profile (default-ap3572).

I make sure I commit and save but still do not maintain the new Profile settings.

Procedures:

- I created the new profile in Configuration-Profiles
- I set Ethernet Ports and Virtual Lan for my scenario
- In the specific Device I set the Profile

Did I forget something?

[ckelly]

Those configs/images look correct.

Question though: You need to finalize the whole VLAN-1 vs VLAN-911 part.
Are both of these VLAN IDs used for the same purpose? (management VLAN?)

If yes, then what I would recommend is getting rid of one of them. Whichever one remains, make sure that the ge1 configuration continues to look like it does for the VLAN-911 setup in your screenshot.
So...you could just delete the VLAN-1 entry from the 'Virtual Interfaces section'...and also remove it from the Allowed VLANs list in the trunk port setup in the 'Ethernet Ports' section.

[Tiago_Juliano_F]

This is the configuration of the Ethernet Ports

Have I set the DHCP settings on Vlan911?

[ckelly]

That looks correct for the 'Virtual Interfaces' section.
Are both VLAN-1 and VLAN-911 untagged? If so, you should only need 1 of those VLAN-IDs if being used as the management VLAN.

Next you need to make sure that whichever untagged VLAN you are going to use is included in the 'Ethernet Ports' section as part of the trunk port setup.

[Tiago_Juliano_F]

Is this setting correct given that I need APs to have the IP address for Vlan911?

[ckelly]

Okay....so that is expected if you have the statement "ip dhcp client request options all" for more than 1 VLAN. Thinking more about it now, you can name your untagged VLAN entry whatever ID you want. Won't matter, except that you need to include it in your ge1 switchport entry.

Since this is an untagged VLAN, you can/should be able to get away with just having VLAN-1 defined like this: (Ideally this should be populated in the AP Profile, not in the override section - although it would work there too)
interface vlan 1
ip address dhcp
ip dhcp client request options all


*****STOP***** Just remembered something that might explain all of this!
When you create a *NEW* Profile on a controller for an AP, it does NOT have a built-in VLAN-1 entry (an untagged VLAN entry). All of those default AP profiles on the controller? If you look at those, you'll see under the interfaces section that they all have VLAN-1 entries already there setup as DHCP clients.
But...when you create a NEW Profile, it doesn't auto-populate a VLAN-1 entry. (Not sure why, but I find it really irritating)

So for the new AP Profile, make sure there's an entry for VLAN-1 (or whatever VLAN-ID you want to use for your native untagged VLAN) that looks like this in the CLI:
interface vlan 1
ip address dhcp
ip dhcp client request options all <-- This should only exist on 1 VLAN entry

Then make sure that this VLAN-ID is included on the ge1 trunk port setup:
Something like:

interface ge1
description "Uplink Radios"
switchport mode trunk
switchport trunk native vlan 911 <--or whatever VLAN-ID you used above
no switchport trunk native tagged
switchport trunk allowed vlan 1,10,20,911 <--include appropriate VLANs

I've run into this several times myself because I forget I need to add it when building new AP Profiles.
IF this is the problem, then what is happening is the AP gets the new config. There's no untagged VLAN entry so does't get a DHCP lease. AP cannot communicate via layer-3 on the network any longer. AP can't reach the controller. AP then gives up after several tries and then auto-reverts to last previous working config.

--------------------
So, if VLAN-1 is getting a 'good' IP address, then you SHOULD be able to also PING the controller from the AP while it has the NEW config. This would be part of the tests I mentioned that you could perform if you had an AP that you could console connect to after it receives its NEW config (before it reverts back - only have a couple of minutes before that happens!)
Or...if you can't setup a test AP and console into it, the next best thing would be to QUICKLY learn the APs new IP address after you push out the new config...and from there, you can run some tests from the controller's CLI (see if the AP shows up as a MiNT neighbor, see if you can MiNT-PING the AP, see if you can MiNT-connect to the AP from the controller, etc)