In this article, I will explains an issue with customer DHCP configuration (related to DNS Domain name) which can potentially cause AP connectivity issue with RUCKUS Cloud.

Symptoms

• If you hit this issue, AP may show online but as soon as you make any configuration changes on venue, AP, WLAN, it will result AP state changing to "Never contacted Cloud".

• AP will not show any new event, since the time of its last successful connection to Cloud.
  In some cases AP will also show in "Operational -  applying configuration" state on Cloud UI and will never complete applying configuration.

• AP will still serve clients with last known configuration (if AP was not rebooted).

How to troubleshoot?

• Run a capture on switch port where AP is connected and reboot the AP.
  Note: This will not help if AP is configured with static IP configuration.
• Check the uplink packet capture and analyze (look at the DHCP Offer frame) the DHCP packets for the DHCP process.
• You will see DHCP server sending DNS domain name information.

• When Domain Name is added to the DHCP and configured on AP, AP will append the AP-Cloud discovery URL which is device.ruckus.cloud to device.ruckus.cloud.xyz.com. Because of this change in Cloud URL, AP will not be able to reach the correct controller IP (usually DNS resolution will fail) and will eventually fail to connect to Cloud.
• In case domain specific URL (in this case "device.ruckus.cloud.xyz.com") has a valid DNS entry on customer/public DNS server, it will further result in connection failure as resulted IP address will not match with the correct Cloud controller IP address.
• You can also factory reset one AP and then SSH into it (with default credentials super/sp-admin), run below commands to confirm if AP is getting the DNS Domain name configuration from DHCP.
• Run and review the output of "get dns" command.
• Output when DNS Domain name is received from DHCP server.
  

  rkscli:
  rkscli: get dns
  Allow DNS from DHCP: Enabled
  Ethernet DNS servers:
  DNS 1 : 8.8.8.8
  DNS 2 : 8.8.4.4

  IPv6 DNS Setting

  DNS Domain
  <None>

  DNS Search List
  <None>
  OK

• Output when DNS Domain name is received from DHCP server

  rkscli:
  rkscli: get dns
  Allow DNS from DHCP: Enabled
  Ethernet DNS servers:
  DNS 1 : 8.8.8.8
  DNS 2 : 8.8.4.4

  IPv6 DNS Setting

  DNS Domain
  xyz.com

  DNS Search List
  <None>
  OK

Resolution

While issue is impacting RUCKUS APs, this is completely an issue caused by customer DNS and/or DHCP server configuration.

Follow below steps to fix the issue.

• Check and remove the domain name configuration from DHCP IP pool which is used for RUCKUS Access points.
• Just updating the configuration on DHCP server may not fix APs as APs will still hold old IP which has valid lease time. In this case you may reboot the AP so that AP can get the fresh IP lease from DHCP server without DNS domain name. Also clearing the IP lease from DHCP server can help.
• Even after rebooting or re-requesting IP from DHCP if issue is not solved, remove the AP from the Cloud and re-add.
• If you continue seeing issue even after fixing the DHCP configuration, please contact RUCKUS Support and report the issue.

I hope this will help!

Got any queries? Start the conversation!

As a Ruckus Technical Assistance Center (TAC) engineer, this knowledge article aims to provide guidance on assigning radio profiles to AP groups within the same venue in the RUCKUSOne platform. This specific tutorial addresses the scenario where a customer wishes to disable the 2.4GHz radio for a WLAN in one particular AP group while allowing clients to connect using both radios in other AP groups.

Customer Environment: The customer's setup comprises 128 APs organized into three AP groups. They seek to disable the 2.4GHz radio for a specific WLAN within one AP group, while maintaining functionality across both radios for the remaining AP groups.

Resolution: Below are the steps to configure radio profiles for WLANs across AP groups:

1. Navigate to the desired Venue within the RUCKUSOne platform.

2. Select the "Networks" tab.

3. Locate and click on the WLAN configured for the Guest network.

4. Within the WLAN settings, click on the highlighted "Radios" option.

5.Select "Specific AP groups" to customize radio settings for individual AP groups.

6. Choose the desired AP group where you wish to disable the 2.4GHz radio for the WLAN.

7. Toggle the radio options to enable or disable as per requirements for the selected AP group.

8. Click "Apply" to save the changes.

9. Hover over the "Radios" option of the specific WLAN to verify that the settings have been successfully applied to the chosen AP group.

Conclusion: By following the outlined steps, users can effectively manage radio profiles for WLANs across different AP groups within the RUCKUSOne platform. This capability allows for granular control over wireless network configurations, ensuring optimal performance and customization based on specific deployment requirements.

If you found this information helpful, please consider clicking on the "KUDOs" button to assist other users.

Regards,

Vasanth Edward || Snr TSE

RUCKUS Networks, CommScope!

The RUCKUS One team will be adding a new outbound http connection, http://ocsp.godaddy.com on March 27th, 2024. If you do not currently whitelist the outbound connections from your premises, you will not be impacted. If you do, please add this new entry to your existing outbound firewall rules before March 27th, 2024 or service will be impacted.

