SC-WiFi

Hands on the Cisco 3504 WLC

September 4, 2017 by scwifi 9 Comments

Not only are WLCs not dead, they’re not even on life support. Continued investment into the WLC platform is a clear indicator that there are still several use cases for centralized data, control, and management plane functions. Cisco has a long heritage of building awesome Wireless LAN Controllers (WLCs) and the 3504 is the next in a long line of purpose built WLCs. If you’re familiar with the Cisco WLC portfolio, the 5520 and 8540 WLCs are basically UCS based appliances with hardware offloading cards added in. The 3504 returns to the heritage of a ‘from the ground up’ design of a purpose built desktop WLC solution and it’s aimed pretty squarely at the aging 2504 and 5508 platforms. As many people are moving forward with 802.11ac deployments, a look at your infrastructure controller may be warranted.

Without going into the details that are readily available on the data-sheet, I’ll instead focus on one or two key items of the platform that I find the most compelling.

1) Feature parity. This WLC marks the first time the entry level boxes have feature parity with the larger WLCs. If you peruse any of the release notes, you’ll see a list of exceptions for various platforms especially on the low end. The 3504 was launched out of the gate expecting to support all of the features of the 5520 & 8540 making the differences between the three platforms strictly speeds, feeds, and capacity. This should be a comfort to those that regularly struggle with the feature gap in the Cisco WLC portfolio.

2) Quiet operation. Let’s be honest, there are more than a few deployments where the equipment is sitting table top or on a cabinet out in the open somewhere. The 3504 supports ‘fan off’ operation at temperatures up to 86 F (30 C). For the overwhelming majority of situations, it’s difficult to get up to 86 degrees and maintain it with any level of comfort. This basically means that for most deployments, you’ll never hear a sound coming out of the WLC – even if it’s in your home lab.

3) mGig support. Multigigabit (or NBASE-T) is becoming more and more prevalent on switching infrastructure and this marks the first time we can break the 1G link speed on the infrastructure side without having to deploy a full on 10G infrastructure. Those of you that read my posts regularly may recall that I’m a fan of being able to deploy solutions that break the 1G barrier on my existing copper runs. This was commonly APs but if you’ve been investing in the latest and greatest and ignoring the FUD about not needing mGig, this is another opportunity to leverage that investment.

All of these coupled together mean that you can get a quite elegant solution for most any environment now that we’re able to breath some life into the low end of the Cisco WLC portfolio. The 3504 is a notable improvement on the hardware and scale of the 2504 but don’t let it’s ‘desktop friendliness’ fool you – if you’re a 5508 customer today, there are going to be tons of places where ‘stepping down’ into a 3504 makes really great sense. With the rack mount kit available for it, you could easily put two 3504s in HA/SSO mode in 1RU and have all of the same features as the 5508 with a bit less capacity. Regardless of your current deployment, you really should make sure you take a peek at the 3504 as you’re considering lifecycle management of your gear.

Disclaimer: I was provided a 3504 from Cisco as part of an early field trial and formed my opinions on my own. This post is my original work and I composed it without an expectation from Cisco.

Filed under 802.11ac, Access Points, Cisco, Wireless, WLC

Portable power for APoS

July 20, 2017 by scwifi 3 Comments

Newer APs often come with some pretty hefty power requirements. Standards such as the 15.4W 802.3af specification are increasingly insufficient on APs that are more power hungry. Enter the 802.3at standard that can support all the way up to 30.0W! While runtime operation of these (over PoE switches) is a topic all of itself, the Wi-Fi professional has always had issues with doing AP on a Stick designs (site surveys, empirical measurements) – especially when your AP power requirements exceed some of the more tried and true solutions. I’ve hashed out several different solutions over the past year, and thought it was time to write them all down.

The staple of AP powering has been for a very long time the Ventev / TerraWave – MIMO Site Survey Battery Pack. On its own, it only supports the older 802.3af specification. This all in one solution is portable, but since it’s based on old lead-acid technologies, it tends to fall on the heavier side of the solutions. Venerable, heavy, doesn’t support newer APs, but everyone has them.

The Terrawave Site Survey Battery Pack!

Enter the Tycon Systems DC To DC Converter And POE Inserter. This bad boy becomes an integral part of most of the rest of our solutions – and it’s very important to understand that it comes in a variety of input voltages. You must mate it to the power solution you’re using.

The Tycon POE injector.

Using the Ventev MIMO Site Survey Battery pack, you can see from it’s data sheet that it supports an external 56V output. If you use the included 56V cable, cut the ends off and mate that with the Tycon that has 802.3at power output, you can retrofit existing site survey battery packs to support newer high power APs! Sadly, physics wins out at some point. Since you’re drawing more power, invariably your battery will not last as long. If you have an older unit, you may be having problems holding a charge or any other number of other issues, but if you’re in a bind, it’s a potential solution.

