Adoption of WiNG based wireless on untagged VLAN

[Eric_Burke]

I've got a site with about 150 WiNG based AP's. They adopt on V67 and as such, this is the default untagged vlan for each port they're connected to. For some reason, when I tell the AP's that this is V67 (as opposed to 1) in their profiles, they don't provision. So they think that the untagged port they're on in 1 when in fact it's 67. Why does this matter? We're implementing a new management platform and since it's pulling the AP configs and they don't mesh with the actual settings, it's messing up everything. Any thoughts as to why the AP's won't work when the profile says that their default vlan is 67 (bridging at the interface)? These are nearly all 4532 and 4522 devices.

[Eric_Burke]

Am I the only one who thinks it's odd that we picked v67?

[Shay_Weir]

Not at all.

[Eric_Burke]

Makes sense. I ended up changing the vlan definition (for V1) to not use DHCP for gateway/DNS. After doing so, and creating a new vlan definition (v67 with those options enabled), it grabbed an IP again. The controller and AP's are on the same native VLAN, just not the one they think (they think it's V1, it's actually v67). Again, was never a problem until I implemented our new mgmt platform and it got very confused.

[Shay_Weir]

Here is the controller profile. Hope this helps.... interface ge1 description Uplink switchport mode trunk switchport trunk native vlan 67 no switchport trunk native tagged switchport trunk allowed vlan 10,20,30,67...... channel-group 1 interface ge2 description Uplink switchport mode trunk switchport trunk native vlan 67 no switchport trunk native tagged switchport trunk allowed vlan 10,20,30,67...... channel-group 1 interface ge3 interface ge4 interface ge5 interface ge6 interface ge7 interface ge8 interface ge9 interface ge10 interface port-channel1 switchport mode trunk switchport trunk native vlan 67 no switchport trunk native tagged switchport trunk allowed vlan 10,20,30,67.... use event-system-policy