To allow RUCKUS One to function properly, please configure your firewall to allow for outbound connectivity according to the following guidelines:

Outbound HTTPS (TCP 443) from APs and Switches to:

https://ap-registrar.ruckuswireless.com

https://sw-registrar.ruckuswireless.com

https://ruckus.cloud

https://eu.ruckus.cloud

https://asia.ruckus.cloud

https://device.ruckus.cloud

https://device.eu.ruckus.cloud

https://device.asia.ruckus.cloud

https://storage.googleapis.com

Outbound HTTP (TCP 80) from APs and Switches to:

http://ocsp.godaddy.com (New!)

http://ocsp.comodoca.com

http://ocsp.entrust.net

Outbound SSH (TCP 22) from APs and Switches to:

device.ruckus.cloud

device.eu.ruckus.cloud

device.asia.ruckus.cloud    

Ensure you have a DNS server configured for your network infrastructure devices. DNS is required for the access points to resolve the RUCKUS One controller names to operate properly. 

Need help?

If you need help with products, please contact RUCKUS Technical Support via normal procedures referenced in the RUCKUS Support Portal.

Thank you for your continued support.

Regards,
RUCKUS Cloud Team

Where the highlight shows the firmware they are currently on,.

Now to update the firmware:
First, to set the version :
Hence
Administration [ bottom left corner ] >> version management >>>

Here go to , Switch firmware and select the venue >> and click on Change Update Schedule:

Once there the below dialog-box will appear:

Where we select the code that’s needed.

And generally the code available on the cloud is the recommended releases for the cloud connected devices or devices that would be connected to the cloud.

Here in this example : the devices are already on the recommended release : 10.0.10c_cd1

However for one of them : we'll be selecting 9010j_cd1 and setting the date and time for the activity as well

Here once the version is selected and saved,:

Once done, click on save,

Below will be displayed :

That’s for scheduling the code update,

In an event, there needs to be an immediate update done : update now is the option you need :

once the version are selected : click on run update : that will initiate the file transfer to the switches and get the update done.

Do note :

• This option is only applicable if the ICX switches are connected to the cloud.
• During this activity as usual  downtime is needed as the switches will reload for the firmware to be applied.
• Also this process/procedure applied to specific venue and all switches under the venue will get the update : hence do consider the below points

  if you are an MSP :

  1. Make sure that the switches that are to be updated are of the specific venue.

  2 . If there are multiple locations managed under the same venue  and only a specific location needs to be updated : then this may not be the best option to follow.

  3 . In case, point 2 applied to you : then device local updates are best way to go about the upgradation. Via TFTP,USB etc.

  if you are not an MSP, and there are multiple locations of install : but all are devices are under the same venue.
  Then device local updates are best way to go about the upgradation. Via TFTP,USB etc.

  If different locations are managed under different venues, there should be no issues in following this process/procedure.

Customer Environment

APs and Switches deployed behind a firewall and inbound/outbound traffic needs to be allowed for successful communication between RUCKUS network devices and RUCKUS One.

Symptoms

Newly added APs and switches are in Never Contacted Cloud state, not joining RUCKUS One.

Resolution

To allow RUCKUS One to function properly, please configure your firewall to allow for outbound connectivity according to the following guidelines:
 

Outbound HTTPS (TCP 443) from APs and Switches to:

https://ap-registrar.ruckuswireless.com
https://sw-registrar.ruckuswireless.com
https://ocsp.comodoca.com
https://ocsp.entrust.net
https://ruckus.cloud
https://eu.ruckus.cloud
https://asia.ruckus.cloud
https://device.ruckus.cloud
https://device.eu.ruckus.cloud
https://device.asia.ruckus.cloud
https://storage.googleapis.com
http://ocsp.godaddy.com

Outbound SSH (TCP 22) from APs and Switches to:

device.ruckus.cloud
device.eu.ruckus.cloud
device.asia.ruckus.cloud

Network Requirements

The following list of firewall ports is required to allow APs to enable Cloud discovery and continued connection with the Cloud

Checking the firewall ports is the first step of troubleshooting if an AP is unable to connect to the Cloud or disconnects from the Cloud.

https://docs.cloud.ruckuswireless.com/ruckusone/userguide/GUID-D00EA4CC-7B8A-4F99-969B-2A5FB5DDB178-low.png 

If these information helped you in any way, please click on "KUDOs", so you can help other users.

My ICX7150 switch failed with SYST amber light on. Tried updating primary, secondary and uboot. Post update when I do the reset, I continue to get the below message on the console. Pls help me.

[BrcdSoftlockup]: BUG: soft lockup - CPU#0 stuck for 89s! [mount:601]

        000066a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

We can see that even when the enable port is checked, we are unable to update the VLAN untagged ID on the cloud GUI.

Many customers have inquired about the inability of a certain AP model, such as the R350, to modify the untagged VLAN ID on the cloud.

This is the design objective for a single LAN port APs, as there is no VLAN given in the ethernet frame for untagged traffic.

For example, our AP on VLAN 1 will be able to communicate with any other side device on any untagged VLAN.

