Ruckus Wireless SmartZone Controller. What s New in Release 3.2

Transcription

1 Ruckus Wireless SmartZone Controller What s New in Release 3.2

2 Contents About This Document Introduction Channel Range Settings/Channel Blacklist MAC Authentication, Guest VLAN and Tunneling on Ethernet Port Load Balancing AP Tunnels Smart Licensing OAM Feature Improvements HTTPS Support in Walled Garden on 3 rd Party WISPr Gateway Log Framework Enhancements Active Directory/LDAP Support Virtual SmartZone Data Plane (vsz-d) vsz Supported Clouds Support Deployments Behind NAT Application Visibility and Controll (AVC) ChannelFly Enhancements AP Management VLAN Tagging Airtime Fairness WLAN Priority... 9

3 About This Document This document provides a high level overview of the different features and capabilities introduced in the 3.2 release of the SmartZone Controller platforms. This document will help you understand the context in which the features operate, the key highlights of the features, limitations and the benefits of the features to the WiFi service provider. This document does not intend to replace other documents that may address the technical specifications of the features and the interface specifications of the features. The sections that follow provide a quick overview of these features. For additional details, please refer to the SmartZone Controller Documentation Suite for Release 3.2.

4 1. Introduction This document provides a high-level overview of several key features that are introduced in the SmartZone (SZ) software release 3.2. For detailed descriptions of these features and configuration help, refer to the respective 3.2 documentation guides. The SZ release 3.2 is applicable to the Ruckus Wireless SmartCell Gateway 200, SmartZone 100, vsz-h, and vsz-e controller platforms. In this release, Ruckus Wireless introduced support for one new AP model (the T504) and the R710 mesh feature. For a complete list of supported access point models, refer to the SmartZone 3.2 Release Notes. 2. Channel Range Settings/Channel Blacklist This feature provides a selection of available channels for the 2.4GHz, 5GHz indoor and 5GHz outdoor APs at the AP, AP group, and zone level. Configuration can be done at GUI, CLI, and public API levels. When the US country code is selected, there will also be option for user to choose operating in the DFS channels. 3. MAC Authentication, Guest VLAN and Tunneling on Ethernet Port In some large hospitality network environments that our APs operate in, device authentication is required for all devices. Authentication will include both hotel and guest devices. The following are some of the typical use cases: In the case of non-client hotel devices (for example, printers, VoIP phones, etc.) that do not currently support the 802.1x supplicant functionality, use of the MAC address for authentication is required. For all client devices (for example, PCs), it is necessary to determine if the device is a hotel provisioned network device, franchise company device or a hotel guest s device. The LAN service provider will also need to utilize these components to determine if a device is a hotel associate s device, franchise company employee s device or a guest s device. Ruckus Wireless followed the procedure in this implementation to differentiate these authentications: o If it is a staff device, it will respond to the 802.1x challenge; o If it is a hotel device, it will be in the MAC database;

