How to make your Ekahau Word deliverable smaller

When you are running a template for a deliverable in Ekahau, the file can be massive.  I have seen them as large as 7 GB.  That’s not a typo.  If you do a validation and the workflow has 500 pictures of APs and other things worth documenting, the validation file (.esx) can be a GB or more.

 

When it produces a Word file that’s several gigabytes in size, it makes it difficult to manage.  The file crashes Word, and the last ten minutes’ worth of edits evaporate.

 

Thanks to John Olsthoorn for pointing this out on the Slack channel.

 

Reduce the file size of your Word documents - Microsoft Support

 

When following this document on a Windows box, there are options to save the pictures.

 

 

The original deliverable output from the template is the one highlighted in yellow.  These files can be unstable when this large, however I get deliverables with 500 pictures that are several gigabytes in size.

 

Following this link, you can choose “Email”, “Web”, or “Default”.

 

Default turns the file into ¼ the size of the original.

 

Web turns the file into 1/7^th the size of the original.

 

Email turns it into something less than 1/10^th the size of the original.

 

Try this out if you have been frustrated with your machine crashing because of the file size.  When I take the final version of the “email” resolution and make it into a PDF, its now 27 MB.  Not small enough to send via email, but it’s a LOT smaller than the original.  About 1/40^th of the size of the original document.

 

Enjoy.

Virus-free.www.avg.com

Replacing your Sidekick1/2 cable

I recently was surveying and after many hours of frustration, came to the conclusion that the SK@ had bad cable.  Well, after that was confirmed, I needed a cable right now.

 

I went on Amazon and purchased the Cable Creation’s CC1303.  It’s a 3 foot 240 watt cable that can charge the SK2 and use for surveying.  I chose three feet so that cable won’t grab door knobs, etc.  If you’ve done a lot of surveying, you know what I’m talking about.

 

I bought it and it didn’t fit snugly.  I decided to try this on my good old SK1 first – you know, the one with the rubber band holding the cable in since it wobbles…

 

 

Most people don’t have heat shrink lying around, but I do.  So I thought…. Hmmm….

 

 

I went through my collection and found some ½ inch “flat” wide heat shrink that would fit around the connector.  Its pretty simple math to find the circumference of the heat shrink that I used, if you need to go order some on Amazon.  I have a pack that has a dozen sizes, so I did trial and error until I found one that slipped over…  It was ½ an inch.  Then I cut in into ½ inch long pieces and tried my luck…

 

I put the yellow one on, heated it with a butane lighter and tested it.  It was still too small.  I then got the next size heat shrink – it is red, and slid some over….

 

 

It is 5/8 inch if you are wondering – but that is “flat”.  I cut it in pieces and heated it like this with a butane lighter.  It worked perfectly.

 

 

It took three pieces of red, all the same size, to make it big enough.  So four in all.  All I did was slide it on, heat, test fit, then do it again.

 

After the third one, I knew the 4^th was going to be the last, and I could see I would need to put some pressure to form fit it.  So I slid the last one on, heated it up and then pressed it against a hard surface with my scissors and fit it correctly.  If you try this, you will see what I’m talking about.  Trust me.

 

 

Now its nice and snug in the SK1, and so is the SK2’s newly modified cable.

 

 

Its even more snug than the OEM cable.  That’s a beautiful thing!

 

 

This is what it started out like – and as you can imagine, it was wobbling around and I didn’t even attempt to take it surveying.

 

 

This all started when I received a new SK2 and it didn’t work from day 1.  I had to sit there and play with it for 15 minutes while people were standing there waiting for me.  VERY FRUSTRATING – and for those of you who do surveys, you know what its like when you escort is standing there waiting on you.  I could not see to find a cable that I could order that would fit snugly – and I honestly thought that what I was ordering would have to be shaved a little bit.  But instead, I got a wobbly one and started to think what I could use.  Rubber bands?  RTV?  Duct tape?  After looking at the slot for the cable, I came up with the idea and it works.  I plugged my cable in and it connected within 15 seconds or so.  The SK1 cable works too – but I’ll probably keep that rubber band on there just in case.

 