Any changes to the AP for the untagged VLAN ID that are necessary to get the AP onto the chosen subnet must be made at the switch port level where AP is connected.

I hope you find this information useful.

• Make sure that all switches and APs added on cloud should be operational.
• Make sure to whitelist below IPs/FQDNs on your firewall outbound rules:

1.            IP range: 34.87.82.64 through 34.87.82.95, ports: tcp 443 & 22
2.            FQDN: ap-registrar.ruckuswireless.com, port: tcp 443
3.            FQDN: sw-registrar.ruckuswireless.com, port: tcp 443
4.            FQDN: ocsp.comodoca.com, port: tcp 443 & 80
5.            FQDN: ocsp.entrust.net, port: tcp 443 & 80
6.            FQDN: device.asia.ruckus.cloud, port: tcp 443 & 22
7.            FQDN: storage.googleapis.com, port: tcp 443

Post migration connectivity checkpoints and troubleshooting before contacting Ruckus Support:

AP Troubleshooting:

• Connect laptop to a switch and same subnet as APs. Ping device.asia.ruckus.cloud, and please check if the resolved IP is in range: 34.87.82.64 through 34.87.82.95.

• If the resolved IP is outside the mentioned range (34.87.82.64 through 34.87.82.95), make sure to flush DNS cached entries from DNS server. Now try to resolve “device.asia.ruckus.cloud” and validate that IP resolution is within the specified IP range.

$ curl -XGET “https://device.asia.ruckus.cloud”

On MacOS, a success response would be:

curl: (56) LibreSSL SSL_read: LibreSSL/3.3.6: error:1404C45C:SSL routines:ST_OK:reason(1116), errno 0

On Windows PC, a success response would be:

     curl : (56) Send Failure: Connection was aborted

• Check reachability to https://device.asia.ruckus.cloud using the command below.

• Feel free to contact Ruckus Support, if all the troubleshooting steps are exhausted.

ICX Switch Troubleshooting:

• For Switches on version 9010e and 9010f kindly reboot the switches to clear DNS cached entries.

• Switches on version 9.0.10h_cd2 and 10.0.10b (for ICX 8200 switches) will not require a reboot to get connected to the new DC.

• Run “show sz status” from switch CLI and check SWR (Switch Registrar) IP has updated new IP range from 34.87.82.64 through 34.87.82.95.

• If the IP address is outside the above range run below commands:

1. device(config)# manager disable
2. device(config)# no manager disable
3. device# manager registrar-query-restart
4. device# show manager status

• Feel free to contact Ruckus support if above steps does not help.

Note that, switch disconnection from cloud doesn’t impact the production due to data center migration.

This is part of the symptom you will see in the AP support log:

Aug 19 17:58:11 clbd sta join XX:XX:XX:XX:XX:XX wlan3(YY:YY:YY:YY:YY:YY) 1 rssi=(25 42) 2g(0x0 4 31) 5g(0x0 4 13) 
Aug 19 17:58:12 clbd sta leave XX:XX:XX:XX:XX:XX wlan36(YY:YY:YY:YY:YY:YZ) rc=1 rss(20 0) 0 pkt(3588 12841) byte(498065 12750895) 
Aug 19 17:58:15 clbd sta join XX:XX:XX:XX:XX:XX wlan36(YY:YY:YY:YY:YY:YZ) 116 rssi=(11 22) 2g(0x0 4 29) 5g(0x0 4 12) 
Aug 19 17:58:16 clbd sta leave XX:XX:XX:XX:XX:XX wlan3(YY:YY:YY:YY:YY:YY) rc=1 rss(43 0) 0 pkt(1011 2437) byte(101751 2409641) 
Aug 19 17:58:20 clbd stamac=XX:XX:XX:XX:XX:XX bssid:YY:YY:YY:YY:YY:YZ score=0 oldstate:NONE newstate:GOOD

I tried ensuring that the airtime was decongested and free of interference, the RSSI was good, the SNR was good, and coverage for roaming was good. There weren't any notorious sources of interference, high retransmission rates, or physical errors in the APs.

For troubleshooting, I even enabled features like 'RSSI threshold' and 'Transient Client Management', but none of those were causing any difference in the constant and annoying disconnections.

So, I started to suspect more and more that there was an issue with those Apple devices, especially when there wasn't an obvious reason for this problem. I began to research within online forums and Apple support pages, an I found many people were complaining about this issue, but there wasn't an actual resolution or valuable comments from the Apple support team until I found this Apple support forum.

This is the workaround that worked for every customer I have suggested it:

In your iPhone:

1. Go to Settings, scroll down, and select 'Privacy and Security.'

2. Select 'Location Services' and make sure the toggle is switched on.

3. Scroll down and select 'System Services.'

4. Switch off the toggle for 'Networking and Wireless.'

5. Forget the Wi-Fi network and then reconnect.

After applying these steps in iPhones running iOS 16.1 the issue was solved immediately. However, the computers kept disconnecting. Then, an upgrade on the computers to the MacOS Ventura version 13.6, finally solved the disconnection issues for the MacBooks as well.

I hope this article is useful if you're experiencing similar issues.

