APs do not preserve a new profile upon restart

  • 25 October 2018
  • 23 replies
  • 336 views

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?


23 replies

Userlevel 5
It sounds like the new Profile is successfully being pushed out to the APs, but then when the APs attempt to use the new Profile and realize that they can no longer re-adopt to the controller, they are automatically reverting back to their previous configuration. This is expected behavior.
You have some sort of problem with the new Profile/config that is preventing the APs from being able to re-adopt.
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Here the new profile settings:

profile ap7532 default-ap7532new
ip name-server 200.XXXXXX
ip name-server 200.XXXXXX
autoinstall configuration
autoinstall firmware
load-balancing balance-channel-loads 2.4ghz
crypto ikev1 policy ikev1-default
isakmp-proposal default encryption aes-256 group 2 hash sha
crypto ikev2 policy ikev2-default
isakmp-proposal default encryption aes-256 group 2 hash sha
crypto ipsec transform-set default esp-aes-256 esp-sha-hmac
crypto ikev1 remote-vpn
crypto ikev2 remote-vpn
crypto auto-ipsec-secure
crypto load-management
crypto remote-vpn-client
interface radio1

interface radio2
description Radio2
beacon dtim-period 1
antenna-gain 15.0
max-clients 100
interface ge1
description "Uplink Radios"
switchport mode trunk
switchport trunk native vlan 20
no switchport trunk native tagged
switchport trunk allowed vlan 1,10,20
interface vlan20
ip address dhcp
ip address zeroconf secondary
ip dhcp client request options all
interface pppoe1
use firewall-policy default
ip dns-server-forward
logging on
logging host XXX
controller host XXX pool 1 level 1
controller host XXX pool 1 level 1
no lldp med-tlv-select power-management
no configuration-persistence
no auto-learn staging-config
service pm sys-restart
router ospf
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Keep the same settings as the previous profile, setting only the interfaces
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
As far as I can see here, the AP should be getting a DHCP lease on VLAN-911.

So....if the AP is able to use VLAN-911 to MiNT connect to the controller using VLAN-911, then there shouldn't be a problem. This would mean that VLAN-911 is able to pass MiNT UDP port 24576 traffic all the way back to the controller (and back again in the other direction).

To continue testing, what would be the MOST helpful here is if you can connect to the AP remotely while it's connected. (SSH)
Are you able to find the IP address of the AP when it gets into the condition where it has lost its adoption? If so, we can verify a lot things and figure out where the breakdown is.
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
I was able to access the AP via SSH, even with the old settings.
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Sorry, got this mixed up with a different issue. I was basing my previous comments based on the AP losing its adoption after getting the new config.

So question....are there any custom settings in the AP's override section?
This is at the very bottom of the running-config and looks like:
ap7532 84-24-8D-86-76-42

At the VERY least, you should always see these entries in the override section:
ap7532 84-24-8D-86-76-50
use profile ap7532-default (or whatever profile name you assigned)
use rf-domain default (or whatever rfdomain you created and placed)
hostname ap7532-84-24-8D-86-76-50 (or whatever hostname you gave it)

So is there anything in this section besides these entries?

Next, what is the output of: show adoption status
If the AP is currently adopted, that will tell us how we want to proceed.
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
These are the settings with the new profile. But when he comes back to rest, all is lost:
ap7532 74-67-F7-03-33-F8
use profile default-ap7532new
use rf-domain default
hostname ap7532-PredioB-Inferior
interface ge1
switchport mode trunk
switchport trunk native vlan 911
no switchport trunk native tagged
switchport trunk allowed vlan 1,10,20,911
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
show adoption status
Adopted by:
Type : RFS6000
System Name : rfs01
MAC address : 5C-0E-8B-19-DB-D3
MiNT address : 0B.19.DB.D3
Time : 0 days 01:49:23 ago
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
[edit]
Just noticed something (was reading too fast)
For your native VLAN 911 - There's no configuration to specify that VLAN 911 should be a DHCP client.
What I would expect to see *somewhere* in your config is something like this:
interface vlan911
ip address dhcp
ip dhcp client request options all

Can you tell me if you see something like this somewhere in the running config of the **new** profile? If you don't, then it confirms the point that I am making below. (AP doesn't get an IP address on VLAN911, therefore it cannot adopt to the controller, then the AP reverts back to the previous config.

