My Ruckus Laboratory – Home Network Architecture & Limitations

My Ruckus Laboratory – Home Network Architecture & Limitations

This post is a continuation of the two part series Building a Ruckus Home/Office Laboratory on a Budget. This post starts with a new series name because from this point on, the topics discussed are more specific to my own laboratory environment.  This post details some of the limitations I have run into when designing my home laboratory, specifically around my Internet service provider and home LAN.

The Internet Connection Wrinkle

My home-office environment is sadly complicated by my Internet service provider’s lack of features (the irony).  I have a fiber connection installed at home,  which (considering how much the connection costs me per month) is connected to an offensively cheap home gateway.

The home gateway provides connectivity to the home LAN via four 10/100/1000 RJ-45 Ethernet interfaces on the back.  The home gateway performs basic DHCP and DNS forwarding for a single subnet (10.0.0.0/24) which is sent to the Internet via a NAT behind a dynamically assigned Public IP address.

I am not about to pay the ISP a premium for the luxury of a static IP address, and I am blocked from altering any of the settings on this device.  These two factors become material if I ever want remote access to my lab via an inbound NAT.  I don’t really trust the home gateway to do anything more than what it does already, and want my laboratory network to have as little to do with it as possible.  When they installed this plastic shoebox, at least they did me the favor of disabling the even cheaper Wi-Fi radio.  So my life is not all bad.

A Hidden Advantage

An unexpected advantage is that my debilitated home network has given me the impetus to design a laboratory environment that can fit in almost anywhere.  The entire laboratory environment including both physical and virtual components will be able to function behind a NAT inside almost any LAN.  More on this later!

The Home Network

The LAN provided by the home gateway router is still useful for running a Home Wireless LAN with Ruckus Cloud.  I use this service at home to keep up to date with new features and enhancements, and to perform continuous testing and monitoring of the service, allowing me to eat my own dog food so to speak.  The other advantages of this setup are that my home WLAN is remotely manageable/demo-able and is kept separate from my laboratory environment.

Overview

The image below is an illustration of my home WLAN.  The Ruckus APs are R600 (Root Node) / R500 (Mesh Node) connected over a 5GHz mesh link.  The R600 plugs into the Home Gateway and is the primary wireless connection to the Internet.  The home entertainment goodies are connected by the R500 mesh AP.  The two port switch on the R500 mesh node has proven useful for connecting the Raspberry Pi Home Media Server with the 3TB NAS for quick media playback & reducing unnecessary wireless utilization.  The Apple TV connects directly to the Home WLAN.

 

Full Disclosure: The Mesh links in the picture imply that I am using only 40MHz channels, but I decided to go with 80 MHz channels as none of my neighbors are using 5GHz yet, poor souls!

Limiting BSSIDs

The home SSID and any other client SSIDs are only available from the root AP on 2.4GHz and/or 5GHz as I require them.  My abode is not very big and a single AP placed roughly in the middle easily covers the entire area.

The mesh AP publishes no WLAN services except the mesh SSID.  This makes the network topology and connectivity a bit simpler, ensuring that clients are always directly connected to the root AP. It also means clients cannot connect to the mesh AP and then do an unnecessary double wireless hop to the Internet.

Ruckus Cloud does not support AP & WLAN groups just yet, so you can’t very easily choose to place specific SSIDs onto specific APs within a venue.  But, you can still accomplish the task above by disabling the 2.4GHz and 5GHz radios in the individual mesh APs’ Radio Settings.  The APs will maintain their full mesh functionality, acting both as mesh clients, and beaconing the hidden mesh SSID, allowing other APs to connect into the mesh if needs be.

Why Mesh?

First off, to test mesh features and stability with the Ruckus Cloud controller, but that is obvious I guess.

The other reason is that connectivity options on the Raspberry Pi Model 3 that I am using as my Home Media Server are truly basic.  The Raspberry Pi 3 only has a 2.4GHz, 802.11n, single stream radio, and a 10/100 Ethernet connection.  These connectivity options are SLOOOW for the 3TB NAS when you’re doing backups or big file dumps from a wireless client.  I also don’t want to muck around with an external USB Wi-Fi adapter (although that is an option).  The best option for me was the Ruckus R500 as a high throughput mesh client with a 1Gb/s Ethernet connection straight to the NAS and a 100Mb/s connection to the Pi.

I could, if I wanted to, replace the Raspberry Pi with something more capable like the ODROID C2 which would eliminate the need for having the mesh AP, but there would be no performance improvement and quite possibly a performance degradation over the current setup.

That about sums up the home network, we will discuss more in later posts!

One thought on “My Ruckus Laboratory – Home Network Architecture & Limitations

Leave a Reply

Your email address will not be published. Required fields are marked *