• Ruckus One uses JSON Web Tokens (JWT) to secure all endpoints.
• POST method is used to obtain a jwt.
• The API response to POST call includes tenantId and token.
• Token is valid for 60 minutes.

POSTMAN:

• Postman is the tool used in this example to make an API call.
• API host URL will vary depending on Cloud/Ruckus One Region.
• Asia: https://api.asia.ruckus.cloud
• Europe: https://api.eu.ruckus.cloud
• North America: https://api.ruckus.cloud

1. Select the method as POST.
2. Enter the API host url for your region.
3. In the Body field- select raw and enter the payload.
4. Select format as JSON.
5. Click on Send button.

The response should be 200 ok and provides tenantId and jwt information as shown below.

Now Subsequent API calls must include JWT obtained as the Bearer token authorization.

Testing an API call:

• We are trying to retrieve venue details using an API call in below example.
• The required API can be found here: https://docs.ruckus.cloud/api/

1. Enter the url as “https://api.eu.ruckus.cloud/api/tenant/{tenantId}/venue”
2. Under Body select none.
3. Change method to GET.
4. Select Authorization type as Bearer token and Paste the JWT token obtained in previous API Call.

The response should be 200 ok and we can see the venue information as shown in below screenshot:

References: https://docs.ruckus.cloud/api/ 

Reason for getting the above error:

• The TI PoE chipset is different for the newly released/manufactured switches with 7150-48ZP Model.
• These PoE chipset work from version 8095k and above in 8095 major release and 9010h and above in 9010 major releases

Hence if you need the switches to operate with PoE then you will need to retain 8095k. If you want to add these switches to the cloud, you need to wait for 9010h release for TI PoE chipset to work.

If you try adding switches with TI PoE issue to cloud, you will encounter below error messages.

How to identify the 7150-48ZP switches have new PoE chipset:

Check the MCU details of the switch using “dm hwinfo” command. These are mostly 2023 batches of switches which have new TI PoE chipset.

ICX7150-48ZP Switch#dm hwinfo

HW Ver: 3.1 [Production-2], Main board CPLD Rev: 0.4.a

NAND Type: Micron NAND 2GiB (x 1)

Rear module card CPLD Rev: 0

Booted from: 1

Primary Uboot Failure Record: 0

Secondary Uboot Failure Record: 0

PoE hardware info:

+++++++++++++++++

Unit 1:PoE MCU: MSP430, PSE: TPS23881

Check for the PoE version and Hardware version using command “show PoE detail” when switch is on 8095k version, and you will see the below details.

Firmware

Version

----------------

01.56.1

Hardware

Version

----------------

V5R34

Device HW version         : 0:V5R34     1:V5R34     2:V5R34     3:V5R34     4:V5R34     5:V5R34     6:V5R34     7:V5R34    

Device Temperature(deg-C) : 0:32        1:36        2:34        3:30        4:30        5:26        6:34        7:30       

Device Status             : 0:Good      1:Good      2:Good      3:Good      4:Good      5:Good      6:Good      7:Good     

Below are the error details you will notice related to PoE if the switch is running on 9010 version.

Switch firmware version 9010f with new TI PoE chipset:

Firmware

Version

----------------

00.0.0

Hardware

Version

----------------

UNKNOWN

Device HW version         : 0:UNKNOWN   1:UNKNOWN   2:UNKNOWN   3:UNKNOWN   4:UNKNOWN   5:UNKNOWN   6:UNKNOWN   7:UNKNOWN  

Device Temperature(deg-C) : 0:0         1:0         2:0         3:0         4:0         5:0         6:0         7:0        

Device Status             : 0:Failed    1:Failed    2:Failed    3:Failed    4:Failed    5:Failed    6:Failed    7:Failed   

Log Size: 2000 entries.     Number of entries in use: 2  for unit 1.

Log printing is requested for complete log.

+-----+--------------------+-----+-----+---------+---------------------------------------------+

|S.No.|Timestamp           | Sys | Dev | Port    | Event Trace Message                         |

+-----+--------------------+-----+-----+---------+---------------------------------------------+

 1    | Fri Jun  9 06:53:54 |  N  | N/A | N/A     | PoE Event Log Mgr: User Req Logging On      

 2    | Fri Jun  9 06:54:47 |  Y  | N/A | N/A     | Loss of sync with controller in slot 1     

+-------+----------------+-----+-----+----------+---------------------------------------------+

After Rebooting the switch on 9010 version:

******* Starting HMON service for SNMPD *******

Jun 09 08:12:25:660838:info:fi_debug:debug_logs:1:4557112064: poeglue_i2c_read_boot: i2c read Failed:-4

Jun 09 08:12:25:970257:info:fi_debug:debug_logs:1:0: poeglue_proc_chassis_itc_msg: i2c write failed:-5

Jun 09 08:12:26:071219:info:fi_debug:debug_logs:1:15513810895616: poeglue_i2c_read: i2c read Failed:-4

Jun 09 08:12:26:812712:info:fi_debug:debug_logs:1:16312674812672: poeglue_i2c_read: i2c read Failed:-4