If you have any part numbers for cables that match right up, please feel free to leave a reply!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Virus-free.www.avg.com

Using Ekahau with Cisco DNAC to create Planned AP designs

First, the boring stuff.  It's in the Cisco docs, however I will add it here.

Add APs to a Map

This procedure describes how to add APs to a map.

Make sure that you have Cisco APs in your inventory. If not, discover them using the Discovery feature.

Step 1  Click the "hamburger" menu icon and choose Design > Network Hierarchy.

Step 2    From the left hierarchy tree, choose a floor.

Step 3  From the map toolbar, click 2D > Add/Edit > APs.

Step 4  In the map left pane, click Add APs.

In the Add APs slide-in pane, do the following:

⦁              To add an AP:  Click Add next to an AP that you want to add.

After adding the APs to a floor, close the Add APs window.

When you add an AP to a map, the wireless map automatically stores the following data even after the AP is deleted from the inventory:

⦁              AP name

⦁              AP MAC address

⦁              Current site of the AP

⦁              Current position of the AP on the map

Important:  When you delete the wireless controller with all its managed APs from the inventory, Cisco DNA Center displays a planned AP icon for the corresponding APs on the map.

Important:  If the same AP is rediscovered in the inventory later, Cisco DNA Center automatically places it back on the map at the same site and position even if a different wireless controller manages it.

To remove the AP data from the map when the AP is deleted from the inventory, you can do one of the following:

•             Before deleting the wireless controller from the inventory, assign the corresponding APs to the Global site.

•             After deleting the wireless controller from the inventory, remove the corresponding planned APs from the map.

 

 

Add Planned APs to a Map

Planned access points will likely be pre-loaded onto new floor plans before the migration.  Adding Planned Access Points (PAPs) should not be necessary.  If modifications are needed, continue with the following configuration.

After you install the actual APs in the wireless network, you can assign them to the planned APs on your map. This procedure describes how to assign planned APs to actual APs.

Step 1  Click the "hamburger" menu icon and choose Design > Network Hierarchy.

Step 2    From the left hierarchy tree, choose a floor.

Step 3    In the map toolbar, click 2D > Add/Edit > APs.

Step 4    In the left pane of the map, in the AP Models area, click the AP model of the planned AP to add.

This procedure shows you how to use the AP Model Catalog feature to add a planned AP to a floor and configure its model, antenna type, azimuth, and elevation orientation.

Step 5    On the floor map, click the location where you want to place the planned AP.

Step 6    In the Edit Planned AP slide-in pane, click the gear icon that is located next to the AP Name field.

Step 7    When you add the first AP to the floor, make sure that you enter a valid name pattern, for example, jkn001-011-ap01.

Important: The planned APs must be unique within Cisco DNA Center. So, make sure that the name pattern identifies the floor.  Access points imported from Cisco Prime can NOT have the same AP name.

Step 8    From the Antenna drop-down list, choose the appropriate antenna type, including dual antennas, for the AP.

Step 9    Depending on the antenna type, enter the Azimuth and Elevation orientation, in degrees.

Step 10 Perform the following actions, as needed:

• To add another planned AP with the same properties as that of the planned AP that you just added, on the floor map, click a location where you want to position the new AP.

A new AP icon is displayed on the map with all of the properties inherited and the AP name appended, for example, jkn001-011-ap02.

•             To add more planned APs with the same properties and appended AP name, click the floor map.

•             To stop adding planned APs to the floor map, press Esc or right-click the floor map.

•             To reposition the planned APs, drag and drop them to the appropriate location in the floor map.

•             To delete a planned AP, right-click the AP icon and click Delete.

•             To edit a planned AP, right-click the AP icon and click Edit.