If you think this Tycon solution looks familiar, Scott Stapleton wrote about a similar solution in his blog. Using the injector that he stated (TP-DCDC-1248GD-HP, note the 10 to 15VDC input change), along with commonly available batteries such as the RAV power units, you can extend the run time of your APoS efforts by interchanging either larger capacity batteries or additional units. In my tests, I used two of the RAVPower 2300mAh batteries along with the Jacobs interconnect to complete the solution.

Image shamelessly stolen from Scott Stapleton.

Thanks to Keith Parsons for this next solution, which is a variation on Scott’s using a battery from Hardened Power Systems. The ReVolt G2 is a large capacity battery that uses 12V powerpole connectors that is *very* light (27 ounces) due to the LiFePO4 battery technology. This, mated with correct Tycon solution using the 12V powerpole connectors gives you a far more portable solution (one high capacity battery, one injector) that can last all day long!

High Capacity Battery, lightweight.

While these all address in varying ways different requirements, they’re all considered a touch on the bulky side and carrying around multiple pieces has always been a challenge for a road warrior that doesn’t want to lose or break bits and pieces. Enter the Ventev VenVolt solution that they were showing off at Cisco Live US 2017. While this isn’t shipping yet, they had a prototype to show off that looked awesome! Lightweight, all in one solution, all day battery on modern technology. Stated dimensions for the unit are 9 3/8″ x 4 3/4″ x 3″ according to Mike Parry. I for one can’t wait for a fully integrated solution to finish baking and come to market!

Filed under Access Points, Surveying, Wireless

Musings on Multigigabit and APeX

July 20, 2017 by scwifi 1 Comment

Cisco Live is always a whirlwind of information and the 2017 US event was no exception! Between the Catalyst 9k launch, the focus on Software Defined Access, and Intuitive Networking, it’s easy to miss some of the nuance that was to be uncovered on the show floor. In the Enterprise Networking booth there was a hidden nugget that was focused on developers called APeX (short for Access Point Extensions). One part of this APeX program is the Extender Module Hardware Development Kit – EM-HDK for short (or just HDK for even shorter!) that plugs directly into the often-overlooked module port on the AP3800. The board itself is a neat springboard for developing on – it allows you to attach a Raspberry Pi, Arduino, XBee or other Small Board Computer directly to the AP. Of course, you wouldn’t deploy a production solution like this, but you would take the solution you’re working on, and compress it to a design that’s purpose built for the modular slot that’s part of the AP3800.

The APeX EM-HDK

The thing that struck me though is that while the HDK is neat – and if you have any SBC experience at all, a very interesting platform, the hidden secret of the HDK is that it also sports two Gigabit Ethernet connections supporting PoE out. It is worth noting that if your host AP had a single 1 Gigabit link, and you put two additional 1 Gigabit links on the back side of it, you can safely assume you have an automatic bottleneck. This is the genesis of my epiphany – those that were shortsighted enough to make claims that 802.11ac wave 2 doesn’t justify uplink speeds beyond 1 Gigabit, clearly did not take into account that 2x 802.11ac wave 2 radios moves you a lot closer to that 1 Gigabit bottleneck, and when you want to pass an additional 2x 1 Gigabit Ethernet interfaces on the same link as your 2x 802.11ac wave 2 radios, your use case for Multigigabit becomes pretty clear.

HDK with Raspberry Pi attached to an AP3802i.

Remember folks, your wired infrastructure is expected to last much longer than your typical switches will. As you start seeing very obvious use cases for breaking the 1 Gigabit uplink requirement, make sure you’re considering the cost savings of investing in multi gig technology today – especially if you can get it for a nominal uptick in price.

Multigigabit interfaces, left. 10G, right.

Go here for more information on Cisco’s mgig (or NBASE-T) and here for information on the APeX program over at Devnet.

Filed under 802.11ac, Access Points, Cisco

Cisco Wave2 site survey how-to

March 20, 2017 by scwifi 16 Comments

So, you have a shiny new Cisco 802.11ac wave 2 Access Point and you went to go grab the autonomous code for it to do an APoS survey – but then realized there isn’t autonomous code for the 2802 or 3802 (or any other wave 2) Cisco AP, huh? You may have noticed that there is a new product called Mobility Express. You can use this ‘controller on an AP’. Here is a guide I co-authored for doing just this.

-Sam

Summary:

Cisco 802.11ac Wave 2 APs do not run IOS like previous platforms. This presents a challenge when trying to perform an AP on a Stick site survey with only a battery pack. The standalone mode for these Access Points is achieved using Mobility Express – or the function to use the integrated WLC on the Access Point to control the radio functionality in a standalone fashion.

Prerequisites:

8.3MR1 code supporting Mobility Express for your Access Point
Local power source for your Access Point (AIR-PWR-C or site survey battery with sufficient power)
Operational Standalone or Virtual Wireless Lan Controller running 8.2MR2 or 8.3 for configuring the Access Point mode and moving the images
TFTP server
802.11ac Wave 2 Access Point (Please note, the 1810 platform is not supported at the time of this writing)
A serial console cable to watch/configure your AP

