AAA configuration on the 9800 WLC

I’m on the fence as to whether the new 9800’s AAA configuration is easier or not, when compared to the AireOS controllers.

 

In this blog, I am creating the config for the new 9800 controllers.  Six WLANs – just to use for example’s sake.  We would never create this many in production!

 

We need to create RADIUS server instances.  I want to use ranges of ISE instances since groups of WLANs often use the same instances.

 

Instances 1-9 can be for CorpWiFi, MedGear and Voice WLANs

Instances 10-19 can be for BYOD and Contractor

Instances 20-29 can be for Guest.

 

This way when we want to add another auth&acct instance for CorpWiFi, we can just pick index 3 everywhere.  We can even use a template to deploy it as index 3 with DNAC in the future.  We can continue to recycle instances 1-9 for the same group of WLANs.  Same goes for the other groups of WLANs.

 

*note*  The 9800 does things differently than the 5508, where it had an accounting instance and an authentication instance.  The 9800’s config has the accounting and authorization as a combined configuration.  At least that’s my understanding.  I tried to make them separate, to no avail.

 

I am using a naming convention RADSER_AUTH_ACCT_X, (X=index number).  This convention initially came from the config translator, and I liked it so I kept it around.

 

radius server RADSER_AUTH_ACCT_1  ß CorpWiFi, MedGear and Voice

address ipv4 10.44.17.210 auth-port 1812 acct-port 1813

key Secret_Key123

!

radius server RADSER_AUTH_ACCT_2 ß CorpWiFi, MedGear and Voice

address ipv4 10.155.214.39 auth-port 1812 acct-port 1813

key Secret_Key123

!

radius server RADSER_AUTH_ACCT_11ß BYOD and Contractor

address ipv4 10.151.6.102 auth-port 1812 acct-port 1813

key Secret_Key123

!

radius server RADSER_AUTH_ACCT_12ß BYOD and Contractor

address ipv4 10.224.5.4 auth-port 1812 acct-port 1813

key Secret_Key123

!

radius server RADSER_AUTH_ACCT_21ß Guest

address ipv4 10.224.5.6 auth-port 1812 acct-port 1813

key Secret_Key123

!

radius server RADSER_AUTH_ACCT_22ß Guest 

address ipv4 10.224.5.6 auth-port 1812 acct-port 1813

key Secret_Key123

!

>>>>> Now we group the RADIUS authorization and accounting into AAA Groups for simplicity<<<<<

 

aaa group server radius RAD_GRP_AUTH_ACCT_CorpWiFi  ß This creates a group that does authentication and accounting

server name RADSER_AUTH_ACCT_1

server name RADSER_AUTH_ACCT_2

!

aaa group server radius RAD_GRP_AUTH_ACCT_MedGear

server name RADSER_AUTH_ACCT_1

server name RADSER_AUTH_ACCT_2

!

aaa group server radius RAD_GRP_AUTH_ACCT_Voice

server name RADSER_AUTH_ACCT_1

server name RADSER_AUTH_ACCT_2

!

aaa group server radius RAD_GRP_AUTH_ACCT_BYOD

server name RADSER_AUTH_ACCT_11

server name RADSER_AUTH_ACCT_12

!

aaa group server radius RAD_GRP_AUTH_ACCT_Contractor

server name RADSER_AUTH_ACCT_11

server name RADSER_AUTH_ACCT_12

!

aaa group server radius RAD_GRP_AUTH_ACCT_SHGuestNet

server name RADSER_AUTH_ACCT_21

server name RADSER_AUTH_ACCT_22

 

Now we create an 802.1x authentication groups using DOT1X_AUTH_CorpWiFi nomenclature for simplicity and point it to the similarly named RADIUS auth & accounting group. 

 

aaa authentication dot1x DOT1X_AUTH_CorpWiFi group RAD_GRP_AUTH_ACCT_CorpWiFi

aaa authentication dot1x DOT1X_AUTH_MedGear group RAD_GRP_AUTH_ACCT_MedGear

aaa authentication dot1x DOT1X_AUTH_Voice group RAD_GRP_AUTH_ACCT_Voice