Step 11 In the map toolbar, click Save.

 

Assign Actual APs to Planned APs

After you install the actual APs in the wireless network, you can assign them to the planned APs on your map.

Step 1  Click the "hamburger" menu icon and choose Design > Network Hierarchy.

Step 2    From the left hierarchy tree, choose a floor.

Step 3    In the map toolbar, click 2D > Add/Edit > APs.

Step 4    In the left pane of the map, click Assign PAPs.

Step 5    On the floor map, click a planned AP.

Step 6    In the Assign Planned APs slide-in pane, check the check box next to the AP that you want to assign.

Step 7    Click Assign.

Step 8    In the map toolbar, click Save.

 

Position an AP on a Map

After adding APs to a floor, you must position them on the map if they were not imported by a Wireless Architect using a design tool.

Step 1  Click the "hamburger" menu icon and choose Design > Network Hierarchy.

Step 2    From the left hierarchy tree, choose a floor.

Step 3    In the map toolbar, click 2D > Add/Edit > APs.

Step 4    From the Un-positioned category in the left pane of the map, click an AP.

 

Step 5    To position the AP:

Click the location on the floor map where you want to position the AP.

• Click Save.

Step 6    In the map toolbar, click Save

 

Edit an AP

This procedure shows you how to change the configuration of an AP.

Step 1  Click the "hamburger" menu icon and choose Design > Network Hierarchy.

Step 2    From the left hierarchy tree, choose a floor.

Step 3    For 2D, do the following:

a)            In the map toolbar, click 2D > Add/Edit.

b)            On the map, right-click the AP and choose Edit.

Step 4    For 3D, do the following:

a)            In the map toolbar, click 3D > Add/Edit.

b)            On the map, right-click the AP and choose Details.

Step 5    In the Edit AP slide-in pane, change any of the following AP settings, as needed:

•             AP Name or Planned AP Name:  jkn001-011-ap12

•             MAC Address: MAC address of the selected AP.

•             AP Model: Model of the selected AP. Usually 9166 series.

•             X-axis coordinate of the AP.

•             Y-axis coordinate of the AP.

•             AP Height: Height of the AP. Usually 10 – 14 feet.

•             Antenna: Antenna type for this AP.

•             Azimuth: For omnidirectional antennas, the azimuth is not relevant if the elevation is 0.

•             Elevation: in degrees. You can manually enter the value or use the blue arrow under the field to change the value.

 

 

 

Edit Multiple APs

When you select multiple APs, only some attributes are editable, as follows:

•             When the selected devices have the same value for an attribute, the value is displayed. Otherwise, the value is blank. In either case, if you change the value, the new value is applied to all the selected devices.

•             When the selected APs have the same model number and radios (number of radios and operating band), the antennas are editable. Otherwise, they are not editable.

•             You can change the model numbers of planned APs, but not added APs. So, if you select an AP, the model number is not editable.

•             Because bulk changes affect more devices, they do not take effect immediately. You must click Apply to apply your changes.

*             This procedure shows you how to update the editable attributes for multiple APs at the same time.

Step 1  Click the "hamburger" menu icon and choose Design > Network Hierarchy.

Step 2    From the left hierarchy tree, choose a floor.

Step 3    Do one of the following:

•             For 2D, in the map toolbar, click 2D > Add/Edit.

•             For 3D, in the map toolbar, click 3D > Add/Edit.

Step 4    Select the APs, using one of the following methods:

•             Click the first device, then press and hold the Shift key while you click the rest of the devices.

•             In the map navigation toolbar, click Select by rectangle. Then click an area of the map and drag the highlighted rectangle to select APs in a contiguous area. All the highlighted APs within the rectangle are selected.

To deselect APs, use one of the following methods:

•             To deselect a single AP, press and hold the Shift key while you click the AP.

•             To deselect all APs except one, click the AP you want to remain selected. All others are deselected.

•             To deselect all APs, press the ESC key or close the Edit pane.