Process:

Step 1) Join your Access Point to your local WLC as you would during a normal deployment.

For the 2800/3800 platforms, you must be running a minimum of 8.2MR2 or 8.3 for step 1. For 1830/1850, there is no similar requirement aside from running a release that supports those platforms. Please note that this is not the above referenced ME image version which will be used in step 2.

Step 2) Convert the Access Point to Mobility Express mode using the correct image.

This is accomplished by going to the console of the AP and logging in, then enabling, then using the ap-type command to convert the AP over to Mobility Express and download the new image from your TFTP server. To get the correct AP image file, you will need to decompress the image bundle and use the correct image for your AP platform. For example:

1830/1850 you should use ap1g4
2800/3800 you should use ap3g3

Note: You can also use the platform specific ME image from CCO if you have that available. If you’re using a Universal SKU AP, you should wait for it to regulatory prime before trying to convert the image to make sure you don’t incur a reboot mid-code change.

Once your AP goes down for a reboot, disconnect the LAN cable and ensure its powered by local power or your survey battery pack:

Step 3) Wait for your Access Point to boot completely.

At this point your Access Point will do several things. It will boot and you will see about 2 minutes of the following messages:

Once these timeout, the Access Point will boot the Mobility Express WLC automatically:

Step 4) Configure the WLC using the following values:

Would you like to terminate autoinstall? [yes]: yes
Enter Administrative User Name (24 characters max): admin
Enter Administrative Password (3 to 24 characters): Cisco123
Re-enter Administrative Password : Cisco123
System Name [Cisco_11:aa:1a] (31 characters max): ME_WLC
Enter Country Code list (enter ‘help’ for a list of countries) [US]: US
Configure a NTP server now? [YES][no]: no
Configure the system time now? [YES][no]: yes
Enter the date in MM/DD/YY format: <date>
Enter the time in HH:MM:SS format: <time>
Enter timezone location index (enter ‘help’ for a list of timezones): 7
Management Interface IP Address: 192.168.1.2
Management Interface Netmask: 255.255.255.0
Management Interface Default Router: 192.168.1.1
Create Management DHCP Scope? [yes][NO]: yes
DHCP Network : 192.168.1.0
DHCP Netmask : 255.255.255.0
Router IP: 192.168.1.1
Start DHCP IP address: 192.168.1.10
Stop DHCP IP address: 192.168.1.200
DomainName : me.local
DNS Server : [OPENDNS][user DNS] OPENDNS
Create Employee Network? [YES][no]: yes
Employee Network Name (SSID)?: survey_ME
NOTE, USE YOUR INITIALS INSTEAD OF ‘ME’ TO DIFFERENTIATE YOUR SSID
Employee VLAN Identifier? [MGMT][1-4095]: MGMT
Employee Network Security? [PSK][enterprise]: PSK
Employee PSK Passphrase (8-38 characters)?: <temp key>
Re-enter Employee PSK Passphrase: <temp key>
Create Guest Network? [yes][NO]: no
Enable RF Parameter Optimization? [YES][no]: no
Configuration correct? If yes, system will save it and reset. [yes][NO]: yes

It is highly recommended to use the values above. Once the Access Point reboots continue on.

Step 5) Clean up the AP

Some of the defaults are not completely friendly. We’ll clean those up now. Discover the name of the Access Point using ‘show ap summary’ and rename it to something more friendly like ‘ap’. It should be noted that renaming your Access Point to ‘ap’ will make configurations easier and in line with the examples below, but if you’re part of a larger team and require unique Access Point names, this is where you would set them, making note to use your defined Access Point name instead of the shortened name ‘ap’ as described in the rest of this document.

Next we want to disable the PSK security on the WLAN for easier association and testing and enable Aironet Extensions to include the AP name in beacons. This step is optional, but recommended. You must first disable the WLAN, the disable the PSK, then re-enable the WLAN:

(Cisco Controller) >config wlan disable 1
(Cisco Controller) >config wlan security wpa disable 1
(Cisco Controller) >config wlan ccx aironetIeSupport enable 1
(Cisco Controller) >config wlan enable 1
(Cisco Controller) >save config
Are you sure you want to save? (y/n) y

Once you’ve made these changes, perform a ‘save config’ as shown on the WLC to ensure the changes aren’t overwritten.

Step 6) Configure your radios for site survey specifics including channel and TX power.

To set these values, you must admin disable the radio, make the change, then re-enable it. Remember, these are the same commands you’d use on a production, bare-metal WLC and are not new. Here are a few examples:

To change the 2.4GHz radio to channel 6:
(Cisco Controller) >config 802.11b disable ap
(Cisco Controller) >config 802.11b channel ap ap 6
(Cisco Controller) >config 802.11b enable ap

To change the 2.4GHz radio to power level 3:
(Cisco Controller) >config 802.11b disable ap
(Cisco Controller) >config 802.11b txPower ap ap 3
(Cisco Controller) >config 802.11b enable ap