[Original Response]
So the AP is successfully adopted using the 'old' profile. My suspicions continue. I think that there's an issue with the new configuration that is being pushed out to the AP that is causing it to lose its ability to adopt to the controller. When this happens, the AP will give up after several failed tries and will used the most recent profile that allowed it to connect to the controller. It's a fail-safe feature.

We should be able to confirm this in the logs. Run these commands:
#show adoption log adoptee

and another just in case:
#show mint mlcp history

The output from these commands will confirm/deny if the AP has had issues adopting to the controller. What you want to do then is match up any of the failed adoptions in the log with the *time* that you pushed out the new config to the AP...this would show the correlation.
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
It did not work even by setting DHCP. The AP receives the IP in the new Vlan but when restart everything undoes.

show adoption log adoptee
2018-10-29 14:42:42:Received 0 hostnames through DHCP option 191
2018-10-29 14:41:37:Received 0 hostnames through DHCP option 191
2018-10-29 13:22:08:Received 0 hostnames through DHCP option 191
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:MLCP created VLAN link on VLAN 1, offer from 5C-0E-8B-19-DB-D3
2018-10-29 13:21:05:MLCP VLAN link already exists
2018-10-29 13:21:05:Sending MLCP Request to 5C-0E-8B-19-DB-D3 vlan 1
2018-10-29 13:21:05:Received 0 hostnames through DHCP option 191
2018-10-29 13:21:02:Received OK from cfgd, adoption complete to 0B.19.DB.D3
2018-10-29 13:21:00:Sending MLCP_DISCOVER to IP 172.16.15.1, UDP port 0
2018-10-29 13:21:00:Sending MLCP_DISCOVER to IP 172.16.15.2, UDP port 0
2018-10-29 13:20:59:Waiting for cfgd OK, adopter should be 0B.19.DB.D3
2018-10-29 13:20:59:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:59:Adoption state change: 'Adoption failed' to 'Connecting to adopter'
2018-10-29 13:20:59:Try to adopt to 0B.19.DB.D3 (cluster master 0B.19.DB.D3 in adopters)
2018-10-29 13:20:58:Adoption state change: 'Waiting for Adoption OK' to 'Adoption failed': redirected to 0B.19.DB.D3
2018-10-29 13:20:58:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:58:Adoption state change: 'Adoption failed' to 'Connecting to adopter'
2018-10-29 13:20:58:Try to adopt to 19.6E.2F.83 (cluster master 0B.19.DB.D3 not in adopters)
2018-10-29 13:20:57:Adoption state change: 'Waiting for Adoption OK' to 'Adoption failed': redirected to 0B.19.DB.D3
2018-10-29 13:20:57:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:57:Adoption state change: 'Adoption failed' to 'Connecting to adopter'
2018-10-29 13:20:57:Try to adopt to 19.6E.2F.83 (cluster master 0B.19.DB.D3 not in adopters)
2018-10-29 13:20:56:Adoption state change: 'Waiting for Adoption OK' to 'Adoption failed': redirected to 0B.19.DB.D3
2018-10-29 13:20:56:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:56:Adoption state change: 'No adopters found' to 'Connecting to adopter'
2018-10-29 13:20:56:Try to adopt to 19.6E.2F.83 (cluster master 0B.19.DB.D3 not in adopters)
2018-10-29 13:20:56:Got new value for MTU: 1500 Was: 0
2018-10-29 13:20:56:MLCP created VLAN link on VLAN 1, offer from 5C-0E-8B-19-DB-D3
2018-10-29 13:20:56:MLCP VLAN link already exists
2018-10-29 13:20:56:Sending MLCP Request to 5C-0E-8B-19-DB-D3 vlan 1
2018-10-29 13:20:55:Sending MLCP_DISCOVER to IP 172.16.15.1, UDP port 0
2018-10-29 13:20:55:Sending MLCP_DISCOVER to IP 172.16.15.2, UDP port 0
2018-10-29 13:20:50:Sending MLCP_DISCOVER to IP 172.16.15.1, UDP port 0
2018-10-29 13:20:50:Sending MLCP_DISCOVER to IP 172.16.15.2, UDP port 0
2018-10-29 13:20:50:Start MLCP IP Discover
2018-10-29 13:20:50:Clearing already existing ipsec secure config for MLCP group 0 candidate 172.16.15.2
2018-10-29 13:20:50:Clearing already existing ipsec secure config for MLCP group 0 candidate 172.16.15.1
2018-10-29 13:20:50:DNS resolution completed, starting MLCP
2018-10-29 13:20:50:Received 0 hostnames through DHCP option 191
2018-10-29 13:20:50:Adoption state change: 'Disabled' to 'No adopters found'
2018-10-29 13:20:50:DNS resolution completed, starting MLCP
2018-10-29 13:20:50:Adoption enabled due to configuration

