Quickly get your 91xx APs to join a 9800 series controller (and start broadcasting)

I was looking for an easy way to get the 91xx series APs to join a 9800 WLC and start broadcasting the WLAN immediately.

 

Let me just say that I prime the APs.  Or have someone else do it - I want to know the AP works, is labeled, and is properly named so when the low voltage guys install it, the AP just starts working.

 

First, I built a macro spreadsheet to scan the MAC address of the access point, and created columns for my hostnames, IPs, etc.  If you want the spreadsheet, just PM me and I'll send a "working" copy to you.  I'm always trying to improve it...  :)

 

My spreadsheet creates this output, so I simply copy and paste each column into the controller CLI and viola!!! 

 

ap name AP6849.92D1.1C90 name xyz148-011-ap01	ap name xyz148-011-ap01 con pri abc001-011-wc01 10.64.25.5
ap name AP6849.92D1.0A40 name xyz148-011-ap02	ap name xyz148-011-ap02 con pri abc001-011-wc01 10.64.25.5
ap name AP6849.92D1.1490 name xyz148-011-ap03	ap name xyz148-011-ap03 con pri abc001-011-wc01 10.64.25.5
ap name AP6849.92CF.0C10 name xyz148-011-ap04	ap name xyz148-011-ap04 con pri abc001-011-wc01 10.64.25.5
ap name AP6849.92CF.1E70 name xyz148-011-ap05	ap name xyz148-011-ap05 con pri abc001-011-wc01 10.64.25.5
ap name AP6849.92CF.1EB0 name xyz148-011-ap06	ap name xyz148-011-ap06 con pri abc001-011-wc01 10.64.25.5
ap name AP6849.92CF.1DD0 name xyz148-011-ap07	ap name xyz148-011-ap07 con pri abc001-011-wc01 10.64.25.5

 

 

Next,  I joined 7 APs to the controller and renamed them and gave them their primary controller config.  They join the controller, but they won’t start broadcasting because they won’t get the tags. Translation - it's 3am and my phone rings because "the Wi-Fi is DOWN!!!"

 

What's an easy way to avoid this cataclysmic catastrophe?  I don't want to be online, copying and pasting mac addresses into the controller at 3am while low voltage folks are doing their thing.

 

The answer is filters!

 

https://www.cisco.com/c/en/us/td/docs/wireless/con/9800/config-guide/newconfigmodel/b_catalyst-9800-configuration-model/m_creating-an-ap-filter.html

 

I built this filter on the controller, since we are going to install 7 access points in small facility and point these APs to the 9800.

 

I added this to the config:

 

ap filter name xyz148

ap name-regex xyz148* <- This is a regular expression, filtering on the first part of the AP name

tag policy abc001_Policy_Tag  <-These are tags configured in the controller

tag rf abc001_RF_Tag <-These are tags configured in the controller

tag site abc001_Site_Tag <-These are tags configured in the controller

 

What this does is match all the AP names from access points to a filter, and automagically sets all three tags.  That translates to the AP starts broadcasting, and your phone doesn't ring!

 

There was only one problem, though.  It didn't work!  I was NOT happy!  Thinking hours of work went down the drain, I started digging.

 

abc001-011-wc01#sho ap summary

Number of APs: 8

 

CC = Country Code

RD = Regulatory Domain

 

AP Name                          Slots AP Model             Ethernet MAC   Radio MAC      CC   RD   IP Address                                State        Location

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

xyz148-011-ap04                  3     CW9166I-B            6849.92cf.0c10 5c64.f1c0.09e0 US   -B   10.64.25.127                              Registered   default location

xyz148-011-ap07                  3     CW9166I-B            6849.92cf.1dd0 5c64.f1c0.2d60 US   -B   10.64.25.124                              Registered   default location

xyz148-011-ap05                  3     CW9166I-B            6849.92cf.1e70 5c64.f1c0.2ea0 US   -B   10.64.25.126                              Registered   default location

xyz148-011-ap06                  3     CW9166I-B            6849.92cf.1eb0 5c64.f1c0.2f20 US   -B   10.64.25.125                              Registered   default location

abc001-011-ap01                  3     CW9166I-B            6849.92cf.f810 5c64.f1c1.6ce0 US   -B   10.64.25.116                              Registered   default location  ß This one another filter and it works.  The others do not bcast.

xyz148-011-ap02                  3     CW9166I-B            6849.92d1.0a40 90e9.5e9a.0640 US   -B   10.64.25.123                              Registered   default location

xyz148-011-ap03                  3     CW9166I-B            6849.92d1.1490 90e9.5e9a.1ae0 US   -B   10.64.25.128                              Registered   default location

xyz148-011-ap01                  3     CW9166I-B            6849.92d1.1c90 90e9.5e9a.2ae0 US   -B   10.64.25.129                              Registered   default location

 

Dig a little more...

 

abc001-011-wc01#sho ap filters all

Filter Name                       regex                               Policy Tag                        RF Tag                            Site Tag

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

abc001                            abc001*                             abc001_Policy_Tag                 abc001_RF_Tag                     abc001_Site_Tag