To change the 5GHz radio to channel 44:
(Cisco Controller) >config 802.11a disable ap
(Cisco Controller) >config 802.11a channel ap ap 44
(Cisco Controller) >config 802.11a enable ap

To change the 5GHz radio to power level 5:
(Cisco Controller) >config 802.11a disable ap
(Cisco Controller) >config 802.11a txpower ap ap 5
(Cisco Controller) >config 802.11a enable ap

To change the 5GHz radio width to 40MHz:
(Cisco Controller) >config 802.11a disable ap
(Cisco Controller) >config 802.11a chan_width ap 40
(Cisco Controller) >config 802.11a enable ap

Of course, you can couple all of these commands together to reduce the number of times you’re disabling your radio if you’re doing an initial configuration. Here is an example of setting the radios both to power level 2 and the 2.4GHz radio to channel 11, and the 5GHz channel to 100@40MHz all in one script:

(Cisco Controller) >config 802.11b disable ap
(Cisco Controller) >config 802.11a disable ap
(Cisco Controller) >config 802.11b channel ap ap 11
(Cisco Controller) >config 802.11b txPower ap ap 2
(Cisco Controller) >config 802.11a channel ap ap 100
(Cisco Controller) >config 802.11a txpower ap ap 2
(Cisco Controller) >config 802.11a chan_width ap 40
(Cisco Controller) >config 802.11b enable ap
(Cisco Controller) >config 802.11a enable ap

To see the channel of the Access Point currently configured, use the ‘show ap channel ap’ command:

To see the power level of the Access Point currently configured, use the ‘show ap config slot 0 ap’ (for 2.4GHz) or ‘show ap config slot 1 ap’ (for 5GHz’ command and look for the following data:

Alternatively, use the grep command to just pick out the data you’re interested in:

Step 7) Alternative management via the WLC GUI

If you’ve followed this guide up till now, you can also access the management interface of the WLC by using your PC and joining your open survey SSID. Then open a web browser and navigate to https://192.168.1.2/ .

Step 8) Putting it all back the way you found it

To convert the AP back to capwap mode and undo this configuration, you must goto the AP console using ‘apciscoshell’ and perform the ‘ap-type’ command again:

Addendum:

Dual role radio notes:

The AP2800 and AP3800 both include the ability to change the slot 0 radios personality from 2.4GHz to 5GHz. This presents some unique configuration considerations as follows:

To convert the XOR radio from the default 2.4GHz to 5GHz and change its channel to 40 @ 40MHz wide use:
(Cisco Controller) >config 802.11-abgn disable ap
(Cisco Controller) >config 802.11-abgn role ap manual client-serving
(Cisco Controller) >config 802.11-abgn band ap ap 5GHz
(Cisco Controller) >config 802.11-abgn channel ap ap 40
(Cisco Controller) >config 802.11-abgn chan_width ap 40
(Cisco Controller) >config 802.11-abgn enable ap

The following should be noted for this configuration:

When you convert the XOR radio into 5GHz mode, you must use a channel that is 100MHz apart from the slot 1 radio in the Access Point. When you configure the XOR radio into 5GHz mode on an ‘e’ model of AP, you must have an external antenna plugged into the DART connector or this configuration will fail. When you configure the XOR radio into 5GHz mode on an ‘i’ model of AP, the tx power will be fixed and not modifiable (by design) to its lowest possible value to retain micro-cell integrity.

To change the XOR radio from a configured 5GHz to 2.4GHz and change its channel to 6 use:

(Cisco Controller) >config 802.11-abgn disable ap
(Cisco Controller) >config 802.11-abgn band ap ap 2.4GHz
(Cisco Controller) >config 802.11-abgn channel ap ap 6
(Cisco Controller) >config 802.11-abgn enable ap

Filed under 802.11ac, Access Points, Cisco, Surveying, Wireless, WLC

Here’s the thing about deleting your FaceBook account

January 20, 2017 by scwifi 5 Comments

When you finally reach the breaking point, you’re sick of all of the infighting and bickering, all of the people requiring that you look at things from their perspective, but refuse to see it from yours. When you have an opinion about politics that’s a bit too middle of the road for your left or right friends. When your family, your extended family, and/or your friends of your family engage in the kind of ‘behind the keyboard’ backstabbing, opinion tossing, open slandering of people that you care about – all because there are no repercussions – all under the guise of ‘I know someone better than you do’. When you’ve finally had enough and you go to delete your FaceBook account, you want to tell people. You want to educate them that the mire they’re drowning in, contributing to, addicted to – the social infighting, the ‘I’m better than you and here’s why’. Unfortunately when you compose a lengthy, well worded thought out op-ed piece on why you’ve finally given up on all of them, then delete your account – that post goes along with it. For those that actually reach the breaking point, then follow through with their account deletion, there is a narrow window of time between you saying goodbye to the world and that post being deleted for no one else to ever see. Fortunately for me, I have a blog and other social media accounts that for some reason have stayed clear of the close and personal infighting that’s the impetus for this post. I’ll be cross posting this blog post here (on sc-wifi.com) since it is technology related by way of it’s social media commentary – which has an odd tie to the technology I’m passionate about.