show mint mlcp history
2018-10-29 14:42:42:Received 0 hostnames through DHCP option 191
2018-10-29 14:41:37:Received 0 hostnames through DHCP option 191
2018-10-29 13:22:08:Received 0 hostnames through DHCP option 191
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:Ignoring MLCP Offer, vlan_state MLCP_DONE != MLCP_DISCOVERING / MLCP_STP_WAITING
2018-10-29 13:21:05:MLCP created VLAN link on VLAN 1, offer from 5C-0E-8B-19-DB-D3
2018-10-29 13:21:05:MLCP VLAN link already exists
2018-10-29 13:21:05:Sending MLCP Request to 5C-0E-8B-19-DB-D3 vlan 1
2018-10-29 13:21:05:Received 0 hostnames through DHCP option 191
2018-10-29 13:21:02:Received OK from cfgd, adoption complete to 0B.19.DB.D3
2018-10-29 13:21:00:Sending MLCP_DISCOVER to IP 172.16.15.1, UDP port 0
2018-10-29 13:21:00:Sending MLCP_DISCOVER to IP 172.16.15.2, UDP port 0
2018-10-29 13:20:59:Waiting for cfgd OK, adopter should be 0B.19.DB.D3
2018-10-29 13:20:59:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:59:Adoption state change: 'Adoption failed' to 'Connecting to adopter'
2018-10-29 13:20:59:Try to adopt to 0B.19.DB.D3 (cluster master 0B.19.DB.D3 in adopters)
2018-10-29 13:20:58:Adoption state change: 'Waiting for Adoption OK' to 'Adoption failed': redirected to 0B.19.DB.D3
2018-10-29 13:20:58:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:58:Adoption state change: 'Adoption failed' to 'Connecting to adopter'
2018-10-29 13:20:58:Try to adopt to 19.6E.2F.83 (cluster master 0B.19.DB.D3 not in adopters)
2018-10-29 13:20:57:Adoption state change: 'Waiting for Adoption OK' to 'Adoption failed': redirected to 0B.19.DB.D3
2018-10-29 13:20:57:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:57:Adoption state change: 'Adoption failed' to 'Connecting to adopter'
2018-10-29 13:20:57:Try to adopt to 19.6E.2F.83 (cluster master 0B.19.DB.D3 not in adopters)
2018-10-29 13:20:56:Adoption state change: 'Waiting for Adoption OK' to 'Adoption failed': redirected to 0B.19.DB.D3
2018-10-29 13:20:56:Adoption state change: 'Connecting to adopter' to 'Waiting for Adoption OK'
2018-10-29 13:20:56:Adoption state change: 'No adopters found' to 'Connecting to adopter'
2018-10-29 13:20:56:Try to adopt to 19.6E.2F.83 (cluster master 0B.19.DB.D3 not in adopters)
2018-10-29 13:20:56:Got new value for MTU: 1500 Was: 0
2018-10-29 13:20:56:MLCP created VLAN link on VLAN 1, offer from 5C-0E-8B-19-DB-D3
2018-10-29 13:20:56:MLCP VLAN link already exists
2018-10-29 13:20:56:Sending MLCP Request to 5C-0E-8B-19-DB-D3 vlan 1
2018-10-29 13:20:55:Sending MLCP_DISCOVER to IP 172.16.15.1, UDP port 0
2018-10-29 13:20:55:Sending MLCP_DISCOVER to IP 172.16.15.2, UDP port 0
2018-10-29 13:20:50:Sending MLCP_DISCOVER to IP 172.16.15.1, UDP port 0
2018-10-29 13:20:50:Sending MLCP_DISCOVER to IP 172.16.15.2, UDP port 0
2018-10-29 13:20:50:Start MLCP IP Discover
2018-10-29 13:20:50:Clearing already existing ipsec secure config for MLCP group 0 candidate 172.16.15.2
2018-10-29 13:20:50:Clearing already existing ipsec secure config for MLCP group 0 candidate 172.16.15.1
2018-10-29 13:20:50:DNS resolution completed, starting MLCP
2018-10-29 13:20:50:Received 0 hostnames through DHCP option 191
2018-10-29 13:20:50:Adoption state change: 'Disabled' to 'No adopters found'
2018-10-29 13:20:50:DNS resolution completed, starting MLCP
2018-10-29 13:20:50:Adoption enabled due to configuration
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Based on the config and what I'm seeing here, you have a cluster of controllers (.15.1 and .15.2 ?)
Can you confirmed that the two controllers have successfully established a cluster?
#show cluster status
#show cluster members