5 o And if it is a guest device, it will fail both authentication attempts and be placed in the default VLAN for guest access. Traffic tunneling from Ethernet ports to SZ controllers is also supported in this release. 4. Load Balancing AP Tunnels In previous deployments, customers have seen some data planes taking a lot more AP data tunnels than others were with a random distribution mechanism. In this release, Ruckus Wireless improved the SZ/AP load balancing mechanism to spread the AP GRE tunnels across all available data planes. Rebalancing data tunnels across the data planes is a user-triggered process, and the controller will calculate and decide which APs should be moved to another data plane. During the process, APs may need to recreate the GRE tunnel to another data plane, which may result in service interruptions for existing user sessions. 5. Smart Licensing Beginning with this release, Ruckus Wireless has changed the way that licenses are deployed and used on the SCG-200 controller. Adopting the same licensing methodology as other SZ controllers, the SCG-200 will now get licenses from the cloud based license server and users will be able to dynamically assign pooled licenses from the license server to any SCG-200 in his network to share the license usage, instead of having a node-fixed licensing mechanism, as in previous releases. As part of the overall licensing enhancement feature, users can now access the following useful statistics related to license server synchronization for the last 30 day period: number of successes, number of failures, and last 5 communication status results. Existing SCG-200 customers who want to upgrade to R3.2 will need to contact Ruckus Wireless Customer Support for a successful migration. 6. OAM Feature Improvements Backup syslog server: SZ controllers will now support two syslog servers in active/active or primary/backup modes. In active/active mode, the log files will be sent to both external log servers at the same time. In primary/backup mode, there is implementation inside SZ controller to detect the status of the primary syslog server and in case of failure to detect the remote server, the log files will be sent to the backup server configured on SZ. Client roaming in real-time tracing: This feature is implemented to provide the capability to trace a specific client as the client roams in real time from one AP to another without the need to manually search various logs. Triggered by a CLI command from a user, all logs in the system that contain the client MAC address

6 are extracted, sorted and shown on screen one page at a time. The extracted logs can then be exported to an external FTP server for post processing. AP reboot reason enhancements: The existing AP reboot reasons are categorized as Power Cycle, Kernel Panic, Watchdog Timeout, Reset Button, CLI and Application. With this feature, SZ events will be able to provide more information on why the AP rebooted: o If the AP was rebooted via the reset button or the CLI reset command o If the AP was unable to communicate with the SZ for some time and reboots (default is two hours). Added timestamp to root s shell history: Root bash history file with timestamp has been added to the shell history in the release. 7. HTTPS Support in Walled Garden on 3 rd Party WISPr Gateway This feature extends the current support of the Walled Garden SZ hotspot gateway function HTTPS passthrough on Ruckus Wireless APs to third party APs. This is a key component to monetizing hotspot networks installed with 3 rd party APs. With this feature, clients can reach HTTPS encrypted web pages via the Walled Garden feature on SZ. It also enables the hotspot operator to redirect users from a service portal to external https pages and allows access to critical encrypted pages, such as payment gateways and social logins, etc. 8. Log Framework Enhancements As part of overall log framework enhancement work, Ruckus Wireless is taking an approach to define and unify how events are logged across the system. A new process called Log Manager has been implemented that collects logs from all processes to centrally manage logs with mandatory defined fields across the board for easy analysis and debugging. 9. Active Directory/LDAP Support In addition to authentication with an AAA server, SZ now supports AD and LDAP-based authentication services. The purpose is to facilitate non-sim UE to authenticate with username and password against AD or LDAP server for WiFi access. The implementation supports EAP-TTLS, EAP-PEAP, PAP/CHAP authentications. PMIP calls for AD/LDAP-based authentication and authentication call via 3 rd party APs are also supported.

7 10. Virtual SmartZone Data Plane (vsz-d) Ruckus Wireless has introduced the initial vsz-d implementation in this release to offer customers more flexibility in deploying SZ dataplanes as needed in an NFV architecture aligned fashion. The key advantages of deploying vsz-d are to offer secure tunneling of user data traffic that encrypts payload traffic, maintain flat network topology, enable mobility across L2 subnets, support POS data traffic for PCI compliance, offer differentiated per site policy control & QoS, etc. Refer to the vsz-d Configuration Guide for more information. 11. vsz Supported Clouds vsz R3.2 now runs on Google Compute Engine (GCE) and Azure clouds. 12. Support Deployments Behind NAT Beginning R3.1.1, some Ruckus Wireless SZ controllers started to support deployment behind NAT scenarios with initial support for NAT configuration on the control plane, so that the SZ-100 and vsz-e can be deployed behind a NAT gateway. Since the DP NAT configuration is unsupported, it only works for APs in local breakout WLAN scenarios. In this release, Ruckus Wireless has enabled SCG-200 and vsz-h behind NAT deployment and further enhanced the solution to include data plane NAT deployment scenarios for all relevant platforms (i.e. SCG-200 DPs and SZ-100 DP). With this release, SZ controllers can be deployed behind NAT for tunneled WLANs as well. One scenario that is yet to be supported is APs outside of the NAT interface. In this situation, the control NAT IP address needs to be configured. However, the controller doesn t send the local and NAT IP address to the AP, it only sends the NAT IP address. Therefore, if the control NAT interface is configured (it can be left blank) when APs are deployed inside the NAT (on the same local interface as the controller), they will need to reach the controller via the outside NAT interface that is configured in the control NAT IP address. In this scenario, the NAT router will need a NAT hairpin that allows inside APs to go out and back in. 13. Application Visibility and Controll (AVC) Release 3.2 offers AVC capability on SZ-100 and vsz-e platforms. Users can enable/disable AVC per WLAN with denial policy settings and gain more insight information into the types of traffic that pass through the WiFi pipeline. On the controller GUI, among other functions, users can view the top 10 applications in pie chart or line chart formats and track the top 10 applications per client.