When my childhood friend decided today to make very public a private conversation with my older brother, people did what people do – decided to make assumptions about my brother’s intentions and decided they were going to turn into social commentators. Sadly, my friend did nothing to assuage the beratement that ensued, even encouraging it with comments about how recent holiday visits had been ‘awkward’. Couple that with his mother (and my mothers ‘best friend’) participating in the debasing spectacle assuming my brother was looking for ‘glee’.

Needless to say, it’s been far too long since I’ve made a stand. I’ve kept my political affiliation to myself (there is one person in the world that *knows* who I voted for, and I sleep next to her every night). You, dear reader, can make all the assumptions you want around who I support and why I support but I was raised that your political decisions are yours and yours alone. I try to keep a level head around the extreme on either side of the fence, trying to understand both perspectives, but the shameful display that occurred today, only has a single silver lining. That my sister in law had a chance to stand up for her husband. I’m ashamed to not have taken a stand before (I missed the last go ‘round) but it’s time to rectify that now. Clearly the longtime bond between our families has turned out to be just a sham.

Now, I’m getting ready to bring my second child into this world. I’ll protect them and my firstborn from the bullshit faux friends and infighting that’s ultimately the cancer that will cripple us all. You will not know about my child. You will not know if they’re boy or girl. You will not see pictures of them unless you text me (or I text you). This is not a challenge to repost, like, or otherwise solicit a response from you. It is merely a good bye. Your infighting has broken me. I’m done and it’s time I take a page out of my younger’s brothers book and say goodbye to FaceBook for good. In the narrow window between me posting this and deleting my account, if you happen to read it – please know – when you challenge my family, they will always wins out over you. It’s up to you how you support whom but when you call into question the goodness of a public servant – then expect that person to come rescue your ass when your house is burning down around you, you should know that despite the fact that you were an asshole to him, he’ll still help you.

Filed under Uncategorized

All about DART

June 30, 2016 by scwifi 3 Comments

