Showing results for 
Search instead for 
Did you mean: 

Can vlan 1 be explicitly tagged on a WLAN?

New Contributor II

When my network was initially set, our internal network was set up on VLAN 1. The ruckus was configured on VLAN 10 (no management interface). I now want to set up a WLAN directly on VLAN 1 so I can use the DHCP server there and my wireless clients can be on the same subnet. Now, on, I wasn't even allowed to set the VLAN field to 1. Yesterday I upgraded to I can now set a 1 there, but it seems to be the default and I still seem to be on VLAN 10 as that is where the DHCP server that is giving me an IP address resides.

Other Configuration info:
1) Ruckus Zone Director is on VLAN 10. No management interface is configured.
2) DHCP server is disabled, I've been using independent DHCP servers on each VLAN
3) Switch config for access points are untagged VLAN 10 and tagged everything else
4) Switch config for zone director is tagged everything, although I have tried untagged for VLAN 1.

As I've had no issues setting up WLANs on other VLANs, I'm wondering if there's something special about VLAN 1? Should my internal network not be there? Did I miss something in the user guide? Is there some other setting in the Ruckus somewhere I need to change? Did I just make a boneheaded error several times?

I think my next step is to see if I can do this via dynamic VLANs as I do intend to use RADIUS there anyway.

New Contributor III
For what it's worth, I'd STRONGLY reccomend staying away from VLAN 1. We've had many long nights of problems with it. Even when traffic seems to be flowing normally, you'll have all sorts of odd problems like DHCP breaking, different behaviors between Cisco and HP, etc....

Not worth the drama, easier to change it up front,...

And yes, tagging/trunking mean very different things in HP & Cisco worlds. A trunk in Cisco networks is a link with multiple VLANs traversing it. In HP land it is a bundle of links acting as one for bandwidth purposes.


New Contributor II
Thanks for the suggestion. In the future I am definitely going to go that route.

It appears everything is working as I want it to now, although I do need to do a lot more testing. My "trunks" are simply ports with all VLANs tagged except for the native VLAN (1), which is untagged. I also discovered that you can change the "primary" (native) VLAN via the command line interface in HP switches, that could prove useful in the future. Most of my troubles stemmed from some confusion about what I read and my Ruckus' initial config - it wasn't properly off of the native VLAN. I had someone else set up the Ruckus for me so I wasn't terribly familiar with how it worked until I started reading the manual, posting here, and spoke with Bittu on the phone.

But had I known how many hours I was going to put into this in advance, I probably would have moved my data VLAN off of the primary/vlan 1, which I had considered doing before I started. After several hours went into it I got stubborn and wanted to get it working as is 🙂

New Contributor II
We go through the same procedure Bittu outlined above on *every* install, which is a bit time consuming. Since we also use a VLAN for network management, say 10 for arguments sake:
1. Plug in fresh ZoneDirector on switchport with VLAN 10 *untagged* (HP) or *native* (Cisco)
2. Configure ZoneDirector, change VLAN to 10.
3. Reconfigure switchport to VLAN 10 *tagged* or move ZoneDirector to apprpriately tagged switchport.
4. Configure the "Access Point Policy" to use VLAN 10 for management.

For access points, similar procedure:
1. Plug in access point on switchport with VLAN 10 *untagged*.
2. After the access point is accepted and configured, it will disconnect.
3. Wait an appropriate amount of time before connecting the access point to a tagged port *or* tagging the port it is connected to. (This step is a bit hair raising because you lose visibility once the access point resets for the first time, and you don't know what it's doing, especially if you're doing a deployment with remote hands without central staging.)
4. If you manage to get the timing right and you don't disconnect the access point in the middle of a firmware update, congratulations, the AP should be online.
5. Rinse and repeat 1-4 a few hundred times. :-)

I am sure there would be an easier way to do this using RADIUS, NAC, and GVRP but since we do a lot of small to medium sized networks (10 - 250 APs) it is not something that we have really investigated.

Is there an easier way?

New Contributor III
We find it much easier to leave the zone director and AP's using untagged managment traffic and just tag the wireless client traffic.

So if VLAN 10 is the management VLAN:
We set up the switch ports for the AP and the zone director to be untagged (Default vlan) 10. Then we allow the tagged traffic for the Wifi client vlans onto the AP ports.

So setup looks like this: (paraprasing from above)
1. Plug in fresh ZoneDirector on switchport with VLAN 10 *untagged* (HP) or *native* (Cisco)
2. Configure ZoneDirector IP address but leave VLAN (from zone director's perspective) to VLAN 1 (ie untagged)

For access points, similar procedure:
1. Plug in access point on switchport with VLAN 10 *untagged*.
2. AP boots up, pulls DHCP for IP addres, uses DNS to find zone director.
3. Add ZP to zone director.
4. assign WLANs' to AP
5. allow tagged traffic for VLANs across AP ports.

New Contributor
I know this is old but I just found this thread because I was having the same issue. I walked into a client where they used vlan 1 for production because it was easy and they didn't know any better. Now, I'm implementing a management vlan & a guest vlan and the client doesn't want me to move production off vlan 1.

The issue here is that the ZD "assumes" that if the access vlan is set to 1 then it's untagged/native. Ruckus software doesn't provide a method of saying "I want vlan 1 tagged" or "I want to use vlan 10 and I want it untagged".

So, if this is your scenario:
vlan 1: production and will be used for trusted client Wifi
vlan 10: Management vlan since vlan 1 is already taken
vlan 20: Guest vlan

You end up with this configuration:

WLAN Production: vlan 1.
- Switch ports for APs will need this vlan untagged/native(pvid).
- On ZD, WLAN Access Vlan set to 1.

WLAN Guest: vlan 20:
- Switch ports for APs will need this vlan tagged.
- On ZD, WLAN Access Vlan set to 20.

AP Management: vlan 10.
- Switch ports for APs & ZD will need to have this vlan tagged.
- On ZD, Access Point configuration will need to stipulate Access Vlan as 10.
- Zone Director Device IP Setting has Access Vlan set to 10.

Hope this helps anyone else running across this.