abc101                            abc101*                             abc101_Policy_Tag                 abc101_RF_Tag                     abc101_Site_Tag

xyz148                            xyz148*                             abc001_Policy_Tag                 abc001_RF_Tag                     abc001_Site_Tag

 

abc001-011-wc01#sho ap filters active

Priority   Filter Name                       regex                               Policy Tag                        RF Tag                            Site Tag

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

1          abc001                            abc001*                             abc001_Policy_Tag                 abc001_RF_Tag                     abc001_Site_Tag

2          abc101                            abc101*                             abc101_Policy_Tag                 abc101_RF_Tag                     abc101_Site_Tag

 

My filter for the xyz148 named access points don't work?  I created the filter just like the other one that I configured last week. (via GUI, and am now trying to script things)

 

Turns out, I forgot this one step.  After creating a filter, there is another step, and that is creating a filter priority.  I know, I don't understand it either, but I did it anyway...  because "a filter without a priority is not active".  It's always those little gotchas in the small print!

 

 

There we have it.  Simply put, name your APs on the bench on a WLC running the same code you have in production.  Scan them, label them, and CLI config them and when they hit the WLC, they'll start broadcasting.  You'll have your nights and weekend back.  If you get paid by the hour, pretent you never saw this post.

 

 

 

 

 

 

 

 

 

Virus-free.www.avg.com

Configuring SSO redundancy on the Cisco 9800

In this blog, I will setup link redundancy to the switch, using two fiber uplinks, and then configure SSO on the standalone 9800 series controller.

 

First, I create a port channel and then configure the uplinks on the Primary 9800 controller.

 

interface Port-channel7

description edh001-011-wc01

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

logging event bundle-status

!

interface TenGigabitEthernet0/0/0

description WLAN Controller trunk uplink

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

no negotiation auto

channel-group 7 mode on

!

interface TenGigabitEthernet0/0/1

description WLAN Controller trunk uplink

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

no negotiation auto

channel-group 7 mode on

!

Now I create the other end of the configuration – which happens to be the core switch:

!

interface Port-channel7

description edh001-011-wc01

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

logging event bundle-status

!

interface TenGigabitEthernet1/1/1

description edh001-011-wc01

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

logging event bundle-status

channel-group 7 mode on

!

interface TenGigabitEthernet1/1/2

description edh001-011-wc01

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

logging event bundle-status

channel-group 7 mode on

!

Next, I create the configuration on the core switch to talk to the second, “base configured” 9800 series controller that we will put into SSO.

!

interface Port-channel8

description edh001-011-wc01

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

logging event bundle-status

!

interface TenGigabitEthernet1/1/3

description edh001-011-wc01-

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

logging event bundle-status

channel-group 8 mode on

!

interface TenGigabitEthernet1/1/4

description edh001-011-wc01

switchport trunk allowed vlan 25,34,300,2346,3200,3201

switchport mode trunk

switchport nonegotiate

logging event trunk-status

logging event bundle-status

channel-group 8 mode on

!

 

Now back to the 9800 series controller, the one that we will call Primary.  It has a configuration on it and it basically a standalone controller.

I am going to configure this controller as the primary, since I just want a specific controller to be the primary.  A higher chassis = higher priority.

 

edh001-011-wc01#chassis 1 renumber 2

WARNING: Changing the switch number may result in a configuration change for that switch.  The interface configuration associated with the old switch number will remain as a provisioned configuration. New Switch Number will be effective after next reboot. Do you want to continue?[y/n]? [yes]: yes  ß Note that I have not rebooted it yet!!!

edh001-011-wc01#sho chassis

Chassis/Stack Mac Address : 4cec.0f2a.a3a0 - Local Mac Address

Mac persistency wait time: Indefinite

Local Redundancy Port Type: Twisted Pair

                                             H/W   Current

Chassis#   Role    Mac Address     Priority Version  State                 IP

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

*1       Active   4cec.0f2a.a3a0     1      V02     Ready                0.0.0.0 ß Note that I have not rebooted it yet!!!

 

edh001-011-wc01#chassis 1 priority 2

edh001-011-wc01#sho chassis

Chassis/Stack Mac Address : 4cec.0f2a.a3a0 - Local Mac Address

Mac persistency wait time: Indefinite

Local Redundancy Port Type: Twisted Pair

                                             H/W   Current

Chassis#   Role    Mac Address     Priority Version  State                 IP

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

*1       Active   4cec.0f2a.a3a0     2      V02     Ready                0.0.0.0 ß Note that I have not rebooted it yet!!!

 

A little heads up.  I’m running 17.9.3, and I was going to use IP address of 169.254.5.6, since the management vlan (25) is 10.64.25.x.  This was an epic failure and when I tried to configure it I got my hand slapped:

!!! configuring 169.254.X.Y(f) is not allowed

Therefore, don’t waste your time.  Grab two IP addresses off your management subnet and use them for SSO and be done with it.

*remember*, this is now chassis two, not one.  ß Note that I have not rebooted it yet!!!  When I reboot it, it will be chassis 2.  So we are configuring it now as if it is chassis 2.  If you are confused, just reboot your controller, I suppose.

 