Also, I don't *think* that the AP should be rebooting when it receives this new configuration (only when it gives up and reverts to previous config).
What is the status of the query on the AP:
#service show reboot-history

And to help to better see what is happening in the logs, run this on the AP:
#show mint neighbors

Sorry for requesting all the info. There's something here that I'm not seeing. In the end, this is GOING to be something simple. 🙂
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Thank you Chris!

show cluster status

Cluster Runtime Information
Protocol version : 1
Cluster operational state : active
AP license : 32
AAP license : 16
AP count : 0
AAP count : 46
Max AP adoption capacity : 256
Number of connected member(s): 1

show cluster members
------------------------------------------------------------------------------------------
HOSTNAME MEMBER-ID MAC MASTER OPERATIONAL-STATE LAST-SEEN
------------------------------------------------------------------------------------------
rfs01 0B.19.DB.D3 5C-0E-8B-19-DB-D3 True active self
rfs02* 19.6E.2F.83 B4-C7-99-6E-2F-83 False standby 00:01:35 ago


service show reboot-history

Configured size of reboot history is 50

Date & Time Event
=====================================================
Oct 29 16:18:43 2018 startup 5.8.6.9-003R
Oct 29 16:18:14 2018 shutdown (graceful:'reload' command issued from CLI (user: admin))
Oct 29 15:20:26 2018 startup 5.8.6.9-003R
Oct 29 13:19:56 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 26 13:34:25 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Oct 26 13:34:24 2018 startup 5.8.6.9-003R
Oct 26 11:33:56 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 26 14:16:54 2018 startup 5.8.6.9-003R
Oct 26 12:16:25 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 26 11:27:45 2018 startup 5.8.6.9-003R
Oct 26 11:27:16 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 25 16:26:22 2018 startup 5.8.6.9-003R
Oct 25 16:25:53 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 25 16:01:59 2018 startup 5.8.6.9-003R
Oct 25 16:01:29 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 25 15:53:21 2018 startup 5.8.6.9-003R
Oct 25 15:52:53 2018 shutdown (graceful:reload by user (user: admin @ rfs02))
Oct 25 13:32:21 2018 startup 5.8.6.9-003R
Oct 25 13:31:52 2018 shutdown (graceful:reload by user (user: admin @ rfs02))
Oct 25 11:47:09 2018 startup 5.8.6.9-003R
Oct 25 11:46:39 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 25 10:59:16 2018 startup 5.8.6.9-003R
Oct 25 10:58:47 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 25 12:16:49 2018 startup 5.8.6.9-003R
Oct 25 10:16:20 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 24 19:29:28 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Oct 24 19:29:27 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Oct 24 17:29:27 2018 startup 5.8.6.9-003R
Oct 24 17:28:58 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 24 17:14:37 2018 startup 5.8.6.9-003R
Oct 24 17:14:09 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Oct 24 16:59:50 2018 startup 5.8.6.9-003R
Oct 24 16:59:22 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Sep 03 11:50:29 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Sep 03 14:50:29 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Sep 03 14:50:29 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Sep 03 14:50:29 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Sep 03 14:50:29 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Sep 03 14:50:29 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Sep 03 14:50:29 2018 startup 5.8.6.9-003R
- - - shutdown (ungraceful:unexpected cold restart)
Sep 03 14:50:29 2018 startup 5.8.6.9-003R
Sep 03 11:50:01 2018 shutdown (graceful:reload by user (user: admin @ rfs01))
Sep 03 14:45:29 2018 startup 5.8.6.9-003R
Sep 03 14:45:01 2018 shutdown (graceful:Upgrade done, reloading... (user: system @ rfs01))
Jan 01 00:00:00 2015 startup 5.8.0.0-050R
- - - shutdown (ungraceful:unexpected cold restart)
Jan 01 00:00:00 2015 startup 5.8.0.0-050R
- - - shutdown (ungraceful:unexpected cold restart)
Jan 01 00:00:00 2015 startup 5.8.0.0-050R
- - - shutdown (ungraceful:unexpected cold restart)
Jan 01 00:00:00 2015 startup 5.8.0.0-050R
- - - shutdown (ungraceful:unexpected cold restart)
Jan 01 00:00:00 2015 startup 5.8.0.0-050R
- - - shutdown (ungraceful:unexpected cold restart)