Yes, I’m writing a blog post on a connector. Just a connector. If you’re like me, you can appreciate the little things in life. This is one of those times that something little snuck past me and it wasn’t until now that I’m starting to fully appreciate it’s impact and importance. When Cisco launched their 2800/3800 APs, dual 5GHz was certainly at the top of the list of the most talked about features (see #MFD session here!). This came with some caveats (as all new features do) and using a separate set of antennas for the second 5GHz radio was the biggest. This is handled on the internal antenna models with an in-built extra set of antennas, but on the external antenna models, this presented a bit of a challenge. In the wide world of antenna connectors, in the Wi-Fi space, we commonly deal with RP-SMA, RP-TNC, and N-type connectors depending on your vendor and the deployment type. In the Cisco world, that’s RP-TNC for indoor APs. With a single, 4 element antenna today, that’s four connectors (or four, single element antennas). With two antennas, that drives the number of antenna connectors up to a whopping 8 cables you’re looking to have coming out of your AP! 8 cables, 8 connectors, it gets messy quick. Enter the DART connector:

All covered up!

Inconspicuously located on the side of the AP, behind a little door, the new DART connector reveals itself in a complex looking array of pins and connectors in a tight external facing form factor. Here’s the interesting part though, this isn’t a new connector! In fact, it’s been shipping to the public for a little bit now in the form of the Cisco Hyperlocation module and antenna!

Hyperlocation with DART

DART on Hyperlocation Exposed!

So, that’s all great and all, but what’s really *in* the DART connector? DART stands for Digital Analog Radio Termination and it does all of those wonderful things. Firstly, the analog antenna connectors that we use (so we don’t have 8 RP-TNC ports on our AP) are the 4 larger pins across the bottom of the connector.

Look at all those pins!

When we use the DART to RP-TNC pig tail for backwards compatibility with shipping antennas, these are the connectors that map directly to the 4 RP-TNC connectors. In short, these are the 4 analog ports that carry the actual analog signal through the connector.

DART to RP-TNC Cable!

Fully assembled!

For existing RP-TNC based antennas

On the cable end!

Which leave us with the extra 16 pins. Those are the ‘Digital’ piece of the DART connector and can be used for a variety of uses. Initially, this is used to identify the type of cable that is attached to the DART connector. For example, in the Hyperlocation module, this shows up on the AP details:

Circular Antenna

For the DART to RP-TNC connector, this is in the form of a simple resistor that maps two of the pins back to each other:

DART disassembled

It’s easy to see that there’s quite a bit of left over functionality that could be used in a connector of this type. Today if we use very high gain antennas we have to have multiple models of APs (see the 3602p and 3702p). If we could identify the gain of the antenna by way of an automated mechanism, we could have the AP auto adjust itself to not exceed EIRP. Another potential use case is DART native versions of our existing antennas in a simple to use connector. Imagine not having to screw on connectors anymore! With a quick-connect antenna mechanism that auto-IDs the antenna capabilities to the AP, this could certainly be the new connector of choice for external antennas in the future!

With DART connector on edge.

Note the DART connector on the left.

Filed under Access Points, Cisco, FCC, Wireless Tech Field Day

NETSCOUT AirCheck G2 unleashed!

June 30, 2016 by scwifi 2 Comments

This blog post is part 1 of a multipart series on the new generation of Wi-Fi tools. There has been a dramatic evolution of the various tools that the WiFi professional uses over the past year or so . I wanted to take a moment and spell out my thoughts on the current state of tools in our industry.

First shown at the Wireless Field Day 1 in San Jose the Fluke AirCheck rapidly became the staple of the ‘serious’ WLAN troubleshooter. It made a huge splash and was immediately lauded for it’s easy straightforward to getting down to the serious data that you need to see when troubleshooting your wireless network. All of the heavy hitters in the industry have been talking about them since then and it’s almost unbelievable that it was just assumed that people would have them on anything but the most entry level of jobs. The platform had very few deficiencies overall and almost became part of the de-facto tool that you would be expected to know and use – almost like site survey software.

AirCheck G2 – The green is a nice touch!

It’s hard to think of something replacing the Fluke AirCheck but the inevitable has happened. There is and Application & Network Performance Management company called NETSCOUT recently acquired the Fluke team responsible for the AirCheck – which was in the midst of developing the next generation of the product. Launched late last month, the AirCheck G2 promises to best it’s predecessor in several areas. Head on over to the official announcement and keep a keen eye out for a quote or two from yours truly! 🙂

I was fortunate enough to be included early on in the development conversations of the AirCheck G2 and so like to believe that I helped shape in some small way the look, feel, and usability of the product as it exists today. From early on, there was a focus on the ‘gimme’ features such as inclusion of a color touchscreen. Other features didn’t develop till later on such as the built in ethernet port for wired testing in the field. Those of you that love the LinkSprinter functionality, this is aimed squarely at you! In fact, there is a laundry list of features that read like a who’s who of todays troubleshooting gear – 802.11ac support, long life battery, external antenna support, USB expansion ports, on screen keyboard and navigation menus, auto testing, and rapid boot & shutdown, just to name a few.

Note the External Antenna port on the far right (capped) for the directional antenna attachment.

By far and away though, the feature that I’m most enamored with at the moment is the Link-Live.com integration. Starting with an easy way to claim the devices online, a one stop shop for getting your software and updates, and of course, upload notifications of the testing you’ve just done – the ability to bring Organizational structure to such an outstanding troubleshooting tool really brings the product full circle. NETSCOUT has done a superb job of rolling functionality and usability into a cloud based product and included it with the product! This wraps up all of the auto-testing into an easy to use and store place for testing and validation. While this may seem like simple functionality, for an organization with multiple units in the field, this sort of automated cloud-rollup functionality is hands down one of the best features of the AirCheck – and that’s saying a lot!

Useful for making sure the link you’re using is functional!

If you haven’t had a chance to get your hands on an AirCheck or have been waiting for a refresh to make the product ‘perfect’, now is the time. You should go ask your VAR, NETSCOUT rep, or beg borrow or steal one to get some time under your belt with one. The simplicity of the product, ease of use, intuitive navigation, and ready access to some very in-depth and advanced data in a straightforward way to consume it.

Filed under 802.11ac, NETSCOUT, Wireless

One in one hundred and fifty three quintillion.

March 29, 2016 by Sam Clements 15 Comments

RRM – a common term for Radio Resource Management – or the set of algorithms that set the channel and power level of your Access Points in an automated fashion. You’ve heard it all before, “RRM is broken, RRM picked the wrong channel, RRM hates me, RRM isn’t right for my network”. The reality is that RRM:

Isn’t dumb
Doesn’t hate you
Doesn’t love you
Doesn’t feel anything for that matter

As it turns out, RRM isn’t even smart. It has no feelings, passion, hate, love, real, imagined, or otherwise. In fact, RRM is just a series of algorithms that are built to do one thing – whatever you tell it to. RRM is a framework, meant to be built, adjusted, tweaked, and tuned. To be fair, there are two major topics that tend to give RRM a bad name and they are:

1) Every vendor implements RRM differently. This is a good thing. It’s called a competitive differentiator and the hardware capabilities of some vendors are not present in other vendors equipment so they may make poorer or less-informed decisions about your network

2) Most people don’t modify the default RRM configuration. This is a bad thing which leads me to the point of my post.