aaa authentication dot1x DOT1X_AUTH_BYOD group RAD_GRP_AUTH_ACCT_BYOD

aaa authentication dot1x DOT1X_AUTH_Contractor group RAD_GRP_AUTH_ACCT_Contractor

aaa authorization network MAB_AUTH_SHGuestNet group RAD_GRP_AUTH_ACCT_SHGuestNet

!

Now we create an 802.1x accounting group using ACCT_LIST_POL_PROF_CorpWiFi nomenclature for simplicity and point it to the RADIUS auth & accounting group.   Why POL_PROF in the nomenclature?  Because the accounting list is referenced in the WLAN’s Profile Policy, not the WLAN config itself.

 

aaa accounting identity ACCT_LIST_POL_PROF_CorpWiFi start-stop group RAD_GRP_AUTH_ACCT_CorpWiFi (see how we are re-using this, instead of creating all new config lines)

aaa accounting identity ACCT_LIST_POL_PROF_MedGear start-stop group RAD_GRP_AUTH_ACCT_MedGear

aaa accounting identity ACCT_LIST_POL_PROF_Voice start-stop group RAD_GRP_AUTH_ACCT_Voice

aaa accounting identity ACCT_LIST_POL_PROF_SHGuesNet start-stop group RAD_GRP_AUTH_ACCT_BYOD

aaa accounting identity ACCT_LIST_POL_PROF_BYOD start-stop group RAD_GRP_AUTH_ACCT_Contractor

aaa accounting identity ACCT_LIST_POL_PROF_Contractor start-stop group RAD_GRP_AUTH_ACCT_SHGuestNet

 

Now we reference the authentication group in the WLAN itself:

 

wlan CorpWiFi 1 CorpWiFi

<output omitted>

security dot1x authentication-list DOT1X_AUTH_CorpWiFi

 no shutdown

 

Now we reference the accounting group in the WLAN Profile Policy for CorpWiFi

 

wireless profile policy POL_PROF_CorpWiFi

<output omitted>

aaa-override

accounting-list ACCT_LIST_POL_PROF_CorpWiFi

description "Policy profile for CorpWiFi"

no shutdown

 

I know it seems like a lot, but I chose six instances of ISE to help illustrate how things are grouped and mapped.

 

Do you think the old way was easier?  Which way do you think scales more?

 

 

Virus-free.www.avg.com

How to create tunnel between Cisco 5508 (IRCM) and 9800

First, we put the IRCM image on the 5508.

 

 

 

 

 

 

Here are the test APs on the Junktown controller:

 

 

 

 

Here is the mobility configuration – this builds the tunnel between the 5508 running IRCM code and the 9800:

 

Password:********

(jkn001-011-wc03) >config mobility group member add 4c:ec:0f:2a:a3:ab 10.64.25.5 JKN encrypt enable

(jkn001-011-wc03) >config mobility group member data-dtls 4c:ec:0f:2a:a3:ab disable

(jkn001-011-wc03) >save config

Are you sure you want to save? (y/n) y

Configuration Saved!

(jkn001-011-wc03) >

 

 

 

Here is the config on the 9800:

 

jkn001-011-wc01(config)#wireless mobility group name JKN

Changing mobility domain name may disrupt connectivity for clients on 11r or Adaptive 11r capable active WLANs

Are you sure you want to continue? (y/n)[y]: y

jkn001-011-wc01(config)#

jkn001-011-wc01(config)# wireless mobility group member mac-address 4c00.8271.5040 ip 10.64.25.15 public-ip 10.64.25.15 group JKN

jkn001-011-wc01(config)#

 

Then the tunnel comes up:

 

*Aug 8 14:26:56.744: %MM_NODE_LOG-6-MEMBER_ADDED: Chassis 1 R0/0: mobilityd: Adding Mobility member (IP: IP: 10.64.25.15: JKN)

*Aug 8 14:27:15.588: %SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as tdennehy on vty1

*Aug 8 14:27:17.803: %MM_NODE_LOG-5-KEEP_ALIVE: Chassis 1 R0/0: mobilityd: Mobility Data tunnel to peer IP: 10.64.25.15 changed state to UP