Jun 09 08:12:27:881837:info:fi_debug:debug_logs:1:17214617944832: poeglue_i2c_read: i2c read Failed:-4

Jun 09 08:12:29:029875:info:fi_debug:debug_logs:1:18099381207808: poeglue_i2c_read: i2c read Failed:-4

You will see above outputs for PoE on 9010f version.

Workaround:

• If you want to use switch model 7150-48ZP switch model with TI PoE chipset in cloud, then wait for 9010h version to have PoE feature and bring these switches up in cloud.
• If you don’t need the switch to be part of cloud and need PoE feature, then retain the switch in 8095k version.

Reference links:

TI PoE TSB referred:

• https://support.ruckuswireless.com/technical_support_bulletins/636

FTP uses TCP (Transmission Control Protocol) for data transmission, which provides error checking and correction, ensuring that the entire file is correctly received. This makes FTP more reliable and faster for transferring large files or over networks with high error rates.

Here is a quick guide to deploying an FTP server on your computer:

1. Download and install the Mobaxterm app.

2. Go to 'Network Services' and click the configuration gears for the FTP server.

3. Select the Folder for the file location and configure a username and password. I recommend disabling the option 'Prompt me before accepting any incoming connections' and enabling 'Allow anonymous connections'.

4. Click 'OK' and 'Start'. The server will start. It will also start a time countdown that will disable the FTP service once this gets to 0.

5. Your FTP server is ready for file transfers.

Mobaxterm is an amazing app with many tools that can help us on our daily tasks. Take a look at this KB so you learn how to use it for SNMP operations on your ICX switch.

AP WLAN oversubscribed

AP [AP-name@M:AC:AD:DR:ES:00] does not have enough capacity to deploy all WLANs. Only maximum WLAN number of the AP can be deployed.

These logs may be seen on the AP CLI:

Jul 13 21:30:50 HOME-R350 daemon.warn libapcfg[11330]: apcfg_set_wlan_cfg:10328 Can't find wlan slot index. Reach the maximum support number[8]. wlan id:[493].
Jul 13 21:30:50 HOME-R350 daemon.info libapcfg[11330]: @@114,apWlanOversubscribed,"apMac"="D4:BD:4F:01:D4:A0",

This is because Access Points (APs) have a finite number of SSIDs they can broadcast per radio band. This limit is specified in the datasheet of each AP model. For instance, consider the datasheet for the AP R350:

The AP R350 can only broadcast a total of 16 (user-configured) SSIDs. The total count of SSIDs includes those broadcasting on 2.4 GHz and 5 GHz bands separately. In other words, there are 8 SSID slots per radio band. This implies that if you have a WLAN named 'wlan-name' that's broadcasting on both radio bands (2.4 GHz and 5 GHz), it's utilizing two of the available SSID slots.

There are additional SSIDs reserved for other functions like mesh networking and recovery purposes. These SSIDs are not considered in the maximum SSID capacity.

You can verify the WLANs your AP is currently broadcasting by using the AP CLI command 'get wlanlist' to check the actual number of SSIDs broadcasting. But make no mistake, this command ONLY shows configured and enabled WLANs. There could be also configured and disabled WLANs occupying SSIDs slots.

Here is an example from the AP R350. This Access Point seems to be using using 4 of the available 8 slots for 5GHz SSIDs ('Internet', 'ruckus-pruebas', 'wlan1', 'wlan2'):

Yet, this AP is already oversubscribed. I can confirm that by checking the SSIDs in WLAN group assigned to this AP.

In the controller, I reviewed the WLAN group and confirmed it has got a total of 10 configured WLANs. 4 WLANs are enabled, 6 WLANs are disabled.

Resolution:

If you have confirmed your AP is actually oversubscribed, the recomendation is to reduce the number of SSIDs.

It could be possible that moving an AP between different AP Zones could trigger a false positive event, indicating that the AP is oversubscribed. If the actual number of configured WLANs is within the AP's capacity, it's recommended to reset the AP to its factory defaults to clear the false positive and let it onboard the controller again.

In Active Directory:

Create a user-group,

Create a user and add this user to the above user-group

The password used here will be mac-address of the client device. Password used here is 00c0caac2ef6

Right Click on the user created and add user to user group which is created at the beginning,

Click OK

Now in the Network Policy Server,

Step-1 >Create Radius Client (Select RADIUS Client >Right click >New)

Note:

The shared key used here needs to be same at the below highlight in WLAN configuration at Ruckus Cloud,

Step-2 > Policies > Network Policies (Right click > New)

Click Next and select the user group, then add group

Once the user group is selected, click OK and then add the NAS Port type

Once above are selected, click OK and then Next, select Access granted in Specify Access Permission

Click Next, and then select CHAP and PAP in Authentication methods,

Then Click Next till the end for the settings review and finish,

Once the user is authenticated, in the event viewer you should be able to see the Audit Success,

This article should be helpful when you need mac-authentication with more than 128mac address.

First of all, you need to get the JWT, reference: Ruckus Cloud API - Authentication Using JWT. Once the JWT has been obtained and configured as an Environment variable, you can start using the following APIs:

Create WLAN

1. Setup the API Call: 

2. Go to Authorization, select Bearer Token and set the JWT variable that it's in the Environment 

3. Go to Body, select raw and JSON format 

3.1. Then, copy and paste within the Body this template for a PSK network example

{
    "name": "PSK-API",
    "type": "psk",
    "wlan": {
        "wlanSecurity": "WPA2Personal",
        "advancedCustomization": {
            "userUplinkRateLimiting": 0,
            "userDownlinkRateLimiting": 0,
            "totalUplinkRateLimiting": 0,
            "totalDownlinkRateLimiting": 0,
            "maxClientsOnWlanPerRadio": 100,
            "enableBandBalancing": true,
            "clientIsolation": false,
            "clientIsolationOptions": {
                "autoVrrp": false
            },
            "hideSsid": false,
            "forceMobileDeviceDhcp": false,
            "clientLoadBalancingEnable": true,
            "directedThreshold": 5,
            "enableNeighborReport": true,
            "enableFastRoaming": false,
            "mobilityDomainId": 1,
            "radioCustomization": {
                "rfBandUsage": "BOTH",
                "bssMinimumPhyRate": "default",
                "phyTypeConstraint": "OFDM",
                "managementFrameMinimumPhyRate": "6"
            },
            "enableSyslog": false,
            "clientInactivityTimeout": 120,
            "accessControlEnable": false,
            "respectiveAccessControl": true,
            "applicationPolicyEnable": false,
            "l2AclEnable": false,
            "l3AclEnable": false,
            "wifiCallingEnabled": false,
            "proxyARP": false,
            "enableAirtimeDecongestion": false,
            "enableJoinRSSIThreshold": false,
            "joinRSSIThreshold": -85,
            "enableTransientClientManagement": false,
            "joinWaitTime": 30,
            "joinExpireTime": 300,
            "joinWaitThreshold": 10,
            "enableOptimizedConnectivityExperience": false,
            "broadcastProbeResponseDelay": 15,
            "rssiAssociationRejectionThreshold": -75,
            "enableAntiSpoofing": false,
            "enableArpRequestRateLimit": true,
            "arpRequestRateLimit": 15,
            "enableDhcpRequestRateLimit": true,
            "dhcpRequestRateLimit": 15,
            "dnsProxyEnabled": false
        },
        "macAddressAuthentication": false,
        "macAuthMacFormat": "UpperDash",
        "managementFrameProtection": "Disabled",
        "vlanId": 30,
        "ssid": "PSK-API",
        "enabled": true,
        "passphrase": "ruckus123"
    }
}

3.2. Click on Beautify to apply the JSON format to the template

4. Finally, click on Send to create the WLAN. To verify the results you can login into your Ruckus Cloud Portal and check the WLAN created, then select on which Venue(s) you need to broadcast it.

Note: From the documentation you can find the type of networks that can be created via API, just select the type, then copy and paste the payload and setup the paraments 

Export WLANs

1. Setup the API Call: 

2. Go to Authorization, select Bearer Token and set the JWT variable that it's in the Environment 

3. Click on Send to get the configuration (backup) from all your existing WLANs in Cloud.

Got questions? Start the conversation!

•POST /token is used to obtain a jwt.
•The response includes the tenantId and the token. The API-KEY field will always be null.
•The token expires after 60 minutes

When using Postman, subsequent API calls must use the Bearer Token authorization, using the jwt obtained previously.
In the below example, the jwt is saved in the {{JWT}} variable.

In Order to save the JWT as token, Create a new Environment and update the JWT token in initial value and current value. 

Step 1:

Click on “Venue “

Click on the Venue your switch is in. In this case the switch we are trying to access is in “My-Venue”

Step 2:

Click on “Configure” option in top left corner

Go to “Switch configuration” -> “AAA”

Go to Local User option. You can try to view the password and try using the same to login to the switch through SSH

If not, you can try adding a password using the “Add local User” option and wait for some time for the password to get pushed and can access the switch using the same password and user name through CLI and Cloud CLI option.

From Switch CLI: 

Ruckus-ICX login: super

Password:

Cloudtest>

Cloudtest>

Cloudtest> en

Switch Running config:

Cloudtest#show run | inc user

username super password .....

username test3 password .....

username admin password .....

username test1 password .....

username test password .....

username test2 password .....

username test4 password .....

Cloudtest#

To connect to console from Cloud, go to More Actions -> CLI session

Note:

• Ruckus Cloud assigns a username and password to the switch once it is managed by the Ruckus Cloud. Even if the switch is disconnected from the cloud, the switch username and password remain the same. The password can be obtained from the Ruckus Cloud GUI under the Venue’s ‘Switch Settings’.
• Also once the switch is up in cloud Web Access to the switch will be disabled as access to cloud using Web UI is available from Ruckus Cloud

• ICX 7150
• ICX 7550
• ICX 7650
• ICX 7850

Link reference:

• https://www.ruckusnetworks.com/cloud-supported-network-devices/
• https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GUID-0A09001F-FDA8-4151-96CC-A21208D55007.html