I decided to put myself in the shoes of Cisco. I asked myself, if I were building RRM, and I could only set one configuration as a default out of the box, how many would I have to pick from? The answer may surprise you – if you counted every possible RRM combination exposed in the GUI on a Cisco WLC (running 8.2 code) you’d end up in the neighborhood of 53 quintillion possibilities (153042639740283000000 to be exact). Assuming my math is correct (and if it’s not, I’m actually too low), that means that some poor developer somewhere had to pick *one* default configuration to ship out of the box and if you’ve not adjusted it, there’s a couple more for you to try… Now, I can already hear the groaning – “but I don’t have time to try all those!”. You’re right – of the possible sane configurations you can try, there are a few widgets you should focus on – and you certainly don’t need to try every possible combination but much like any other auto functioning mechanism in your network (OSPF, EIGRP, VTP, Auto Updates) the defaults are likely to not be 100% optimal in your environment. When your network adopted OSPF, did you leave it at the defaults? What about Windows Updates? What about AntiVirus? What about… never mind you get the idea…

Well, you may ask, why doesn’t Cisco just change the RRM defaults to ‘fit more environments’? That’s an excellent question and in fact, Cisco has done just that! They made a neighbor threshold change in WLC release 4.1.185.0 and the overhauled the defaults with the Mobility Express setup wizard in 8.0. The question is, did you implement the changes of the new defaults or are you running an old config?

If you have an issue with the way RRM is functioning, instead of lambasting it as hateful, dumb, or otherwise ineffectual, I have one question to ask you. Which of the 153042639740283000000 combinations didn’t work for you?

-Sam

Fun fact: if every possible RRM combination was a black pixel on your shiny new 4k TV, and you were watching 120FPS content, you’d be staring at a black screen for over 160 years.

FAQ:

Q: Isn’t it easier to just static plan all channels and TX powers everywhere?

A: Not if you want to spend your life manually reacting to new neighbors, new sources of interference, or any of the myriad of other changes that could occur in your environment – including AP failures (no one ever accidentally unplugs an AP, do they?) and people moving and changing furniture or other obstructions.

Q: Do I really need to try every last one of those combinations?

A: No! Nor am I advocating that. I think you should look at some of the heavy hitters (neighbors, max/min), understand how those work and how they’re impacting your network, then decide for yourself if tuning RRM makes sense.

Q: Why doesn’t Cisco just update my network with the new RRM defaults when I update code?

A: Because, not all RRM options are safe/valid for all users – you have a configuration on your WLC and I have one on mine. If you want to implement a new feature, you should do it prescriptively – not because a manufacture thinks it’s the best thing since sliced bread.

Q: Your number is too high. Are you sure that’s real?

A: Nope! In fact, I included *all* possible combinations with the intention of seeing just how high it actually is. This includes all possible channel combinations.

Q: But everyone runs the same channel combinations, that’s an inaccurate representation of your claims!

A: Not technically a question, but fair point – except that there are many multiple channel planning recommendations – some customers use a 3 channel 2.4GHz plan in the US, some use a 4 channel 2.4GHz plan in the UK. Some folks use UNII2e, some folks don’t. Some folks say use all channels except 149 (for Apple TV issues), some don’t. The upshot is that you must know your environment’s requirements including channel requirements and adjust for them. By the way, capping with a max 3 channel 2.4GHz plan and a max using default number of 5GHz channels (12) in my calculations still leaves 18680481146880000 possible combinations. Feel free to check my math:

WLC combinations

Filed under Cisco, Wireless

The E is for Easy

February 5, 2016 by scwifi 5 Comments

I’ve been struggling to put into words just how straightforward configuring the ePMP 1000 from Cambium Networks is. While that may sound like something completely boring to write about, I assure you, once you’ve tried to administer or even out of the box configure Point to Point links from the likes of most anyone else, you really come to appreciate the simplicity and readiness of the out of the box experience that Cambium has so clearly focused on. The ePMP 1000 unit is part of the broader Cambium Backhaul and Access portfolio and can be used in a variety of roles depending on your network layout and your overall throughput and performance needs. Architecture and design topics aside, the biggest challenge I had with the evaluation units I received was making sure they had the latest firmware on them. Starting there (and that was even really straightforward), I applied the latest firmware to both units then cleared their configs. I took the remote side (Subscriber Module) and put it in the other room with local power applied to it. I then powered up the close unit and changed it to ‘Access Point’ then rebooted it. From this point forward, all of the other settings were optional including changing my hostnames, IP addresses, NTP servers, SNMP strings, etc. The point being, when they say ‘Quick Start’, they mean quick!

Screen Shot 2016-02-05 at 6.25.36 AM

The SM (Subscriber Module) joined the AP (Access Point) as close to ‘automatically’ as I could envision a product being. Of course, just because they came up rapidly doesn’t mean they’re short on features or configurable options – there’s no need to stick to the default security settings, management settings, or any of the radio specific performance settings – all seem to be highly customizable and well worth exploring.

Easy to understand SM link info