8 14. ChannelFly Enhancements ChannelFly (CF) is a Ruckus Wireless approach to dynamic channel management. It involves assessment across all available channels, keeps detailed statistical capacity data per channel, and uses statistics to predict when it is a good time to change the channel before making any decisions about channel changes. In this release, Ruckus Wireless enhanced the following areas to further improve the behavior: o Broadcast test frames are sent in background scan cycles on all off-channels o Off-channel capacity is estimated using access time from these test frames and is augmented to ChannelFly data o Continuous ongoing estimates from background scanning helps ChannelFly in picking up a better channel and avoids flip flopping of channels o Default Mean Time Between Change (MTBC) is set to 480 seconds o Start temperature is lowered to 17C (controls aggressiveness) from 25C o Temperature is preserved across reboots helping to prevent restarts, CF aggressive learning at each reboot 15. AP Management VLAN Tagging To cope with some customers network design challenges, Ruckus Wireless provides customers the flexibility to either keep or set their own AP management VLAN IDs. The VLAN can be configured at Zone, AP Group or AP levels. However, once the management VLANs are changed/configured on APs, the APs may get disconnected from the controller and necessary plans and steps need to be in place to reconnect those APs by the customers. 16. Airtime Fairness Having older, slower wireless devices on the network can slow down the wireless network. Airtime fairness helps ensure that wireless clients can transmit data at the highest possible speed. By design, WiFi is a shared medium, which means only one device per channel can transmit data. Because of this design, wireless clients on the same channel compete for the same limited bandwidth. The rates at which these competing wireless clients transmit data are not the same. Older, slower devices take relatively longer to transmit and receive data compared to newer, faster devices. This gives less airtime to faster devices and disproportionately longer times to slow transmitting devices. Similar behaviors in airtime can be observed if a device is farther away from an AP relative to other clients or if wireless interference exists. To improve the performance of wireless networks that have a mixture of both slow and fast wireless clients, Ruckus Wireless introduced the airtime fairness feature.

9 Airtime fairness prevents a wireless client from using more airtime than the allowed maximum, which is 4ms. It gives equal amounts of air time (instead of equal number of frames) to each wireless client, regardless of its theoretical data rate. This will ensure that slow clients do not starve fast clients by occupying more airtime. By default, this function is enabled and is not user-configurable. 17. WLAN Priority This feature enables an administrator to prioritize traffic for a particular WLAN. You can set the WLAN priority when you create or edit a WLAN. On a per-user basis, the Ruckus Wireless SmartCast QoS engine classifies and queues each packet into one of the four traffic classes voice, video, data, and background. Within each class, traffic belonging to higher priority WLANs will be delivered prior to traffic from lower priority WLANs using a weighted round-robin scheduling technique across users. Traffic is then queued for transmission over the air based on traffic class.