*Aug 8 14:27:31.782: %MM_INFRA_LOG-3-RECV_FAILED: Chassis 1 R0/0: mobilityd: Unable to receive mobility message aplist_update from ipv4: 10.64.25.15 . reason: Peer link is down

*Aug 8 14:28:17.802: %MM_NODE_LOG-5-KEEP_ALIVE: Chassis 1 R0/0: mobilityd: Mobility Control tunnel to peer IP: 10.64.25.15 changed state to UP

*Aug 8 14:29:03.353: %SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as tdennehy on vty1

jkn001-011-wc01(config)

How to get the base radio MAC while staging Aruba APs

 When staging/priming APs for deployment, some folks do it ahead of the actual cutover/go-live date so that a cutover runs smoothly.

APs that are staged are booted up on a bench controller, labeled, named, and joined to a controller to verify its operation and burn them in, so-to-speak.  They are placed back in boxes and handed over to low voltage Contractors who install and patch them, and they should headlessly come online.

After all, not all APs can be easily accessed during a go-live, some are in hard to reach spaces, where man lifts may be needed, ICU patient rooms in hospitals, clean rooms where technicians may not wander in at any moment to work on an AP that's having problems.

Priming APs helps eliminate some of the issues come go-live.

Communication badges, such as Vocera system, need the base radio mac address and the AP's hostname, depending on how the system is configured.  If you would like to hand over the AP names and base radio macs of the APs to the Vocera Administrators, this is how it might be accomplished.  This is a rudimentary way of getting the information without having the AP powered up and online, since the mac address is on a label on the access point.

If I were to do this for thousands of access points (and that is my goal) I would like to build a macro enabled Excel spreadsheet and scan the mac address barcode on the physical AP into a spreadsheet and have a macro do the math for me to output the base radio mac.

Credits:  Thanks to @CaNerdIan for the pointers, and to this fella on the Airheads blog. 

By AnandKumar Sukumar   How is the BSSID derived from the Access Point ethernet MAC address? (arubanetworks.com)

First, we scan the mac address from the label.

We all agree the Wired MAC Address is  d0:d3:e0:c1:97:48

Take the last five of the MAC, which is 1:97:48, and remove the colons.

19748

Use this website to convert the hex (19748) to binary:

Take the output,  00011001011101001000, and tack on four zeros.

000110010111010010000000

Now XOR the first four with 1000

000110010111010010000000

XOR

1000

--------------------

100110010111010010000000

If you have forgotten all that math, you can see it right here:

Now we have to convert the sum of that binary XOR back to binary.  (I used this website)

Now, we scroll back up to the top and look at the OUI of the wired mac, which is d0:d3:e0.

We have to put the mac address together, so we combine d0:d3:e0 with 997480, to get d0:d3:e0:99:74:80

How do we know its right, though?

We can look at the controller and see it:

There you have it.  The base radio mac address can be derived from the wired mac address.  I must admit that I didn't think this was possible, as the mac addresses did not look even remotely related to one another.

The real solution, moving forward, would be to have some sort of spreadsheet that the mac could be scanned in, and have a macro do all of this math for us and output a column with the AP hostname and base radio mac.

If anyone has done this, please feel free to share with the community.

Why doesn't 802.11a data show up when surveying with Ekahau Pro and an iPad?

Why doesn't my 802.11a data show up when surveying with Ekahau Pro and an iPad?

For over a year now, I have been plagued by an issue when troubleshooting/upgrading WLANs.  The issue is simple - when I step into a site with little to no documentation, I start off with a Validation Survey to see what the environment looks like - and it helps to find APs that might be lurking behind filing cabinets, on desks, on book shelves or sitting on top of ceiling tiles - or my favorite, which is hanging on the wall like a clock.  When I find them, I always ask my colleague what time it is.  The reply is always, "it's time to get that AP mounted properly!".  Please don't put ceiling mount APs where they don't belong!

