Management Frame Detection?

Nope! But MFD does stand for something even more exciting! Mobility Field Day (3!) is just around the corner! As a long time delegate with a few minutes to burn on the family PTO trip, I thought I’d take a moment to reflect on the upcoming event. As you can see from the Tech Field Day page there are tons of great sponsors lined up. Here is my take on the coming week, the sponsors strengths, weaknesses, and what I’d like to see. In order of presentation:

Arista (http://techfieldday.com/companies/arista-networks/, @AristaNetworks)

Arista has made a splash in the Wi-Fi space with their recent acquisition of Mojo Networks (nee: AirTight). I’m happy to see Mojo get scooped up, especially in the ever diminishing landscape of infrastructure providers especially since they have a strong story about ‘hardware agnostic’ solutions. Their story since the AirTight days has been one of open platforms and this strength has carried them to the success they’ve had so far. Arista has not. Admittedly I’m not a strong Data Center switch guy, but I don’t see a similar story of how the open, commodity hardware platforms with custom ‘better than you’ software on top meshes well with their corporate messaging. I’d love to see some reconciliation on that front, and a clear vision for the Mojo team moving forward. Please spare me the ‘HP acquired Aruba’, ‘Cisco acquired Meraki’, and those companies are fine story. Paint me a genuine story of market leadership backed by strong technical chops that promise to survive the acquisition.

Aruba (http://www.arubanetworks.com/, @ArubaNetworks)

Aruba (a Hewlett Packard Enterprise company) has been touting ‘industry leadership’ on several fronts recently. They have clearly claimed leadership on several fronts including WPA3 and some intriguing messaging around 802.11ax. Their strength is messaging. They do it well, but I fail to see how Aruba single handedly ‘landed’ WPA3 and how their messaging around 802.11ax (buy when *we’re* ready, but not anyone else) is anything more than corporate marketing fluff. I’d love to see how they are helping the industry move forward *as a whole* on more than just ‘standards stuff coming down the road’. Help me understand why Aruba’s implementation of QCA radios is better than someone else’s. Help me understand why their switches brings more value to an enterprise other than an ABC play. Help me understand why end to end networking with the Aruba logo on it is better.

Cisco (http://www.cisco.com/, @Cisco)

Cisco, the 800 lb. gorilla that everyone loves to hate. Cisco is a machine unlike any other. They have critical mass despite themselves and are painting some intriguing messaging around Assurance products that seem to resonate well with the on-premises enterprises. All other networking aside (routing, switching, security, Data Center, etc), Cisco Wi-Fi has seemingly lost its way as of late. Their adoption of QCA radios (CleanAir is awesome, unless they sell an AP without it!), their continued duality around the Meraki acquisition (it’s right when it will land a sale), and the feature gaps as new platforms come online has always stuck in my craw. The 802.11ac wave 2 APCOS change (the OS on the APs) debacle has left many with souring appetites for a monolithic beast of an assurance platform. I’d love to see how Cisco is involved in driving standards (WPA3, 802.11ax) while allowing their ecosystem around CCX fall to the wayside despite not having a standards based equivalent to 100% of those components (DTPC anyone?).

Fortinet (http://fortinet.com/, @Fortinet)

Fortinet (nee: Meru) has always been intriguing to me. If there is a dark horse in the Wi-Fi space, this is it. Out of left field, some strange security company acquired ‘those SCA guys’ which raised more than a few eyebrows in the industry. I’m not super passionate about firewalls so when someone touts that their strong suit is plopping some security stuff onto an already delicate Wi-Fi ecosystem, I get nervous. I’d love to see what Fortinet is doing on the SCA front (other than the occasional corner case deployment). How are you fostering the technology that made Meru, Meru? If you’re going to be the one exception in the CWNP curriculum, own that. Embrace it, get the delegates to see what makes it special. Get into the nuts and bolts of how it works, what makes it tick. Get your radio firmware developer into the room and nerd out with us for a bit. Don’t be afraid to put that unpolished guy on stage that only knows protocol. We love that kind of stuff.

Mist (http://mist.com, @MistSystems)

Mist is on the short list of Wi-Fi only players that I suspect will be acquired soon. Between them and AeroHive, there aren’t many players left and to be fair, Mist came out of nowhere when Cisco ‘spun out’ (my speculation) the previous owners of the AireOS legacy. They claimed virtual BLE was the next big thing, now it’s AI driven Wi-Fi – what’s next? Do they realize that the ‘heritage’ that they claim ownership of has turned off more people than it’s attracted? When someone claims to be at the helm of Cisco Wi-Fi during the Meraki acquisition, or to have the father of controllers (and RRM) in the drivers seat, how is that a compelling story when so many of todays woes are centered around those two topics? I’d like to hear how Mist has those people at the helm, but how they’re not destined to repeat the past. Mist claims to have an AI driven interface but fails to answer some pretty plain english queries. Tell me how Mist is better. How the AI is not just a bunch of if statements. Burning Man Wi-Fi, I hope not!

NETSCOUT (http://www.netscout.com, @NETSCOUT)

NETSCOUT (or is it netscout or NetScout?) has long held the mantle of go to wired insight products and only recently entered into the Wi-Fi foray with the Fluke (nee: AirMagnet) acquisition. They inherited an impressive product in the AirCheck G2, but also a legacy of tools that are, quite frankly, stale. What is next for the G2? Many of us in the industry love our hulk green Wi-Fi diagnostics tool and the G2 v2 additions were welcome. Is there enough left in the AirCheck to hope for a v3? I’d love to see a cleaner picture about link-live and how it plays a role in the beloved AirCheck G2. I’d love to hear a definitive story on the likes of AirMagnet Survey Pro, Wi-Fi Analyzer, Spectrum XT – all of which are *very* stale. Let’s put these to bed or make something of them that the industry can use.

nyansa (http://www.nyansa.com, @Nyansa)

nyansa has been that strange analytics company with the funny name that promises to fix all of our ails through machine learning and comparative analytics. They’re doing some neat things with ‘just a bunch of flows’, but is it enough? It seems like everyone is jumping on the analytics bandwagon now a days, but with the hefty price tag for a point-in-time resolution product, it feels somewhat estranged. Do you know what happens when your help desk has 9 dashboards all with different data in it, and you try to aggregate and correlate it into a meaningful dashboard? Your help desk now has 10 dashboards. I’d love to see why your data is better (of course), but tell me how it gets rid of data I don’t use today, and tell me how it does it at a price point that makes it a no brainer.

Dear reader, what do you want to see? Feel free to reach out to me by comment, or privately, or on twitter before or during the event and I’ll make sure you get a response. Till then, see you at MFD3 on September 12 through the 14th – make sure to tune in at: http://techfieldday.com/event/mfd3/

Advertisements

Meraki gets smart

I’m a fan of antennas. They’re pretty awesome components of Wi-Fi networks and I think they’re one of the most under-appreciated and oft-overlooked components, so when someone introduces a new antenna related technology, I tend to sit up and take notice!

 Recently, Meraki released their new external antenna model APs, the MR42E and MR53E. In the past, if you needed antenna flexibility in a Meraki solution, you had to use their outdoor rated AP. This introduction, in addition to rounding out their AP portfolio, snuck a new innovation into the market that Meraki has dubbed ‘Smart Antennas’. With the promise of auto-identifying an antenna to the AP, I couldn’t not know more about it! One of the more notable aspects of using external antennas is the potential risk to exceed regulatory compliance. While not terribly complex, the risks for getting it wrong could see the Feds breathing down your back – and nobody wants that! In addition to self-identification for compliance reasons, the new models of APs include more connectors than one might otherwise expect – 5 connectors for the MR42E, and 6 for the MR53E! This breaks down to 3 Wi-Fi antennas, 1 security/scan antenna, and 1 BLE/IoT antennas for the MR42E, and the same compliment on the MR53E with one more Wi-Fi antenna to support that 4th spatial stream. Without delving into each individual component, I really wanted to get a feel for if this thing did what it promised it would do, so I hooked them all up to their respective ports:

That’s a lot of cables!

Fired up the AP, claimed the hardware in my dashboard account and went poking on the antenna settings! Sure enough, where you would normally define an antenna, the exact model number of the antenna array I had was shown!

The cloud got it right!

Hoping it wasn’t fluke of some sort, I powered off the AP, disconnected them all, and tried again. Sure enough, this time, the dashboard presented me with the expected drop down list of available antennas.

The cloud still wants to help out.

I was impressed, it was magic, it worked automatically and wonderfully – and I had to know how. One screwdriver later (the tool, not the drink), I had done the unthinkable, and performed the ill-advised dissection of the shiny new antenna looking for something out of place:

No stranger to the inside of an antenna, the culprit jumped out at me pretty readily:

What appears to be a Maxim Integrated DS2431 1-wire EEPROM was sitting inline just before an antenna element. I traced it back to the connector and found it belonged to the externally-labeled IoT connector:

So, I dutifully connected just the IoT port to the AP, fired it up and viola! The dashboard indicated that the antenna was identified properly despite the fact that only 1 of the 6 connections was attached. This seems to reinforce that Meraki has indeed found a pretty intuitive way to integrate a digital component onto an analog line (as opposed to Cisco that has actual digital connectors in the DART) for a one-time polling of the antenna ID. This was further reinforced by booting the AP without the IoT port connected (so it did not identify the antenna correctly) and then re-attaching it without powering down the AP. After a day of uptime, the AP never properly re-identified it’s antenna. This means that, if you’re using the Meraki smart antenna solution:

  1. Make sure that the antenna cables are attached to the proper port using the silkscreen indicator on the RP-TNC connectors
  2. Make sure that if you change any antenna ports (especially the IoT port), you should reboot the AP so it can properly identify itself to the AP, and subsequently the cloud

It remains to be seen what kind of ecosystem Meraki intends to develop with 3rd party antenna developers, but rest assured, if you want to use a 3rd party antenna today on these new Meraki APs, you certainly can – you just need to log into the dashboard and make sure you pick the equivalent Meraki antenna that closest matches the gain of your 3rd party antenna.

Hands on the Cisco 3504 WLC

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.

IMG_8526.JPG

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.

IMG_8527.JPG

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.

IMG_8530.JPG

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.

IMG_8528.JPG

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.

IMG_8525.JPG

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.

Musings on Multigigabit and APeX

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.

Or HDK for short.

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!

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.

Cisco Wave2 site survey how-to

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

All about DART

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!

All covered up!

DART revealed!

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

Hyperlocation with DART

DART on Hyperlocation Exposed!

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!

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!

DART to RP-TNC Cable!

Fully assembled!

Fully assembled!

For existing RP-TNC based antennas

For existing RP-TNC based antennas

On the cable end!

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

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

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.

With DART connector on edge.

Note the DART connector on the left.

Note the DART connector on the left.

One in one hundred and fifty three quintillion.

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