One other ‘nice feature’ is of course the SNMP polling you’d expect from a good piece of network gear. While it may seem like a simple feature, the ability to setup MRTG at point it at a radio interface for downlink SNR was very easy to do. Here is the snippet I used from MRTG after changing my SNMP community strings:

Target[ePMPdownSNR]: 1.3.6.1.4.1.17713.21.1.2.18.0&1.3.6.1.4.1.17713.21.1.2.18.0:snmp_string@192.168.3.62:::::2
Title[ePMPdownSNR]: ePMP1000 downlink SNR
MaxBytes[ePMPdownSNR]: 100
Options[ePMPdownSNR]: gauge,growright,nopercent
PageTop[ePMPdownSNR]: <H1>ePMP1000 downlink SNR</H1>
ShortLegend[ePMPdownSNR]: SNR
YLegend[ePMPdownSNR]: SNR
LegendI[ePMPdownSNR]: SNR
LegendO[ePMPdownSNR]: SNR

and here’s what the resultant charts look like:

cambium daily

Screen Shot 2016-02-05 at 6.51.42 AM

All in all, if you’re in the market for a new point to point solution, I’d advocate you go check out the ePMP and other Cambium products. They’re priced right and have the features that make sense.

Full disclosure: as a Wireless Field Day 8 delagate, Cambium Networks provided me a pair of ePMP 1000 units for personal use with no obligation to write about them. The above article is done at no cost or commitment to either the Tech Field Day organization or Cambium Networks.

As requested, here are some pictures of the gear itself.

Filed under Uncategorized

The Cloud giveth, the Cloud taketh away

February 1, 2016 by scwifi 14 Comments

We all love ‘The Cloud’. It’s flexible, fast, always (mostly) available, and takes our business agility to heretofore unknown heights – but what happens when the service you’re using in the cloud goes a different direction than you need or want it to?

Meraki has been touting the Cloud flexibility as *the* single most important reason to move to their infrastructure management platform. This brings with it a whole host of great things like access-anywhere management, rapid feature development, and a whole new paradigm of how to configure your infrastructure equipment. In one move, Cisco has rocketed past the CLI based days of old, past ‘here’s a pretty GUI’ to 100% web driven, ‘don’t worry your pretty little head about it’ dashboards for everything from configuration, monitoring, troubleshooting, and deployment. It works and it works well.

Today marks the closing of Copy – a Cloud based file sync service from Barracuda and it got me thinking. When someone shudders their doors and it’s ‘just files’, you go to another Cloud based service provider – in this case Dropbox or box.com. What happens when/if Meraki goes away? Okay, they’re under the wing of big-brother Cisco now, so the chances of that happening are basically nil, but what if you ratchet that concern back a notch? What if they make a change you don’t like? What about ‘perpetual beta’ features such as the Remote Control that have been in beta since prior to the Cisco acquisition? What happens if you don’t pay your bill? Those of us familiar with Cloud services like Office 365 know that when you stop paying, you stop playing and for software based services (like Copy today) that doesn’t seem to as big as a deal to most people. What happens when that service is your network?

Perpetual Beta features

When Meraki adds a new feature to their product, the Cloud enables rapid deployment of those features. This is good. What happens when they remove a feature you use such as WAN Optimization? As you an see here Meraki decided to retire what they perceived to be either a little-used feature or a feature that was too difficult to maintain to keep functioning properly.

WAN Optimization, gone baby, gone!

What happens when Meraki decides to artificially cap the performance of your router (intentionally or unintentionally) to 50M?

Astute reddit users, always on the lookout.

While the WAN Optimization removal is clearly an intentional move and the Z1 cap is clearly unintentional, these both raise very significant questions about allowing someone else to be the ultimate authority for the features that are deployed on hardware you’ve purchased. What is your recourse when this happens? Open a support ticket? Make a wish? Roll back the firmware (hah!)? With no fail-safe mode of operation by design, when you lock yourself into a Cloud based infrastructure product, you are ultimately at the mercy of using features how and where they determine are best suited. Your only recourse is to scrap your gear if they make a decision to go in a direction that you no longer support. What is the environmental impact to this business model? How many Cloud-only products end up in landfills because of expired licenses? How much eWaste is generated because the product has stopped functioning (not through MTBF, but intentionally crippling through code)? You used to have options like Cucumber Tony and OpenWRT, but apparently Meraki has fixed the technical loophole that those folks used to use for the MR-12 and MR-16 Access Points by way of a Trusted Platform Module.

What is your take on Meraki and other Cloud based services that you operate your business with? Cloud based products are great and work as designed – but is loss of features something you consider prior to your investment in a solution? Does your organization rely on perpetually beta features that never seem to make it into production? Has a feature been ‘pulled out from underneath you’? What are you doing with that old AP/switch/firewall that is perfectly good hardware but you let the license lapse on? Inquiring minds want to know – please leave me a comment and let me know how you and your organization handles this kind of quandary!

Filed under Access Points, Cisco, Meraki, Wireless

← Older posts

Newer posts →