I noticed a strange issue this morning after configuration changes on our controllers that I had performed last night. I had upgraded the controllers from 6.1.3.1 to 6.1.3.7 and that had gone well. The controllers are three 3600’s in a master/local/local all in the same location with VRRP, no AP’s on the master but will fail to the master if a local goes down. We use the DNS method for an AP to find the master.
After the OS upgrade I wanted to move them out of vlan 1 (a project of mine to move away from that vlan). Each controller has an ip in vlan 1 and the vrrp addresses are also in vlan 1. I took these steps, never got far enough to actually change the IP of the controllers:
- I trunked our management vlan 880 to the controllers, adding it to the trunks from the switch side then building the vlan in the controllers via the gui and adding an IP to the vlan. I was then able to ping each controllers IP in vlan 880 from my pc.
- I then went into the redundancy section, shut down the VRRP state and changed their IP’s and brought them back up.
- Then I changed the AP system profiles to use the new VRRP address.
I was not having a lot of luck, AP’s were rebooting and one of the VRRP sessions were master on both sides. I decided to roll back some of the changes and discovered that I had accidentally made the IP address for the two VRRP’s the same on each local (they were correct on the master side) so I know that was the issue. Once I had rolled back the VRRP and AP system profiles to the old vlan 1 addresses, some of the AP’s would not connect. There were also some AP’s on the wrong controller (because of my mistake) so I rebooted the controllers again as a way to straighten it all out. This helped but I still had some AP’s that were not connecting so I rebooted the affected AP’s individually and that finally got all the AP’s back in order. One concern I had is that I did not have as many clients connected as when I had started, by more than I would have expected.
The next day I looked at “show user-table” and I found something that I had never seen before, the users I’ve listed below. There was many more but this is just an example.
Users
-----
IP MAC Name Role Age(d:h:m) Auth VPN link AP name Roaming Essid/Bssid/Phy Profile Forward mode Type
---------- ------------ ------ ---- ---------- ---- -------- ------- ------- --------------- ------- ------------ ----
10.8.0.9 00:17:59:45:b9:44 logon 00:00:02 tunnel 8 Wired default tunnel
10.8.192.25 00:60:16:35:df:dc logon 00:00:00 tunnel 8 Wired default tunnel
10.8.192.30 e4:1f:13:74:ea:b0 logon 00:00:07 tunnel 8 Wired default tunnel
These “users” were stuck in the logon role, and I don’t understand what the “tunnel 8” AP name is about, and the Wired under roaming. The last two IP’s are in the new management vlan that I had added, the first one is outside of that vlan and not one that is on the controllers. The MAC addresses and IP’s correspond to servers that we have. I did not understand what that was about, but I quickly removed vlan 880 from the switch trunks and disabled the vlan on the controllers. That fixed this issue. What might have caused this behavior?
Something that I had noticed while adding an IP to the new VLAN was that there is an option checked for all of the vlans, “enable inter-VLAN routing”. The controllers are not the gateway for any of our networks, just layer 2. They used to be however, for the wireless vlans. I’m wondering if this should not be checked and it is left over from that time? Could that have anything to do with what I saw?
#3600