Step 5    In the Edit AP slide-in pane, configure the settings, as available:

•             AP Name or Planned AP Name: Name of the AP.

•             MAC Address: MAC address of the selected AP.

•             AP Model: Model of the selected AP.

•             X-axis coordinate of the AP. You can manually enter the value.

•             Y-axis coordinate of the AP. You can manually enter the value.

•             AP Height: Height of the AP. You can manually enter the value.

•             Antenna: Antenna type for this AP.

                Note      For external APs, you must select an antenna, or the AP will not be present in the map.

•             Azimuth: Angle of the antenna, measured relative to the x axis, clockwise. The azimuth range is from 0 through 360. In Cisco DNA Center, pointing right is 0 degrees or 360 degrees; pointing down is 90 degrees.

You can manually enter the value or use the blue arrow under the field to change the value.

•             Elevation: in degrees. You can manually enter the value or use the blue arrow under the field to change the value.

 

The Cisco 9166i is designed to be placed on a ceiling. 0 elevation means pointing down. For External APs and antenna models that are designed to be placed on a wall, 0 elevation means pointing horizontally and negative values means pointing down.

Step 6    In the map toolbar, click Save.

 

Remove APs from a Map

This procedure shows you how to remove APs and planned APs (PAPs) from a map.

Step 1  Click the "hamburger" menu icon and choose Design > Network Hierarchy.

Step 2    From the left hierarchy tree, choose a floor.

Step 3    In the map toolbar, click 2D > Add/Edit.

Step 4    To remove APs (including planned APs), do the following:

a)            Click the AP, or to select multiple APs, click the first AP and while pressing the Shift key, click the rest of the APs.

b)            In the Edit pane, click Remove Selected.

Step 5    In the map toolbar, click Save.

 

Now for the good stuff.

You likely have Cisco Prime, but maybe you don't.  The export feature in Prime exports all the maps and then you import them into DNAC.

If you have the imported floor plans from Cisco Prime into DNAC and try to update the floor plans with a file from Ekahau, your results may vary.  If the Building/Floor in DNAC is the same as the Ekahau file, the Ekahau file replaces the floor plans in DNAC and as long as the Ekahau PAPs are named identically, they will take their place on the floor plan.

If the floor plans are not named the same – for instance, the Cisco Prime export has wonky naming conventions and this is the time to fix it, it will upload a parallel set of floor plans.  However, they PAPs will not show up on the floor plans, since those AP names exist on another set of floor plans in DNAC.

 

Floor Plans that were imported from Cisco Prime.

There are many caveats with Cisco DNA Center when dealing with legacy controllers and access points.

Mainly, the planned APs must be unique within Cisco DNA Center. So, make sure that the name pattern identifies the site code, floor/IDF, and AP number.  Per Cisco documentation:

The planned AP name and the name of the AP that may have been imported cannot be the same name and same case. They can be the same name and different case, however.  Specifically, the imported AP can be all uppercase, and the new planned AP and staged AP can be all lower case.+

If you try to add a planned AP to a floor plan that was imported from Cisco Prime, you will get the following error:

 

If the newly updated floor plans with PAPs are imported and have all lowercase names in DNAC, they will not show up on the floor plans if there are any access points with the same name and case in DNAC from the imported Cisco Prime migration.

The example below has a newly updated floor with Planned Access Points (PAPs) on it.  They are all lowercase names, and four of the imported PAPs did not show up.  That is because the Cisco Prime import has mostly uppercase AP names, but does have four lower case AP names.  Likely due to some maintenance or other issue and the access points were either renamed or replaced with lower case.

Importing a new floor plan with lower case AP names and having a Cisco Prime import with lower names will not work.  A workaround might be to log in to the legacy AirOS controller and rename all of the legacy access points with all UPPERCASE names, such as AUB001-001-AP01.  That would allow a new floor plans to be uploaded with all lowercase AP names so that new AP names with lowercase could be added. 