show mint neighbors
46 mint neighbors of 75.03.33.F8:
0B.19.DB.D3 (rfs01) at level 1, 2 adjacencies, 2 UP adjacencies, best adjacency vlan-1
0B.E8.4B.04 (ap-Zootecnia2-Suinos) at level 1, best adjacency vlan-1
0B.E9.A1.C1 (ap-PredioB-Inferior) at level 1, best adjacency vlan-1
0B.E9.A2.21 (ap-Equoterapia) at level 1, best adjacency vlan-1
0B.E9.A7.C7 (ap-PredioB) at level 1, best adjacency vlan-1
0B.E9.A8.A5 (ap-ctAdm02) at level 1, best adjacency vlan-1
0B.E9.AB.07 (ap-Zootecnia1-Avicultura) at level 1, best adjacency vlan-1
0B.E9.AB.15 (ap-Cooperativa) at level 1, best adjacency vlan-1
0B.E9.AB.69 (ap-Garagem) at level 1, best adjacency vlan-1
0B.E9.AB.99 (ap-Pousada) at level 1, best adjacency vlan-1
0B.E9.AB.E1 (ap-Biblio) at level 1, best adjacency vlan-1
0B.E9.AC.05 (ap-Sala-Prof-Predio-Central) at level 1, best adjacency vlan-1
0B.E9.AC.09 (ap-LabFito) at level 1, best adjacency vlan-1
0B.F4.CE.30 (ap-Refeitorio) at level 1, best adjacency vlan-1
0B.F4.CE.3A (ap621-F4CE3A) at level 1, best adjacency vlan-1
0B.F4.CE.A4 (ap-Ginasio-Quadra) at level 1, best adjacency vlan-1
0B.F4.CE.B8 (ap-Zootecnia3-Bovinos1) at level 1, best adjacency vlan-1
0B.F4.CE.BE (ap-subsolo-biblio) at level 1, best adjacency vlan-1
0B.F4.CE.CC (ap-Agri2-CultAnuais) at level 1, best adjacency vlan-1
0B.F4.CE.DA (ap-Zootecnia3-Bovinos2) at level 1, best adjacency vlan-1
0B.F4.CE.FA (ap-Corredor-DEX-02) at level 1, best adjacency vlan-1
0B.F4.CE.FC (ap-aloj2) at level 1, best adjacency vlan-1
0B.F4.CF.00 (ap-Aloj3-Rad2) at level 1, best adjacency vlan-1
0B.F4.CF.12 (ap-Aloj1Rad2) at level 1, best adjacency vlan-1
0B.F4.CF.16 (ap-Corredor-DAE) at level 1, best adjacency vlan-1
0B.F4.CF.1E (ap-Aloj3Rad1) at level 1, best adjacency vlan-1
19.6E.2F.83 (rfs02) at level 1, best adjacency vlan-1
1A.41.B1.18 (ap-CorredorBiotecnologia) at level 1, best adjacency vlan-1
1A.41.B1.1A (ap-Agroindustria) at level 1, best adjacency vlan-1
1A.41.B2.5A (ap-AlojamentoFeminino) at level 1, best adjacency vlan-1
1A.41.B3.52 (ap-Mecanica) at level 1, best adjacency vlan-1
1A.42.02.F6 (ap-Agri1-Olericultura-novo) at level 1, best adjacency vlan-1
75.03.25.78 (ap7532-A13-Sup-Fundos) at level 1, best adjacency vlan-1
75.03.25.C0 (ap7532-A13-Inf-Centro) at level 1, best adjacency vlan-1
75.03.26.74 (ap7532-A13-Sup-Cenrto) at level 1, best adjacency vlan-1
75.03.33.DC (ap7532-SalaA104-PCentral) at level 1, best adjacency vlan-1
75.03.33.EC (ap7532-A13-Inf-Fundos) at level 1, best adjacency vlan-1
75.03.34.04 (ap7532-Auditorio-Central) at level 1, best adjacency vlan-1
75.03.34.14 (ap7532-SalaA102-PCentral) at level 1, best adjacency vlan-1
75.03.34.38 (ap7532-CTI) at level 1, best adjacency vlan-1
75.03.35.00 (ap7532-AlojamentoHorta) at level 1, best adjacency vlan-1
75.03.35.0C (ap7532-SaguaoTI-Sup) at level 1, best adjacency vlan-1
75.03.35.10 (ap7532-Auditorio-Adm) at level 1, best adjacency vlan-1
75.03.35.28 (ap7532-ArtesCultura) at level 1, best adjacency vlan-1
75.03.37.40 (ap7532-A13-Inf-Frente) at level 1, best adjacency vlan-1
75.03.3A.F8 (ap7532-A13-Sup-Frente) at level 1, best adjacency vlan-1
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Okay...first, cluster looks good!