edh001-011-wc01(config)#redun-management interface vlan 25 chassis 2 address 10.64.25.253 chassis 1 address 10.64.25.254

edh001-011-wc01#wr mem

 

=========== NOW MOVING TO THE OTHER CONTROLLER – THE ONE THAT WILL MAKE THEM AN SSO PAIR============

 

Now, let’s go to the SSO controller.  I put a base config on it which consists of an IP address on the g0 so I could install the same exact code on it that is running on the Primary 9800 controller.

Armed with a console cable, I slowly approach the controller and quickly plug it in to the console port.  Success!

*create a port channel and then configure the uplinks on the 9800 controller* use the steps at the beginning of this HowTo.

<output omitted>

edh001-011-wc02(config)#

edh001-011-wc02(config)#redun-management interface vlan 25 chassis 1 address 10.64.25.254 chassis 2 address 10.64.25.253

WARNING: Reload HA Chassis for RMI configuration to take effect ß Note this is a subtle hint for me to go BACK to the Primary controller and reboot it. 

*note – this chassis is chassis #1, just like the other one.  We are going to leave this one as chassis #1, per config line above.

 

=========== NOW MOVING TO THE PRIMARY CONTROLLER  (for rebooting purposes) ============

 

edh001-011-wc01#reload

Reload command is being issued on Active unit, this will reload the whole stack

Proceed with reload? [confirm] Y

<output omitted>

 

Now I am going to just paste console outputs from both controllers, since the Primary has rebooted and the SSO pair is successful.  edh001-011-wc01 is Primary, edh001-011-wc01-stby is the standby.

edh001-011-wc01#sho chassis

Chassis/Stack Mac Address : 4cec.0f2a.a3a0 - Local Mac Address

Mac persistency wait time: Indefinite

Local Redundancy Port Type: Twisted Pair

                                             H/W   Current

Chassis#   Role    Mac Address     Priority Version  State                 IP

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

1       Standby  648f.3e83.fb20     1      V02     HA sync in progress  169.254.25.254  ß The standby controller has not synced yet

*2       Active   4cec.0f2a.a3a0     2      V02     Ready                169.254.25.253 ß This is the Primary, recall we renumbered it to chassis 2.

 

#sho chassis

Chassis/Stack Mac Address : 4cec.0f2a.a3a0 - Local Mac Address

Mac persistency wait time: Indefinite

Local Redundancy Port Type: Twisted Pair

                                             H/W   Current

Chassis#   Role    Mac Address     Priority Version  State                 IP

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

1       Standby  648f.3e83.fb20     1      V02     Ready                169.254.25.254ß synchronized

*2       Active   4cec.0f2a.a3a0     2      V02     Ready                169.254.25.253 ß synchronized

 

Now look at the management VLAN’s config:  The secondary IP address has been added to the management VLAN’s configuration.

 

edh001-011-wc01#sho run int vlan 25

Building configuration...

Current configuration : 144 bytes

!

interface Vlan25

description WLAN_MGMT_10.64.25.0

ip address 10.64.25.253 255.255.255.0 secondary

ip address 10.64.25.5 255.255.255.0

end

 

Here’s a trick if you want to be able use console in to the standby controller and issue *some* commands.  I’m not an expert on what commands are available.

 

edh001-011-wc01#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

edh001-011-wc01(config)#

edh001-011-wc01(config)#redundancy

edh001-011-wc01(config-red)#main-cpu

edh001-011-wc01(config-r-mc)#standby console enable

edh001-011-wc01(config-r-mc)#do wr mem

Building configuration...

 

=========== NOW MOVING TO THE SECONDARY CONTROLLER  (to see what commands are available on console) ============

 

Username: admin123

Password: ChangeMe

edh001-011-wc01-stby>ena

Password: PleaseChangeMeNow

 

edh001-011-wc01-stby#sho chassis

Chassis/Stack Mac Address : 4cec.0f2a.a3a0 - Local Mac Address

Mac persistency wait time: Indefinite

Local Redundancy Port Type: Twisted Pair

                                             H/W   Current

Chassis#   Role    Mac Address     Priority Version  State                 IP

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

*1       Standby  648f.3e83.fb20     1      V02     Ready                169.254.25.254

 2       Active   4cec.0f2a.a3a0     2      V02     Ready                169.254.25.253

 

edh001-011-wc01-stby#sho chassis rmi

Chassis/Stack Mac Address : 4cec.0f2a.a3a0 - Local Mac Address

Mac persistency wait time: Indefinite

Local Redundancy Port Type: Twisted Pair

                                             H/W   Current

Chassis#   Role    Mac Address     Priority Version  State                 IP                RMI-IP

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

*1       Standby  648f.3e83.fb20     1      V02     Ready                169.254.25.254     10.64.25.254

 2       Active   4cec.0f2a.a3a0     2      V02     Ready                169.254.25.253     10.64.25.253

edh001-011-wc01-stby#

 

You’re done!  SSO is configured.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Virus-free.www.avg.com

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.