Wireless Access

I'm having issues deleting a test VLAN as the system claims it is being referenced.

Yet you cannot see the reference for VLANs with show reference <...> so how am I supposed to find this exacrtly?

The VLAN does not exist in the root /md/ folder. In my production folder, it appears. Using show configuration effective detail, it confirms this.

The only reference in show configuration effective detail for my rogue VLAN, 3950 is the command "vlan 3950" and yet I can't remove it.

Any help? I am running 8.2.2.3. Has this bug been fixed in any later release?

Where did it say it is inherited from in the "...detail) output?

When I run it on the controller itself, it says

vlan 3950 # inherited from [/mm]

This is the same for the all the VLANs that were created there.

When I run it on the VMM cd'd into the folder in which the controller resides (Production_Main), it says:

vlan 3950 # local [/md/Production_Main]

Same as every other VLAN there.

I am sure you tried to remove it from Production_Main

Yep. I've run into this bug before, but I don't remember how it was resolved.

So for anyone else who runs into this, it's a bug that is currentlty still not fixed as of 8.4.x.x. Here's what you have to do to remove the stuck VLAN:

[a] can be the MD or the folder node to which to the MD belongs. Thank you to TAC engineering for this solution. I hope the bug is fixed soon.

1. restart profmgr:

(ArubaMM-152) [a] (config) #process restart profmgr
WARNING: Do you really want to restart process: profmgr (y/n): y
Restarting: profmgr
(ArubaMM-152) [a] (config) #
(ArubaMM-152) *[a] (config) #

2. delete generated crash file to save space

(ArubaMM-152) *[a] (config) #tar crash
(ArubaMM-152) [a] (config) #dir
rw-rr- 1 root root 71112 Apr 18 12:20 AUDITTRAIL-HISTORY.log
rw-rr- 1 root root 37804 Apr 18 12:20 AUDITTRAIL-LOGIN_OUT-HISTORY.log
lrwxrwxrwx 1 root root 14 Mar 17 2018 bios-info -> /tmp/bios-info
rw-rr- 1 root root 152 Apr 18 12:23 blimits
rw-rr- 1 root root 40 Apr 12 00:00 bmap
rw-rr- 1 root root 21921280 Apr 18 13:38 crash.tar ====>need to delete to save space
rw-rr- 1 root root 58 Apr 18 13:38 crash.tar_md5sum.txt ====> need to delete
rw-rr- 1 root root 24366 Mar 16 18:03 default.cfg
drwxr-xr-x 4 root root 4096 Mar 12 15:51 fieldCerts
rw-rr- 1 root root 18 Apr 18 12:22 mac_addr.cfg
rw-rr- 1 root root 14 Mar 12 11:51 peeripchange
rw-rr- 1 root root 45188 Apr 8 14:45 reboot_config_backup.tar.gz

(ArubaMM-152) [a] (config) #delete filename crash.tar
(ArubaMM-152) [a] (config) #delete filename crash.tar_md5sum.txt
(ArubaMM-152) [a] (config) #

3. remove vlan XXXX

(ArubaMM-152) [a] (config) #no vlan XXXX
(ArubaMM-152) ^[a] (config) #write memory

To tell the truth, restarting profmgr is a blunt force instrument that solves tons of problems, but it does not fix  the root issue, or collect enough information to file a bug.  

Tarring crash collects crash information, but just restarting profmgr does not generate enough information to initiate a bug. 

Understanding that the TAC Engineer wanted to solve your problem ASAP, I cannot question his solution, but it is not something that would allow us to identify the root issue and fix it in the future.

Long story short, I would not advocate end users restarting profmgr.

That's good to know, I had no idea that killing that process was such a hammer.

What TAC did say was that they are able to replicate this bug so hopefully Aruba engineering can figure out what's really going on with this. Is there anything you may want from me? I took logs from the MM and MD before doing any of this while the problem was still present.

Do you want my TAC Case#?

Since I am in a lab environment, it was easy. I removed all the tree below MN and reboot the MM and the MC.