Note:  Renaming an AirOS access point requires a reboot.  Therefore take that into consideration before, should you decide to rename all legacy access points to upper case so that newly refreshed floor plans and PAPs can be uploaded into DNAC.

 

 

 

Floor Plans that were imported from Cisco Prime implementation example:

Step 1.  In this scenario, a fresh floor plan with planned access points (PAPs) on it was imported into DNAC.  This replaced the legacy floor plan that was imported with Prime, and the legacy APs were added as well.

The access points from Cisco Prime immediately took the place of the planned APs that were uploaded into DNAC.

There are two PAPs in this example that are not being occupied by a legacy access point, since they are likely offline.

 

Step 2.  Import a fresh floor plan with standard naming conventions moving forward.  Naming conventions are 1^st Floor Hospital, 2^nd Floor Hospital, etc.  Replacing the floors when spelled out alphabetically.

 

When new buildings/floors are imported, the old floors with the access points that were imported from Prime are still visible.  This is because the naming convention is different.  "First Floor" does not equal "1^st Floor" in Cisco DNAC.  They are two different entities. 

When the new naming convention/updated floor plans with PAPs are uploaded into DNAC, the planned access points do not show up.  This is because Cisco DNAC cannot have two APs with the same name in the system at the same time.

In this example, this is the actual Ekahau PAP floor plan that was imported into DNAC.  This is not a screenshot from Cisco DNAC.  Highlighted are two PAPs that do not exist in the system, likely due to them being offline – since they are legacy APs that exist.

This is an example of what happens when the above PAP floor plan is uploaded into DNAC.  When the legacy access points are the same name as the future APs, the PAPs do not show up on the new floor plan.  This is because we cannot have the same name twice due to restrictions clearly documented in the Cisco DNAC configuration guide.

 

I hope this helps someone who might be trying to wrap their head around refreshing ancient Cisco controllers and Prime with new controllers, new APs, and a shiny new DNAC.  My advice is to not import Cisco Prime into DNAC if proper housekeeping has not been in order for the last ten years of Cisco Prime care and feeding.  Start fresh – new floor plans, Ekahau files with PAPs on them and clean out all those old SSIDs the legacy gear while you're at it.

 

 

 

 

 

Virus-free.www.avg.com

Building a scalable Cisco 9800 WLAN controller configuration

When I first started researching how to configure the 9800, I was completely lost.  Coming from a “Wi-Fi standard deployment” of AireOS controllers where all the buildings on a controller were configured with AP Groups, none of what I was reading or watching made any sense.  I needed to understand how to architect and design the controller configuration first.  The problem is I didn’t understand how to configure the controller, therefore I could not design a configuration for it.   Enterprise deployments are usually designed and configured to company standards that are adhered to across the organization.  Standard naming conventions of buildings using city/campus/building/floor/closets for access points, city/campus for controllers and switches needed to be translated from the old AP Groups configurations to the new AP tags that I knew absolutely nothing about.

Everyone told me about the Cisco Config converter, and then the next sentence was, “but don’t use it”.  In order to learn how to configure a 9800, I did exactly what everyone told me.  I used the converter to migrate a standard controller configuration, then reverse engineered it piece by piece.  While reverse engineering the converted configuration, I discovered the conversion tool put a LOT of extra lines of code into the configuration.  I found it useful that I also watched Youtube videos and Chris Avants’ online 9800 classes.

I spent about two months learning the config, reverse-engineering it from the top down, then realized I should have started at the bottom. I found that architecting the configuration from the tag level (bottom) up toward the top of the configuration helped me understand how to build it.

During those two months, I had other projects, meetings, etc, but my focus was to learn this controller platform.  Some of the things I had to figure out: how to configure SSO, what to do with former AP Groups, how to convert WLAN profiles, and more importantly, why I could not see the SSID being broadcasted?

