Header Only - DO NOT REMOVE - Extreme Networks

Adoption of WiNG based wireless on untagged VLAN


Userlevel 4
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.

14 replies

Userlevel 4
Try changing the AP switchport interface to: switchport trunk native vlan 67, switchport mode trunk
Userlevel 4
It's an EXOS x440, so the ports are set to "conf v67 add port n untagged" then two "tagged" for the BSSID vlan's.
Do you have your tagged and untagged vlans defined on ge1?
interface ge1 switchport mode trunk switchport trunk native vlan 67 no switchport trunk native tagged switchport trunk allowed vlan 5,6,7,8... [/code]Just to make sure, you're also assigning your management IP to vlan 67, correct?
interface vlan67
ip address dhcp[/code]or if you are using device overrides for static IPs, for each AP config:
interface vlan67 ip address [/code]
Userlevel 4
Hi Phil. Here's the config (done in via the controller UI, but seems to match [except for the wrong vlan]):

interface ge1
description "Trunk to local switch"
switchport mode trunk
switchport trunk native vlan 1
no switchport trunk native tagged
switchport trunk allowed vlan 1,60-68
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface vlan1
ip address dhcp
ip address zeroconf secondary
ip dhcp client request options all
Change "vlan1" to "vlan67"

interface ge1
description "Trunk to local switch"
switchport mode trunk
switchport trunk native vlan 67
no switchport trunk native tagged
switchport trunk allowed vlan 1,60-68
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface vlan67
ip address dhcp
ip address zeroconf secondary
ip dhcp client request options all[/code]I'd also look at removing vlan 1 from your "switchport trunk" under ge1 if you're not using it.
Userlevel 4
Understood. That's what I was originally saying in the post. If I set it to v67, it will not adopt. It's set to trunk, as we're bridging at the ge1 interface so I assumed that was/is correct...
Userlevel 4
This is what we have and it works great... interface ge1 switchport mode trunk switchport trunk native vlan 67 no switchport trunk native tagged switchport trunk allowed vlan 10,20,30,67,...... no lldp receive no lldp transmit interface vlan1 shutdown interface vlan67 ip address dhcp ip dhcp client request options all
Ah, I see now. The root of the issue appears to be your APs are unable communicate with a controller using MiNT on VLAN 67, but can on VLAN 1. I'd start drilling down into the wired network at this point.

Is the controller local or remote? If local, is the controller's native VLAN also 67? If it's remote, is port 24576 allowed for VLAN 67?

What DHCP options are you pushing to the APs?

Is the AP getting a valid DHCP address on VLAN 67? Can you access the AP via SSH over VLAN 67?

Things like that.
Userlevel 4
I'm so confused... 🙂 There is a "vlan1" virtual interface set for DHCP. I can't delete it, as when I try it says that it does not exist. As such, I can't create a vlan67 virtual interface using DHCP (only one can use DHCP I believe), so when I try to commit - it fails. The controller is also on V67 (untagged in the switch), but believes it's on V1 untagged too. Been this way for 3 yrs or more. All works fine except for the new mgmt tools (which think that the native Vlan for all of the AP's is the same as the LAN, which it's not).
Userlevel 4
The switchport and the GE1 interface need to have the same native vlan. "mint mclp vlan" should be enabled by default. If you add a controller host entry to point the AP to the IP address of the controller, then mint mlcp vlan should be disabled. AP communicates via IP instead of vlan to the controller. A more direct approach. Just a little more information to help.
Userlevel 4
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.
Userlevel 4
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
Userlevel 4
Am I the only one who thinks it's odd that we picked v67?
Userlevel 4
Eric Burke wrote:

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

Not at all.

Reply