virtual smartzone controller.

[tim_simmons]

victual SmartZone controller can you trunk a port on the controller to handle multiple vlans?  not finding much information on this.

Thanks

[eizens_putnins]

You don't need multiple VLANs on vSZ - it's just control plane, no client VLANs are needed there at all. You may use multiple VLANs on vSZ-D, which is separate VM to handle tunneled VLANs termination, if you use this feature. Otherwise this client VLANs must be present only on switch ports, to which APs are connected.

You probably had experience with legacy Cisco, HP or Aruba WiFi controllers, which used as a preferred tunneled mode. With  adoption of 802.11n standard, and later 802.11ac/ax tunneling traffic through controller became major bottleneck, and tunneled WiFi network design is used now  only when specifically required, which is not that often.

By the way, as Ruckus vSZ supports multiple dataplanes / traffic tunnel termination points (vSZ-D), completely separated from management servers, main drawback of this design is eliminated and it can be used when useful.

Currently very actual use is to provide convenient and secure office network access to home-workers...

[syamantakomer]

Hi Tim,

vSZ comes in two type of interface configuration.

• Single interface (vSZ-E and vSZ-H both supports it).
• Three interface. One for management, one for control and one for cluster (Only vSZ-H supports it).

In both the above interface type, you have to define interface on VM and this will not be a trunk port, as per my understanding.

So straight answer is, No, you cannot use vSZ interfaces as trunk and same is not supported.

May I know the use case for your requirement.

[tim_simmons]

thanks for the reply's the installer only has 1 nic online for the controller and our old cisco network is across 4 different vlans,  that are not all in the vswitch as the cisco was physical controller.  so having some traffic issues the controller see's the ap's but not pulling an ip for testing laptop.

Thanks,

Tim

[eizens_putnins]

This is exactly I described -- you have old Cisco controller, which terminates tunnels from APs. It means that APs don't have client VLANs (assigned to SSIDs), SSID traffic is tunneled from AP to controller (there is only management VLAN on AP ports), and controller is terminating tunnels, so all traffic is decrypted by controller and put on VLAN through it interface, which is a trunk. In this structure all traffic from all APs is transported through tunnels to WLC, and than moved from it to network, which makes controller the major bottleneck on network. For example if you have 50 APs, with just 50 MB/s traffic on each (and even 802.11n AP can move much more traffic than this, not speaking about 802.11ac) than you load  2x interfaces to 2.5GB/s each at least, and processing power on controller to match this.

Anyway, in your case you need to reconfigure switches -- make each port, to which AP is connected, trunk, with proper VLANs, and propagate this VLAN between this switches. 

If you really want to replicate same structure with tunneled VLANs, you can do it, but you need than to install vSZ-D VM or appliance, as tunnel termination part in vSZ is separated to avoid making bottleneck in the network. I would not use this architecture without specific reasons, as it is less scalable and efficient - it is outdated way to do it... Ruckus realization mitigates most scalability issues of tunneled mode, but it comes with a cost - you can get performance, but you need hardware and licenses for that (which includes also enough LAN capacity to move all traffic to controller and from it and interfaces to connect controller).

So if you just want tunneling mode to avoid configuring network, better think again and configure your network for local termination of traffic. It is not complicated, you just need implement client VLANs on switches, that's pretty straightforward  thing to do.