One of the things I wish I could have grasped early on is quite simple.  Former “global settings” are now configurable down to the AP level, and the tags have profiles in them that are customizable so that the configuration scales quite easily across an entire campus and each building/floor/AP might have a configuration tailored to it. 

An AP needs three tags in order to function.  An RF tag, a Site tag, and a Policy tag.  These tags contain a lot of information that used to be in many of the global settings on the AirOS controllers. We need to understand what is in tags – I like to think of it as each tag may have two or three buckets of settings. 

Think of it another way.  An AP is a plate.  It can act as a dinner plate, a lunch plate, or a breakfast plate.  You “tag” your plate with eggs, oatmeal and pineapple, making it a breakfast plate.  Tag it with steak, a potato and roll, and it is now a dinner plate.  But if nothing gets tagged on your plate, it’s just an empty plate – translation: no SSIDs being broadcast.

An RF tag has exactly that.  Two “Profiles” or buckets containing information on how this AP is going to act from an RF perspective.  In this case, it has a 2.4 GHz Profile and a 5 GHz profile.  Here is the CLI to create our RF Tag for our site code atl001:

wireless tag rf atl001_RF_Tag ß This creates the tag that will be associated to the AP

24ghz-rf-policy atl001_24GHz_RF_Profile

5ghz-rf-policy atl001_5GHz_RF_Profile

What if there are ten buildings on campus, and each has its own RF requirement?  We can create ten 2.4 GHz profiles, and 5 GHz profiles for ultimate flexibility.  Yes, that seems like a lot of work, but if you’re using the CLI, it really isn’t.  Simply create the first building’s RF Profiles for both frequencies, then copy/edit/paste and create the other nine.  For instance:

ap dot11 24ghz rf-profile atl001_24GHz_RF_Profile  ß name of the actual 2.4 GHz RF Profile.

channel add 1

channel add 6

channel add 11

description atl001_24GHz_RF_Profile

rate RATE_11M disable

rate RATE_12M mandatory

rate RATE_1M disable

rate RATE_24M mandatory

rate RATE_2M disable

rate RATE_5_5M disable

rate RATE_6M disable

rate RATE_9M disable

trap threshold clients 20

trap threshold utilization 60

tx-power max 20

tx-power min 1

tx-power v1 threshold -67

no shutdown

In this example, atl001 is a building’s site code.  Simply open up notepad, copy/paste and change atl001 to the next building atl002 and paste it into the config.  Do that eight more times and then there are ten RF Profiles that can be modified in the future so that each building can have its own customized RF settings.  There might be a library, a football stadium, hospital, warehouse, office space, etc, and they might each have their own requirements.  It’s the easiest thing to do when setting up the controller so that in the future, the RF tags can be modified to meet new requirements.  The best part is that the AP names will likely have that building site code atl001 in it, so it will be obvious how to assign the tags if they are being done manually.

The next thing we need are Site Tags.  Since we have determined we have ten buildings on campus, we will need ten site tags.  Site tags can have two buckets in it – an AP Join Profile and a Flex Profile, for FlexConnect APs.  This is a campus controller, so the latter is not needed since the APs are all in local mode. 

The campus APs might be able to be tagged by a single AP Join profile.  Since there are ten buildings, the most you would have would be ten ap profiles.  Let’s see what’s in an AP Profile:

ap profile atl001_AP_Profile

capwap timers fast-heartbeat-timeout 1

capwap timers primary-discovery-timeout 30

description atl001_AP_Profile