Back to the issue regarding the validation survey and the "Mystery of the Missing 802.11a 5GHz data".  The first time it happened, I thought I had done something wrong.  Surely I had misconfigured something on the iPad somewhere.  I walked a site that had both 1131s and 3502s on the ceilings and I noticed a pretty green map on the 3502i series side of the house.  I kept walking, not looking at the data as I thought it was collecting fine.  When I returned to the office, I noticed when reviewing the file on my desktop that the 5GHz 802.11a appeared to be missing where the 1131s were.  I asked around and nobody had a great answer as to why this is happening.  After all, Ekahau Pro is a WLAN survey platform and there are a bazillion customers using it and nobody has seen my issue.  I was convinced it was something I was doing.

This is what the floor looks like from the documentation/monitoring side of the deployment:

It is difficult to see, but that is the floor with the APs on it, showing the APs with the channel and power levels on them.  They are Cisco 1131s (they have internal antennas) and are dual band access points with 802.11a and 802.11g.  They are not 802.11n or greater.  The graphic show both radios online, and their power and channel selection.

A few weeks ago, I went to a site I needed to schedule and did a quick test run with a laptop and Sidekick as I knew the site had 1131s on the ceiling.  I walked the site with my laptop and Sidekick for five minutes and verified I had both bands in a very small area, and then made an appointment to walk the facility with the building supervisor.

I changed one thing the following week when I walked it.  I saved the project to Ekahau Cloud, and walked it with my iPad and Sidekick.  When I saw the results below, I started to wonder if the problem was with the Ekahau Cloud/iPad/Sidekick combination.  Here's what the first floor validation looks like with that combination of survey and only that floor's APs selected: (three APs in the middle were upgraded to 802.11n and they show up)

As you can see above, there is no 802.11a data at all from the 802.11a radios.

