I recently had to go fix up an install of 5 Xirrus 2425H arrays, and in the process of doing so have found some lessons learned that I felt I should share in case anyone gets stuck or needs some info on their deployment.
 |
| Not that this has anything to do with this post, but this thing was so bad ass its worth showing. |
Weatherproofing
When I went to weatherproof the TNC connectors on the bottom of this unit, I learned something: bring patience … or heat shrink tubing, a pair of scissors, and a heat gun. I opted for patience, as it was my first time doing this. The connectors on the bottom of the unit are grouped 4 together and leave very little room for weatherproofing and fingers. In retrospect, if I had some tubing and heat gun, it would’ve taken me 10 minutes tops instead of the 45 per device.
Also, as a bonus, there is lip created by the equipment cover on one side (the front face of the array) that makes it extra difficult to get your digits in there, so if you choose to go the route I did, get ready for some top-of-knuckle pain.
WDS: Definitely not a Xirrus strong suit (even though it’s an awesome implementation of it)
Linking 2 arrays together on the Xirrus AOS is pretty damn simple using their WDS and a few dedicated IAPs:
- Build an SSID for the bridge
- Define the array as the host
- Create a bridge client link with a check-box, SSID, MAC address, and password on the client IAP
- Coffee.
However, there is absolutely zero support for WDS in the XCS / Xirrus Cloud Management System, leaving you to configure it independently on each array / IAP. Typically that wouldn’t be a big deal, oh but it is. The XCS configuration gets pushed to the Xirrus array every time it updates from the cloud, overwriting the config on the array … without WDS support .. which of course it disables when it writes the config. Luckily a week or two ago Xirrus decided to create “Read Only” configurations on XCS so that config settings wouldn’t get overwritten on the array when it pinged the cloud… which is cool, however still pretty sucky because now you can’t configure the arrays from the cloud, you can only monitor them .. sad trombone.
So, lesson learned: if you’re using WDS on Xirrus, try everything you can NOT to use the WDS (even though its awesome), including pricing out inexpensive bridges like Cambium ePMP or mesh gear so you don’t have to lose the ability to config, control, and monitor your arrays from the cloud.
Learn the CLI
Lesson learned: It’s awesome. Super quick, super awesome. SSH into the arrays using Putty. Golf clap to the CLI team.
Be Patient, It’s Doing It’s Thing
Xirrus arrays take about 3 minutes to reboot completely. For a minute or so they’ll come up with 10.0.2.1 as their default IP while they wait for the DHCP server to respond. You can access the array up until it gets a lease from DHCP using that default address, so if you need a quick fix for screwing something up, it’s a cool trick.
Xircon = awesome
That simple little tool gives you a quick view of your network, the IP address of the arrays, and piece of mind knowing they are online. Great job on something simple yet totally usable.
Download it here using your partner portal login:
http://sforce.co/1yflU1IIn closing..
All in all, I have enjoyed working on the gear (like a 6/10). The weatherproofing portion sucked big time. Followed up by the reboot-reset-reconnect-repeat issue with cloud updating, it has made for 4 days of on-site, unbillable service. So, heed the warnings on here and save some time and money. If I think of more, I’ll post em. 🙂
Like this:
Like Loading...
Related
Thank you for this report!