mgmtuser username alincoln password 8 f^JaaGS_OI[LO^S2D^L=NLS_DIIaTfOAAB secret 8 YCdW^[EN\JHHTQWgMLHOJMJBaZGfAAB

preferred-mode ipv4

ssh

syslog host 10.155.60.148

There is the possibility that someday the timers may need to be tweaked for a specific building.  If we create one AP join profile, we won’t be able to do that unless we create more join profiles and site tags and then re-tag the APs.  That said, if we created them now, it’s easy to do, and its standardized so future modifications will be made to individual profiles.

Here we create the Site Tag, and we will associate the AP Join profile into it.

wireless tag site atl001_Site_Tag

ap-profile atl001_AP_Profile

description atl001_Site_Tag

Simply copy/edit/paste, changing the site code (building code) and we can simply create all of the profiles and tags from the start so the configs can be modified in an orderly fashion in the future.

The last set of tags are called Policy Tags.  There are two buckets in the Policy Tag, one is for the SSID, and the other for the SSID’s Policy Profile.  I’m not a fan of the wording, and maybe it’s because I haven’t been working enough with the 9800 to understand the naming convention.  I would have preferred “SSID Advanced Settings”, or something else.

Just like in the previous examples, we will create a Policy Tag for each site on the campus for future flexibility.  Like the others, we will create the first one via CLI, then copy/paste and simply edit the site name to create the other buildings on this campus controller.

The Policy Tag’s name indicates which building it is on campus, which matches the description field.  In this tag, it ties each SSID to be broadcasted, and the Policy Profile for that WLAN/SSID together.  This is a campus controller – specifically meaning that it is not in a data center where it might have 3,000 big box retail stores on it, each with 15-20 APs and each store having local DHCP servers, VLANs, etc.  In that case, each SSID would likely have a Policy Profile for each building – since that is where VLANs are specified, and other configurations that might be for that site’s address.  Note how the contents of the tag call out the SSID and the “mapping” to the SSID’s Policy Profile, which could possibly have different settings if this were not a controller on a campus.  The point I am trying make is that you might think both the WLAN and the Policy Profile could have been in the same WLAN config, since that is how it was in the AirOS controller.  However that is not flexible enough if this controller was going to be deployed in a data center with 3500 big box stores – therefore this is separated into two different configurations and tied together with the Policy Tag.  Clear as mud?

wireless tag policy atl001_Policy_Tag

description atl001_Policy_Tag

wlan Contractor policy Contractor_Pol_Prof

wlan Telemetry policy Telemetry_Pol_Prof

wlan Voice policy Voice_Pol_Prof

wlan BYOD policy BYOD_Pol_Prof

wlan GuestWiFi policy GuestWiFi_Pol_Prof

wlan Wireless policy Wireless_Pol_Prof

 

Here’s a sample of a WLAN config and a Profile Policy config:

wlan Wireless 1 Wireless

assisted-roaming prediction

band-select

no chd

no dot11ax

no dot11ax downlink-mumimo

no dot11ax downlink-ofdma

no dot11ax uplink-mumimo

no dot11ax uplink-ofdma

dtim dot11 24ghz 2

dtim dot11 5ghz 2

radio policy dot11 24ghz

radio policy dot11 5ghz

security dot1x authentication-list Wireless_Auth

no shutdown

 

 

wireless profile policy Wireless_Pol_Prof

aaa-override

accounting-list Wireless_Acct

description "Policy profile for Wireless"

dhcp-tlv-caching

no exclusionlist

http-tlv-caching

idle-timeout 3600

ipv4 flow monitor wireless-avc-basic input

ipv4 flow monitor wireless-avc-basic output

ipv6 flow monitor wireless-avc-basic-ipv6 input

ipv6 flow monitor wireless-avc-basic-ipv6 output

multicast vlan 34

service-policy input silver-up

service-policy output silver

session-timeout 86400

vlan Wireless_Group

no shutdown

 

The folks at Cisco obviously have their act together and figured out that there needs to be a WLAN Profile and a Policy Profile.  Notice how the policy profile has the VLAN the WLAN is mapped to (or group), the multicast vlan, AAA override, etc.  That’s where the flexibility comes in – the policy profile allows the AP to map client devices to different VLANs on campus, creating flexibility and scalability.

 

 

 

 

 

 

 

 

 

 

 

Virus-free.www.avast.com

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