Next, I walked the floor with Ekahau/Laptop/Sidekick (project saved on SK) combination.  See graphic below.  Here's what the first floor validation looks like with that combination of survey and only that floor's APs selected.  Since we all know battery life is important (and we had already walked the entire second floor with this combination, we decided to only do this half.  As you can see, the 5 GHz 802.11a data shows up when we use the Ekahau/Laptop/Sidekick combination.

Next, I walked the floor with Ekahau/iPad/Sidekick (project saved on SK) combination.  See graphic below.  Here's what the first floor validation looks like with that combination of survey and only that floor's APs selected.  As you can see, the 5 GHz 802.11a data does not show up when we use the Ekahau/iPad/Sidekick combination.

Finally, I turned to a trusted old friend, AirMagnet Survey Pro.  I used the Edimax AC1750 adpater and walked the site yet again.  As you can see from the graphic below, the 5GHz spectrum is correctly mapped out for me.

My conclusion is that the iPad will not gather 5GHz (802.11a) data from an 802.11a radio.  I do not mean 802.11a/n or 802.11a/n/ac/ax radio.  I think I have ruled out the issue as an Ekahau Cloud issue, as I saved the projects to the Sidekick for this test.  It looks as if the iPad is the culprit.

I looked at some older surveys (pre-iPad) and verified that 802.11a data displays properly.

I feel that being able to see 802.11a data is important.  Even if you don't have older protocol APs in your network, your neighbor might have them and when you survey, you won't pick them up if you use the iPad.  I'm just going to have to use a laptop and Sidekick.  I'm also wondering if I can get a refund for the iPad/cloud, as it is not useful to me anymore.

How to reset your Ekahau visualizations (and why you might want to check them)

How to reset your Ekahau visualizations (and why you might want to check them)

Eighteen months ago I was asked to give a ballpark number of access points for a small campus of buildings consisting of multiple floor each.  After a quick glance at the floor plans I knew I had to do some sort of predictive design in order to get a ballpark number, and luckily some produced some CAD files.

I created the project and went to site verify the walls were accurately placed, marked off where I could not place access points, and went back to my desk and created the model so I could give the project manager a ballpark estimate.

Eighteen months later, I was asked to do the same thing since the first project had not taken flight and this time the project manager stated they needed a voice implementation.  Probably a good thing the first project didn’t get any traction since that design would not have worked for VoWi-Fi.

When I opened the project up, I noticed something was off.  Note: if you are following along, I am using version 10.1

First of all, my signal strength is set to Primary.  Yes, the word “Primary” is not there, but it is implied. (to the best of my knowledge, anyway)  Notice the bottom middle AP does not have any heat map around it?  Neither does the AP in the middle.  That was red flag #1.

I then turned my visualization to the 2.4 GHz, which I usually do not pay that much attention to since I usually concentrate on 5 GHz WLAN designs.  Same thing – the middle AP doesn’t have any “heat” on the heat map, and I didn’t turn any radios off yet. 

Then I selected “Both”, and I now knew something was wrong.  If you look at the bottom middle AP in both visualizations above, there is no green above the bottom row middle AP, yet there is in the “Both” visualization.  How can that be?  If “Both” is both 2.4 GHz and 5GHz painted on the monitor at the same time, how can I have green where there is none on either of the last two visualizations?

When seeing this, I started questioning myself.  I started asking myself if I fully understood what exactly these views meant.  I asked multiple people who were all Ekahau Masters if their visualizations were accurate, and they said they were.  But they were not looking at my project file. I honestly started doubting myself about my knowledge of these visualizations, and then came to the conclusion that my knowledge was accurate and there was either something wrong with my project file or the software.  Then I started checking other views within the software – specifically the “Secondary Signal Strength” view.

Under this view, I selected two APs and the 2.5 GHz and came up with something that I thought I might see in real life:

Then I selected 5 GHz and saw this view:

Then I did the unthinkable.  I clicked on “Both”.  I rarely, if ever, use this view:

I thought to myself – WHAT?  How can that be?  That is supposed to be where these two APs overlap each other with both bands on – basically, a sum of the two graphics above it.  This made absolutely no sense to me!  During all of this, I opened two support tickets with Ekahau, but after a day of not hearing from anyone, I figured they were closed due to a holiday that I am unaware of.

Then I selected one AP, kept it on Secondary, and selected the 2.4 GHz visualization: (looks good)

Next I selected 5 GHz and didn’t see anything there either. Again, looks good.

Then I selected Both, under Secondary, and the single AP:

That is not what I expected to see.  Why?  Because from the Primary & Selected & 2.4 GHz, I don’t see anything on the heat map:

Let’s look at the 5 GHz: (again, nothing)

Therefore, how could the Secondary Signal Strength & Selected & Both with the single AP display anything?

Now I knew something wasn’t working properly.  I went back to Secondary Signal Strength & Selected & Both and looked at it again:

I thought to myself, “The coverage area is too large”  and then I was reminded that when Secondary is selected in conjunction with “Both” and only one AP is being selected, that “Both” will display the area where both 2.4 GHz and 5 GHz reside from that one AP.

That is not what I expected to see because, in theory, that should be the same view as Signal Strength & Selected AP & Both, and that same AP selected.  And then I remembered I was on Secondary and it was displaying out to -70.  If we slide the Primary out to -70 and compare, they should, in theory, be the same.

They look pretty close too me. 

I have now come to the conclusion something is messed up with either my project or the software.  I asked several awesome Wi-Fi Engineers (thank you, you  know who you are) and I was informed that we can “reset” the views within Ekahau Pro.  I figured “what else have I got to lose?”.

In order to do this, go to “View” in the bar across the top.  Scroll all the way to the bottom, and look for View Settings, then Restore View Settings to Original Defaults:

I clicked through the “Are you sure” type of messages and 15 seconds later, my visualizations are all fixed.  Here’s a re-graph of one of the first heat maps in this post, and that is what I expected to see the first time.

One thing is for sure – I am going to keep a closer eye on my visualizations.  I’m not exactly how the visualizations got “broken”, but they did, and I am thinking about doing the reset on every file as a preventive maintenance.  And now you know how to fix it.

Using the Service Port on Cisco 3504 WLC

When setting up new Cisco WLAN controllers, I find it easier to set one up, get it working properly and then copy the configuration off of it and put it on another WLC and change what needs to be changed in order for it to become a backup controller.  You know – the IP addresses need to change, hostname, and then set up the mobility configuration.  Everything else as well – I’m sure I am forgetting to mention something.

 

My most recent pair of WLCs threw a curve ball.  I set up the first 3504 WLC via the CLI while on the bench with a very basic config, then copied my base config file to it via TFTP.  Everything went well, and the system rebooted.  After relogging in via CLI, I tested the Service Port’s IP config with a patch cable to my ethernet port on my laptop.  I tried to browse to it, and nothing happened.

 

I pinged the WLC, and the service port responded.  I then SSH’d into the service port and it worked perfectly.  But no web browsing!

I went home and came back to work the next day, and I could browse to the WLC.  Nothing changed.  I thought that was a bit strange.

 

After getting the WLC all setup like I wanted, I copied the controller’s config off the WLC via TFTP and began to set up the backup controller’s configuration.  Everything was successful, and I changed what needed to be changed via CLI, saved the config and rebooted it.  When it came up, there was no browsing – same as the first WLC.  I looked at the system time, and it was set properly, however it was not connected to the internet and the NTP configuration was not in use.

 

After asking a few friends and googling around, I started trying different things one by one.  I found one post where someone had to regenerate the webauth certificate (for something else), and I also found in that same post there was a command to regenerate the webadmin certificate as well.

 

I ran the “config certificate generate webadmin” command and executed quickly, however it did not appear to do anything.  I saved the config and typed “reset system” and it rebooted.  When it came back up, I could browse to the WLC.

 

 

I honestly have absolutely no idea why this worked, but it did.  I do not know why the first WLC worked the next day, but not the first day when I configured it.  If my friend Sam Clement’s theory was correct, it was the NTP setting – and I suspect it had not timed out.  My timeout was set to one day, and I do not know if more than 24 hours had passed when I checked the first controller again and it magically worked.

 

I hope this helps someone, since when I searched, I found no references to anyone else having this same issue.

 

 

 

 

One of the coolest features of the netAlly EtherScope nXG is being able to charge it via PoE.  We’ve all been there – using your favorite tool of choice, and you notice you are low on battery – usually at an inopportune time in most cases. 

Those days are in the rearview mirror with the netAlly EtherScope nXG.  The EtherScope nXG has the ability to be charged with the charging cable that comes with the unit, but also via PoE. 

In this quick tutorial, I am going to show you how to configure it to charge via a class 4 PoE port.  You’ll know when you have it configured properly when you see the charging “lightning bolt” in the battery icon in the status bar in the upper right hand side of unit, as seen below:

In the upper left of the EtherScope nXG, you see the AutoTest icon.  You’ll need to press that button (you have likely done this many times by the time you read this) after plugging in the Ethernet port into a Class 4 PoE switch – just like the photo above.  That will run the AutoTest.  Here are my results below.  Note: I plugged into a not-so-smart switch port, so that is why we see “Nearest Switch Not Found”.

In the upper left, you will see three horizontal lines that are commonly referred to as the “hamburger”.   Go ahead and press that and the following screen will appear.  Look for General Settings down near the bottom and tap that with your finger.  

Near the bottom, you will see “Charge battery via PoE”.  It will likely not be enabled if you have determined that your EtherScope nXG is not charging via PoE.  Simply tap that with your finger and enable it, then press the “back” triangle in the lower left, under the word “Management”.

 Now that you have pressed the “back” arrow button, you should be at the screen below:

You will now configure the unit to expect Class 4 PoE power.  Press the Settings icon (gear) next to the word START.  The following screen appears:

Tap the Wired Profile card somewhere in the middle of the card – in that empty space.  That will bring you to the settings in the Wired Profile as seen below:

As you can see, the PoE Test is set to Class 4, which will allow the EtherScope nXG to be charged via PoE.  I will go through the motions of setting it to Class 4 in case the unit is set to something else – which will likely not allow the unit to be charged via PoE.  From this point on, we will assume the unit showed PoE Test Class 1.

Press the PoE Test card and it will bring you to the PoE test page as shown below.  The PoE Test should be enabled, and needs to be set to Class 4 on the Powered Device Class card.  Since we are assuming it is set to Class 1, press the Powered Device Class card.

Once the Powered Device Class card has been pressed, the Powered Device Class screen should pop up, allowing the selection of Class 4 as shown below:

Select Class 4 and press OK.  Tap the “back” triangle in the lower left four times and it should bring you to the main screen.  If the EtherScope nXG is plugged into PoE Class 4 power, you should now see the unit charging – and now you’re ready to enjoy this awesome feature!