It's hardly news that wireless networking is incredibly empowering for those who use it, but there's even more to WLAN functionality than typically meets the eye. Beyond just providing access for client devices like laptops, smartphones and tablets, an enterprise-grade Wi-Fi network usually has a few tricks up its sleeve for the admin who's willing to seek them out. A recent consulting project took me down the path of indoor mesh wireless, and then a little bit further into a slick bit of configuration that has the potential to solve a number of challenging "How do I…?"-type questions for oddball client devices.
Bringing heat to an outdoor bus stop
I run an extremely large Cisco wireless network environment, with around 4,000 802.11ac and 11n access points (APs), and upwards of 20,000 simultaneous clients at busy times every day. The vast majority of those client connections are made on one of our 802.1X-secured service set identifiers (SSID). We have a small guest complement as well at any given time, which uses its own SSID. For the project in question, I was asked to figure out how to provide heat to an outdoor bus stop on our campus. That required connecting an Ethernet (as in wired)-enabled heater control board to our network. The constraints: no UTP cabling could be run -- easily or cost-effectively -- to the bus stop. Point-to-point wireless bridges were also not practical for a number of reasons. And because of the bus stop's location -- between two buildings cloaked by a dense Wi-Fi signal -- bleed-out was a concern.
Here's the kicker to what seems like should be obvious: There are no Wi-Fi adapters for the control board, and I've yet to find a reliable wireless workgroup bridge that supports Cisco's latest WLAN topologies very well. Enter indoor mesh wireless, along with working a little magic through an AP's Ethernet uplink port.
Indoor mesh, only for outdoor use
Indoor mesh is a double-edged sword. You get to extend the reach of the WLAN infrastructure to places where you can't run cable for an AP, but you do so at the cost of decreased throughput on the backhaul link, and therefore also for Wi-Fi clients that attach to the mesh AP. And you still need electrical power at the far end. For my project, the bus stop had electrical power already, and very little bandwidth was required for the administration of the heater's control board. But what made this application different was that "indoor" mesh was actually going outside, and the AP at the bus stop would not be serving Wi-Fi clients. Instead, it would have its RJ-45 jack enabled and configured to deliver the virtual LAN (VLAN) needed by the heater.
How it was accomplished
Cisco's documentation on indoor mesh can be confusing, and it seems like dozens of pages are expended on what boils down to a few key steps. Here are the important ones (based on Cisco's WLAN controller code version 8.100):
- If you use Cisco's Prime Infrastructure (PI) to manage the WLAN, it's best to enable indoor mesh directly on the controllers to avoid configuration gaps between PI and the controllers.
- Any AP that will participate in the indoor mesh -- either as root AP (RAP) or mesh AP (MAP) -- must have its media access control (MAC) address in the controller's MAC authentication list. (Editor's note: The RAP is the wired node, connecting MAPs -- which have no wired uplink -- back to the network.) If you miss this step, the APs will no longer associate to the controller once you toggle them out of Local mode.
- Even wirelessly connected mesh APs need to start off on the wire. There's nothing automatic with Cisco's mesh.
- Before you can invoke Bridge mode, which toggles on the mesh functions, you need to nail down a static 5-GHz backhaul channel.
- Plan on at least two available RAPs for each MAP for resiliency, after identifying good strong candidates based on signal strength at MAP location.
- With RAPs and MAPs on the wire still in Local mode, set each to Bridge mode. This will reboot the APs and force the Mesh configuration tab to be displayed.
- When the APs return to service, access the Mesh configuration tab and select either RootAP or MeshAP, as appropriate. After the config is applied and saved, you can remove the MAP from the wire and it will use radio backhaul.
Now we have the mesh AP activated, but we're not done. Next, we have to make it behave the way we want -- on both the radio interface and the AP's RJ-45, which will bridge the WLAN of our choice to the heater control. To do that:
- Disable "Backhaul Client Access" under the Mesh tab of the MAP, so wireless clients aren't competing for the radio resources of the 5 GHz radio.
- Disable "VLAN Transparent" under Ethernet Bridging to enable VLAN tagging.
- Enable "Ethernet Bridging," which turns on the RJ-45 port.
- Under Ethernet Bridging, select the VLAN that the bus heater's RJ-45 will use. This VLAN must be present on the trunked uplink to the RAP -- but it does not have to be present at the controller.
And that's the gist of it. The heater controller ends up on whatever VLAN you want it on -- even one that has nothing to do with your Wi-Fi environment. This same application can be used for any Ethernet-connected device (non-wireless printers, projectors, point-of-sale terminals, etc.) where power and Wi-Fi are available but a wired port isn't. Think about temporary events, disaster recovery and other scenarios. This handy little wired extension of Wi-Fi is a great tool to have at your command, even if it doesn't get used often.
See how one town goes mesh and improves its security and compliance posture.