Devices used in Lab:

• Ruckus Cloud R1
• Switch model ICX7150-24P-4X10GR version 8095g

Step 1:

Add the switch details in the cloud as shown below

Go to Wired -> Switch list

Click on “Add” option in the top right corner

You will see the below options to add the switch

Step 2:

Add other details like. Serial number, Venue , Switch is standalone / Stack and switch name

Switch serial number can be identified from “Show version” output

show version

  Copyright (c) Ruckus Networks, Inc. All rights reserved.

    UNIT 1: compiled on Jan 31 2023 at 21:50:36 labeled as SPS09010e

      (29360128 bytes) from Primary SPS09010e.bin (UFI)

        SW: Version 09.0.10eT211

      Compressed Primary Boot Code size = 786944, Version:10.1.25T225 (mnz10125)

       Compiled on Mon Aug  8 11:58:28 2022

  HW: Stackable ICX7150-24-POE

==========================================================================

UNIT 1: SL 1: ICX7150-24P-4X10GR POE 24-port Management Module

      Serial  #:FEA3227P11R

      Software Package: BASE_SOFT_PACKAGE

      Current License: 4X10GR

      P-ASIC  0: type B160, rev 11  Chip BCM56160_B0

==========================================================================

UNIT 1: SL 2: ICX7150-2X1GC 2-port 2G Module

==========================================================================

UNIT 1: SL 3: ICX7150-4X10GF 4-port 40G Module

==========================================================================

 1000 MHz ARM processor ARMv7 88 MHz bus

    8 MB boot flash memory

    2 GB code flash memory

    1 GB DRAM

STACKID 1  system uptime is 11 hour(s) 55 minute(s) 18 second(s)

The system started at 19:13:23 GMT+00 Wed Apr 26 2023

The system : started=warm start   reloaded=by "reload"

Step 3:

Make sure the below commands are present in the switch which is in factory default from CLI

• manager registrar
• manager port-list 987

Step 4:

• Run “Cloudtest(config)# no manager disable”
• Run “Cloudtest# manager connect”

Step 5:

Once after the above steps below are the states you will notice for the switch in cloud

If Switch is in 8095g

Never contacted cloud -> initializing -> Firmware upgrading -> Operational Synchronizing -> Operational

If Switch is in 9010e

Never contacted cloud -> initializing -> Operational Synchronizing -> Operational

Note : The cloud will auto push 9010e to the switch but the process may take time if auto pushed by cloud

From switch CLI :

telnet@Cloudtest#

telnet@Cloudtest#show manager status

============    MGMT Agent State Info     ===================

Manager mode: ACX

Config Status:Enabled Operation Status:Enabled

State:NATS CONNECTED    Prev State:NATS CONNECTING      Event:ACX_HEARTBEAT_EVENT

SWR List                : device.ruckus.cloud 34.66.194.67

SWR fqdn                : device.ruckus.cloud

DNS List                :

Active FQDN List        : None

Backup FQDN List        : None

Active List             : None

Active List IPV6        : None

DHCP Option 43          : No

DHCP Opt 43 List        : None

Backup List             : None

Backup List IPV6        : None

Merged List             : device.ruckus.cloud 34.66.194.67

ACX Server Used         : device.ruckus.cloud

Port List               : 987

Server Port Used        : 443

SWR host                : sw-registrar.ruckuswireless.com

SWR discovery retry cnt : 0

SWR host retry time     : 0                                      

Query Status            : Initiated

NATS Tunnel Status -:

Tunnel Status           : NATS CONNECTED

Websocket Port          : 4222

NATS Port               : 7681

RPCLI Status            : None

ACX Hbt Count           : 1228

ACX JWT Renew Count     : 2

Timer Status :-

Manager Query Timer Status       : None

Manager heartbeat Timer Status   : Running

Manager JWT Renewel Timer Status : Running

  ACX JWT Renewel Time    : 2023-05-04 06:41:36

Click on switch to view switch information

From Running config:

Cloudtest#show run | inc manager

manager registrar

manager registrar-list device.ruckus.cloud 34.66.194.67

manager port-list 987

To connect to console go to More Actions -> CLI session

How to delete a switch from cloud:

Check the switch to delete and click on delete, then type “Delete” in space provided and delete the switch from cloud

Note:

• Ruckus Cloud assigns a username and password to the switch once it is managed by the Ruckus Cloud. Even if the switch is disconnected from the cloud, the switch username and password remain the same. The password can be obtained from the Ruckus Cloud GUI under the Venue’s ‘Switch Settings’.
• Also once the switch is up in cloud Web Access to the switch will be disabled as access to cloud using Web UI is available from Ruckus Cloud

I wanted to take a moment to touch on the minimum code level to onboard an ICX switch to RUCKUS Cloud. In order for an ICX to begin the onboarding process to RUCKUS Cloud, they must be running a minimum code level of 8090d. To confirm your code level, you can use the "show version" command.  If you happen to be running code older than 8090d, you will need to manually upgrade your ICX. Here are the recommended upgrade paths coming from older code:

-If you are running 8080 flat to 8090c, upgrade directly to 8095ca via UFI image

-If you are running any 8070 patch or older, we will need to do a multi-step upgrade. The upgrade path will be: 8070x or older > 8080f (non-ufi) > 8095ca UFI

Additional details are documented in our FastIron Management Guide here and our Cloud User Guide here 

As always, if you need assistance with an upgrade, please do open a case (see my signature) and our support team would be happy to help. 

• AP can be configured with static IP using CLI or Web console.
• Only after the AP is configured with static IP, its SN should be added to the cloud.

Below are the steps to be followed to configure AP with static IP.

Step 1: When the AP is powered up on the network, if AP VLAN has DHCP services then it gets an IP from the DHCP pool which can be used to access the AP CLI using SSH or web console. If there is no DHCP then you can access the AP using the default IP 192.168.0.1

Step 2 :

1. If the AP is being accessed using CLI use the command ‘set ipaddr wan <ipaddr> <netmask> <gateway>’.
2. If AP is accessed using the Web console, go to the device setting and input the address configuration.

Step 1: Testing connectivity and firewall ports for cloud connectivity

• Access and setup the Ruckus Cloud dashboard and licensing

Getting Started Section and Licensing Guide (Admin Guide): https://docs.commscope.com/bundle/ruckuscloud-2201B-onlinehelp/page/GUID-345B88CB-3982-4B1C-9468-0E270FA4151F.html

• Add the AP serial number to the Ruckus Cloud Dashboard at https://ruckus.cloud > Networking Devices > Add AP

• Access one AP that is currently active on the smart zone using the SSH
  • The credentials will be located on the Zone configuration on your Smart Zone controller
• Factory reset the AP using # set factory command
  • The AP if has internet access (following ports are open) will connect to the cloud controller and show with active status
• Replicate the wireless configuration to match the smart zone and test if a client can connect to the one AP we moved over

Once we can bring up one AP and the licensing part is validated, we can proceed with moving the reset of the AP’s

Step 2: Finding the cloud controller IP address

• Open the Cloud controller UI and head over to Networking devices
• Select the AP we moved over and tested on the first step
• Click on the “More Actions” tab found on the right
• Select “Download Log” option
• Once the file is downloaded – search for the following string “Server List:”
• Save this IP address as this the Cloud Server that manages the access points – this will be used in step 3

Step 3: Initiating the production access points in one click  

• Move all AP’s that are intended to be moved to cloud to a single zone and make sure the zone firmware is set to 5.2.x
  • Zone > More > Change AP firmware
• Head over to System > AP Setting > Approval – disable the “Automatically approve all join requests from Aps” toggle and hit OK
  • This prevents the AP’s from coming back to the SZ after the migration

• Make a copy of the access point details by
  • Head over to Access Points > select the zone that has the AP’s that will be moved over to cloud
• Head over to Access Points > select the Zone which has the AP’s parked and on the far right look for the “Export all data to CSV file” option

• This will be the list that we can use in case of a failure to manually move any AP’s that are stuck due to network conditions
• Once the above is completed it is time to move the AP’s to cloud – one zone at a time
• Select “More” from the drop down just above the Zone names and select switch Over Cluster

• Feed in the Server IP we fetched from Step 2 and make sure to enable the “Delete Selected Access Points after switch over” toggle

Step 4: Verify and move any AP’s that did not show up on cloud

• Use the CSV file we collected to find if any AP did not make it to cloud
• Factory reset the AP as per step 1 and execute the command “set scg ip <IP of cloud server>”

Related Article: https://community.ruckuswireless.com/t5/Cloud-and-Analytics/Convert-SmartZone-Access-Point-to-Ruckus-Cloud-Wi-Fi/td-p/45277 

What is the problem?

Wireless clients connecting on a M510 access point (Cloud managed) are not getting IP address.

What is the Root Cause?

This is as per product design.

As per the M510 design, a local DHCP configuration is must on the AP because this AP has dual WAN connection capabilities with LTE SIM. In case of LTE connection, there is no way to pass IP over DHCP from ISP network, thus local DHCP is must on the AP.

What are the Symptoms?

There are two major symptoms if you hit this design intent:

1. M510 on Ruckus Cloud with a DPSK SSID
   • In this type of configuration, you will not be able to enable Network (SSID) on the venue, if there is one or more M510 AP in it.
   • System will show "Activating network" the WLAN and it will circle in loop.
   • If you refresh the page, WLAN will show in disable state.
     
     
2. M510 on Ruckus Cloud with a non-DPSK SSID (any auth type than DPSK)
   • System will not show any error.
   • It will allow you to enable SSID on the venue with M510 AP in it.
   • Client will be able to connect to WLAN but further it will not get an IP address.

What is the Solution?

Make sure that DHCP service is configured and enabled on per AP basis for M510 APs, under venue settings.

To configure, go to Venue > DHCP > WiFi > Enable DHCP service > Choose "Simple DHCP".

For step by step procedure on "How to create DHCP service and enable it on venue", please refer online help page from here.

Got queries or need help? Start the conversation!