This AP is seeing 44 other APs using VLAN-1 and seeing both rfs controllers using VLAN-1.

On the reboot history:
Looks like there were a number of reboots on the 25th and 26th (and 2 yesterday) (user 'admin' issued a reload to the AP). Was this due to something you were doing on those days?

So I'm wondering now about the whole migration to VLAN-911. Bottom line, is the controller cluster reachable by an AP that is on VLAN-911 ?

Also, I didn't really see anything regarding the configuration for VLAN-911 in the config. is this somewhere in the new config?
interface vlan911
ip address dhcp
ip dhcp client request options all

**I'm still thinking this is an issue where the AP is losing connection ability to the controller once it receives the new config push.
Do you have an AP that you could test with that you can plug in somewhere handy and be able to console connect to it? The thought hear would be to use that AP to push the NEW config to it...and then from the console connection you can verify things in the CLI. (IP address, MiNT connectivity to the controller, the config that it received looks correct, etc)
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Was this due to something you were doing on those days?
Yes! I set up a testing environment with this AP and have been trying to modify the native Vlan ever since.

Apparently the routing between Van911 and Vlan1 is OK since AP receives an IP in the range of Vlan911 when commit write.

Set this again

interface vlan911
ip address dhcp
ip dhcp client request options all

Now I connected the AP directly to a POE port on the Controller. I tried to redo the settings on the specific port (ge2) and had the following error:

commit write
% Error: Commit failed for the following reasons:

[device '5C-0E-8B-19-DB-D3'] Only one interface can be configured for ip dhcp client request options all.
[device 'B4-C7-99-6E-2F-83'] Only one interface can be configured for ip dhcp client request options all.
[device '5C-0E-8B-19-DB-D3'][] Only one interface can be configured for ip dhcp client request options all.
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
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)
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

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

Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
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.
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
This is the configuration of the Ethernet Ports



Have I set the DHCP settings on Vlan911?

Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
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.
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
OK! Is that all in the AP profile correct?

Yes, they are Vlan's for management. Currently the Management Vlan is 1 but I need to migrate the APs gradually to Vlan911. That is, in the controller I need to keep the APs in the old Vlan (Vlan1) and migrate gradually.
Userlevel 5
Hi Tiago,

Might we see both profiles (pre/post commit) and the device overrides?

Kind regards,
Tomasz
Normally, if you were going to be making changes in an AP Profile for only some subset of APs, you would either create an entirely new Profile those APs...or make the configuration changes as override settings (less preferable method unless it's small changes and only to a few APs - otherwise, it just creates too much keep up with from a management perspective)

Hypothetically, if this migration is simply to move APs from one untagged VLAN to a different untagged VLAN, then *no* changes should be necessary. What we're trying to figure out here though is WHY the changes you're making are creating the problem.

Try moving just one AP to use this new Profile and see what happens.
If it continues to behave as before, then we need to get access to the AP immediately after it receives the new config so you can run some queries to find out what is making it angry. First thing I would test after receiving the new Profile is to see if it's still able to see the controller using MiNT. If so, then none of this should be happening.
Userlevel 6
Hi Tiago,

always make sure you used commit write or Commit & save before WiNG device gets rebooted.

Commit only is not reboot-surviving as it is not writte into startup-config...

  • commit = running-config
  • commit write = startup-config
Also, make sure there is no version-mismatch - this would prevent mismatched AP from writing new config to its memory.

Regards,
Ondrej

Reply