WirelessNick

802.11ax The Future Begins

The networking industry is full of buzzwords and hype; A.I., M.L., SDWAN and virtual everything. This is even more evident in the world of wireless networking; claims of speeds up to 1 Gbps, wired-like connectivity, mobility first, future-proofing and on and on. It all reminds me of one of my favorite Queen songs Radio Gaga, “All we hear is radio ga ga, Radio blah blah, Radio, what’s new?”.

The new 802.11ax amendment (not yet standard, thanks TheITRebel), or WiFi6 as it is now being called, is slated to be ratified later in 2019. This is causing all kinds of hype in some circles and not so much in others yet as end-user computing devices will probably not have chipsets to support 802.11ax until maybe the end of 2019. Looking forward, more full adoption will probably not happen until 2020 or even as late as 2021.

What is 802.11ax?

802.11ax will build on the features that the 802.11ac, or WiFi5, standard gave us as well as adding some cool new things to help with the ever growing demand on wireless networks. From a desire for mobility-first networks [to cellular offloading that is wanted (and sometimes needed) from the carriers,.11ax has it’s work cut out for it.

802.11ac gave us some significant improvements with additional channel widths in the 5GHz space to allow for 80MHz channels in Wave 1 and 160MHz channels in Wave 2, giving higher bandwidth availability to user devices if those devices had the chipset to support it. The drawback isnow with 80MHz and 160 channels is that we take the available 5GHz channels from a total of 24 down to 5 or 1 available non-overlapping channels, depending on the usage of DFS channels. This makes it much harder to channel plan in an enterprise or LPV style of deployment, so I still recommended to use 20 MHz channels, or perhaps 40MHz if done properly. However, when this style of deployment is done the whopping 1.3Gbps that is touted by the marketing folks cannot be met even when using 3×3 spatial streams. Again, an example of more hype that really is not too useful outside of a small business or home deployment.

802.11ax can achieve throughput speeds of up to 4.8Gbps according to the data sheets and marketing put out so far. But how can we get to those speeds?

As with 802.11ac, to reach the speeds marketing is telling us about we need two things, multiple bonded channels and clients that can support it. Let’s look at these one at a time.

802.11ac wave 2 began to support 160MHz channels as well as Multi-User Multiple Input/Multiple Output to support multiple streams of data. This implementation yielded multi-user downlinks from the AP to the client. However, uplink traffic from the client to the AP is a single client at a time, by contrast. 802.11ax looks to improve this by allowing MU-MIMO APs to talk bi-directionally to up to 8 devices simultaneously and to become almost ‘switch-like’ (I know more buzzwords, sorry). The new standard will also allow capable clients to take full advantage of MU-MIMO and to use dual-streams to an AP which would potentially double the bandwidth to that client.

The best analogy I have seen of this so far is with 802.11ac there is an eight-lane road, that funels down to one-lane creating a bottle neck and allowing only a single car thorugh at a time. This is how MU-MIMO worked previously with legacy uplink/downlink mechanisms. Now with 802.11ax that one-lane road is extended to a full eight-lanes, eliminating the bottle neck and allowing traffic to flow freely.

More to come on this subject soon.

To Predict or not to Predict, that is the question…

In the world there are many questions that polarize us all; did Han shoot first, Kirk or Picard, Left Twix or Right Twix. But the most important question of them all, should predictive designs exist. If you follow the wireless community this is probably the most polarizing topic right with lower data rates being enabled or not.

Designing wireless is one of the most challenging things we do. We receive a set of drawings and put the Solo cup down and start drawing circles. Wait, bad flashback. These were the good old days. We would draw our circles, place APs and then go on site and verify locations and take some survey readings with an AP on a stick to verify all looks good, what does the spectrum look like, are there interferers in the area.

Today we still draw circles, but they are really cool looking ones using Ekahau typically. We draw walls that can help us predict what loss may occur from walls, doors, etc. Then we go on site and take readings with the same software and an AP on a stick to make sure those pretty circles match. But why do it ahead of time and not when you are on site?

I have had many instances over the years where a predictive survey was all I was able to do. The customer would not sign-off on doing an on-site active survey because of the disruption it may cause, the building has not been built yet, or just no budget for it in the project.

I have also had the opposite where a customer would tell me that they saw no reason for a predictive and the coverage they had was ‘good enough’. But is it?

With the stuff we are putting on wireless today can we really be ok with just good enough? In a large portion of organizations, we have gone from wireless being a nice to have to a wireless first strategy. This includes VoWIFI using Skype or some other demanding application/protocol. How do we handle this without trying to do some kind of prediction? Are we to just install the network and then do a remediation at additional cost after things blow up quicker than Lee Badman’s temper when they take the all you can eat steak away??

With tools like Ekahau, and no they are not paying me, but they have awesome swag, you can do predictions based on applications, number of users, and device types. We no longer need the Solo cups, oh what? The keg just got tapped…

But all joking aside, is it really worth us guessing and throwing APs up and then coming back doing remediations after the fact to make sure we handle the new generation of wireless networks appropriately? Or should we just do the extra work up front so we have an idea of what we are walking into? The reports we can provide ahead of time as well as comparing to post-installation surveys are invaluable to this bloggers opinion and will continue to be fought for as long as I do wireless.

Cisco Prime – This is what it is good for. Part 2

In the previous post the scripting needed for multi-linecard switches like the 6500 was discussed. In this post we will finally deploy the configs we have created through our scripts using the Prime Deployment function.

To start we simply go to our config template and open it in Prime. We can see the script in the bottom pane of the screen and the Deploy button is available at the top of the page.

Once we click Deploy we are presented with a screen to select the switches to which we want to deploy the configs.

To filter by a specific switch name of prefix, Hit the filter icon and enter the name. As devices are selected with the checkbox, they will add the Device to Deploy area. When all devices to deploy are selected click Next.

The next area is the Workflow screen. We did not do anything in this area and just clicked Next.

This then displays the devices selected and we now can see the form created when the script was written which is where, like in the case of the 6500, lincecards can be selected. This area also has an option in the right corner to check the CLI commands against the device verified to make sure the commands are compatible.

After clicking Next we are presented with the Deployment Options area. We did a couple of different ways of deployment, On-Demand and Scheduled.

On-Demand is when selecting the Now radio button then Next. If deployment is to be scheduled at another date and time, this can be accomplished us the Date radio button and selecting the appropriate Date/Time. Be careful as this is the Date/Time of the sever. If your server is centralized in a data center and your site is in another time zone this needs to be taken into account.

There are a couple other options at the bottom of this screen that help to make sure we do not lose our config that we have worked on so hard, Copy Running Config to Startup and Archive Config After Deployment. These are fairly self-explanatory, but the second option is used if you are archiving your device configurations to the Prime Server for back-ups.

Once we click Next we get the final Deploy verification screen, this is our last point of turning around. Once Deploy is clicked the job will begin running in Prime and we can only abort it in the Job Dashboard.

At this point, sit back and have some coffee or something stronger, and wait to see the job complete in Job Dashboard. Depending on the number of devices the config is being pushed to and how large the config ended up being, this can take upwards of 20+ minutes to complete. You can keep an eye in it in Job Dashboard and make sure all devices are successfully being deployed to.

Some gotchas that gave us a little grief.

Portchannels. Depending on the model of switch, the portchannels have to have imnput part of the port config added to physical and the output added to the portchannel. We did this manually as it was easier and fee and far between, but with testing you could add this part to your script.

Random Errors. We would occasionally receive an error that a timeout occurred pushing the config to the switch. After doing research and looking at the actual switch it was determined the config would actually push and we never really figured out why this error would occur. If anyone else has seen this and has any further info, please let me know and I will update this with that info.

With that we complete the look at using Cisco Prime to push QoS configs to ~1,000 switches in the wild. I genuinely hope this helps some other folks out there and provides some info to all.

Look for more coming soon.

Cisco Prime – This is what it is good for. Part 1

In the last post we looked briefly at a scripting sample on adding QoS commands to IOS-X and IOS switches using Prime Infrastructure. To recap, we were looking to push QoS policies to ~1,000 switches of various models, IOS versions and even line cards. Using APIC-EM was not an option as only about half the switches were supported either because of old platform, IOS or other issues. Prime was selected since it had just been stood up for the wireless implementation and could push to all the various switch types, from 2960 to Nexus 7K.

With the scripts we needed to take into account the platform of the switch, the IOS and linecards as previously mentioned. This process has to use a combination of automation through Prime as well as manual intervention to know what the linecard is installed in the switch so it can be selected from a drop-down of available cards.

Last time we looked at a basic IOS config for QoS, how do we handle a 6500 series with a variety of linecards? Below is a sample of how this had to be handled.

The first thing, as with the previous script is we have to query the Prime DB structure and set the variables for the slots on the switches.

<parameter-metadata>

<param-group cliName=”cli command set” isMandatory=”true” name=”Deploy_QoS_Cat6500 parameters”>

<description>Parameters for Deploy_QoS_Cat6500</description>

<parameter name=”slot1″>

<description>Line Card Slot 1 Type</description>

<default-value label=”Select the appropriate line card type or none for slot 1″>None</default-value>

<default-value>6148</default-value>

<default-value>6524</default-value>

<default-value>6704</default-value>

<default-value>6724</default-value>

<default-value>6748</default-value>

<default-value>6824</default-value>

<default-value>6848</default-value>

<data-type>Dropdown</data-type>

<mandatory>true</mandatory>

<isGlobal>false</isGlobal>

<syntax>

<pattern/>

</syntax>

<isGlobalVariable>false</isGlobalVariable>

</parameter>

This has to be done for each possible line slot depending on the model. We went all the way to 13 based on the customer having a number of 6513 chassis.

Next we get to the meat of the QoS config that will be applied to the ports.

mls qos

mls qos map cos-dscp 0 10 18 26 34 46 48 56

##Queuing command structure

#set ( $OnePSevenQEightT = “wrr-queue queue-limit 10 25 10 10 10 10 10

wrr-queue bandwidth 1 25 4 10 10 10 10

priority-queue queue-limit 15

wrr-queue random-detect 1

wrr-queue random-detect 2

wrr-queue random-detect 3

wrr-queue random-detect 4

wrr-queue random-detect 5

wrr-queue random-detect 6

wrr-queue random-detect 7

wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 2 80 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 3 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 3 80 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 4 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 4 80 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 5 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 5 80 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 6 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 6 80 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 7 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 7 100 100 100 100 100 100 100 100

wrr-queue cos-map 1 1 1

wrr-queue cos-map 2 1 0

wrr-queue cos-map 3 1 2

wrr-queue cos-map 4 1 3

wrr-queue cos-map 5 1 6

wrr-queue cos-map 6 1 7

wrr-queue cos-map 7 1 4

priority-queue cos-map 1 5″ )

This is one example of the different structure that needs to be created which is also based on linecard model and what the card will support for commands and QoS. If you are new to this, as I was, the name $OnePSevenQEightT seems confusing, but being a great cryptographer, you can quicker decipher. OneP = One Priority, SevenQ = Seven Queues and EightT = Eight Thresholds.

Now that we know what model line cards and the configs built for the actual QoS commands, we can start the interface configs for each slot.

## !—INTERFACE CONFIG for slot 1:

#if ( $slot1 == “6704” )

#set ( $port_range = “Te1/1-4” )

int range $port_range

$OnePSevenQEightT

#elseif ( $slot1 == “6708” )

#set ( $port_range = “Te1/1-8” )

int range $port_range

$OnePSevenQFourT

#elseif ( $slot1 == “6724” || $slot1 == “6824” )

#set ( $port_range = “Gi1/1-24” )

int range $port_range

$OnePThreeQEightT

#elseif ( $slot1 == “6748” || $slot1 == “6848” )

#set ( $port_range = “Gi1/1-48” )

int range $port_range

$OnePThreeQEightT

#elseif ( $slot1 == “6524” )

#set ( $port_range = “Gi1/1-24” )

int range $port_range

$OnePThreeQOneT

#elseif ( $slot1 == “6148” )

#set ( $port_range = “Gi1/1-48” )

int range $port_range

$OnePTwoQTwoT

#elseif ( $slot1 == “None” )

#end

In this code we are looking at each slot, #if ( $slot1, and we have to build a config for the slot with each possible linecard that could be installed because each takes a different command or queueing structure as we built in the first set of code.

The linecard model is then specified, == “6704” ). You may be asking, ‘Nick why does this even matter? That seems like a lot of extra code I just really don’t want to deal with.’ It does matter since each linecard model may have a different number of ports and even type of port. We cannot really specify commands to add configs to a Gig interface when the linecard is a TenGig card. We also have to account for the option that the linecard is not actually populated, can’t really put a config on a card that is not installed. It is painful but needed. Copy and Paste is your friend, but be careful to make sure the slot number gets updated each time.

At this point just make sure have the correct number of #end statements and don’t forget to close the clicommand.

We will now move on to Deployment of the configs we have created.

Cisco Prime, What is it good for?

By now the majority of us have used some itinerant of Prime, NCS, or WCS for wireless management, placing APs on maps, template building, backups, etc. But what else can Prime really do?

I recently did a project where we needed to integrate a new prime instance with the standard CMX installs, which is a chore in and of itself (a post on that is coming), wireless management for the various buildings they have and some jobs to do back-ups of switch, router and ASA configs. There then a larger project to push QoS to a large number of switches, around 1,000 or so. APIC-EM was attempted but there was such a variety of switch models, chassis, IOS versions, QoS abilities to name a few. With these variances, only about half the switches were supported in APIC-EM. Since we had just stood up the new Prime, it was decided to use Prime to push these configs to the switches. Let’s be totally honest before we begin, Prime was not built as a wired network management suite. It was built form the old WCS and then pieces were added and we now have this. It is not horrible, but it is not the best for wired either.

Fun now ensues.

Initial thoughts were to just push Auto-QOS to all switches, however there was a requirement for more granularity. More fun begins. I start to set out writing config scripts in Prime for a couple of switch models to test on, 4506-E and 4500X. Should be simple right, take a QoS config, put it in the template, select the switch and go. To write a script in Prime you need some knowledge of Apache scripting commands which can be a little confusing in itself if you not done coding previously, like myself. I was lucky and had someone who could do these scripts and teach along the way.

Some of the pitfalls we had along the way included the need to build-in smarts to see what platform the switches were to use the proper commands, what version of code was on the switch, querying the switch to gather port types and line cards installed. To accomplish this you have to first begin with understanding the Prime database structure and how to call the appropriate variables for what you need. This excerpt from the Prime 3.1 user guide is a good place to start to understand the variable and how to call them from inside the CLI config templates. Also, see this Support Community Post which has some good info as well.

Now we have gotten our background info we are ready to start jumping in and breaking, I mean writing, some scripts. This was a lot of trial and error for me as we had to touch at least one version of each type of switch and verify we had the right CLI commands to enable QoS as it differs on platforms and even code trains within the same platforms.

After a couple of false starts with getting platforms commands, interface commands and settings just right we were able to get a working script for the first group of switches, the 4506-E,4500-X and a test Nexus 7K. The script ended up looking like this:

$Platform.contains(“Data Center Switches”))

The trick is we had to have the platform command and specifically the “Data Center Switches”. If a sh platform is run on the switches this is what is returned as the platform name. The reason we were looking at this command was it was easier and seemed more stable to call the platform type than the $Version.contains command to check IOS vs. IOS-X.

policy-map configs for IOS-X

#else

This is where we specify non-IOS-X config elements

access-list

policy-map

class-map

#foreach ($interfaceName in $InterfaceNameList)

#if ($interfaceName == (“GigabitEthernet0/0”))

#else

int $interfaceName

service-policy output QOS-SHAPE

service-policy input QOS-MARK

#end

These are the lines where the magic really happens. This code is going to the Prime DB and doing a querying for interfaces using the $InterfaceNameList and then we are checking if $InterfaceName == (“GigabitEthernet0/0”)) which is generally the management port on the switch. Of the port has that name we do not apply any Qos to it. If not any other $InterfaceName we apply the service-policy config to.

Gotcha 1 for me, make sure you account for all the #end statements you need. It becomes easy to lose track and it will frustrate you when you import to Prime and try to test it the first time.

With this basic config, you can now customize based on switch type.

The next step to deploy is we have to get this config into Prime, if you didn’t write it there, and make sure all our variables are working properly. After importing into Prime the Form View tab and Add Variable tabs will now be populated.

Our next post will cover Deployment of the newly created script to either 1 or 1,000 switches depending on the need.

Becoming a Wireless Super Hero – Part 1

In the first part of this multi-part blog, we will explore what it takes to be a Wireless Super Hero.

My family and I went to see Justice League over the holiday weekend and with all the super hero movies and TV shows over the last few years it got me to thinking, What is needed to become a Wireless Super Hero?

Growing up I was always more of a DC fan than Marvel and specifically I loved Batman and the Flash. They were the ones that had the smarts and other than the ability to run really fast, no actual powers. Batman being my absolute favorite (until Ben Affleck came along) has his wits, tools and Sidekick (see what I did there?). Over the next few blog posts we will explore how to become the World’s Greatest Wireless Detective and what would someone need to build a Wireless Bat Utility Belt and BatCave.

Meanwhile back at the Hall of Justice… Superfriends-Justice-League-Hall-of-Justice

The first step in becoming the World’s Greatest Wireless Detective is what all super heroes have to start with, training. It doesn’t have to be crazy League of Shadows level training, but understanding of the basic concepts of wireless is a must for anyone trying to get their feet under them in an industry that at one point seemed to be all black magic and smoke and mirrors. In our next post we will start looking at the tools you need to hit the street and start getting hands-on in the fight against bad Wi-Fi.

When I first started in wireless about 18 years ago, the only training you could find was specific to manufacturers prior to the being any wireless standards or organizations. Each manufacturer used proprietary configurations. The designs were more or less the same when doing 900 MHz, then 2.4 came along and things got wild. We had Telxon doing DSSS and Symbol with their Spring radios and FHSS. To get the needed knowledge you would have to attend courses for each manufacturer to under the proper design configurations. Standards organizations finally came about and we finally were able to get training around actual wireless concepts it was still somewhat vendor dependent and most times you trained in whatever you were selling or supporting at the time.

We now have so many great options for vendor-neutral training that gets into the heart of Wi-Fi and the technology with the CWNP program. I had heard about it for years and had looked at the CWNA book multiple times and kept saying I would do it and then would always get sidetracked chasing squirrels. I finally sat down a few months ago and went through it and wished I had done it years ago. It helped to clear up some misunderstandings I had made in my own head for years and gave some good insight into why we do the things we do in wireless which helps me to communicate that back to my customers as well when they ask, instead of the old “That’s how we do wireless.”

The vendor-specific training seems to be going in the same direction over the last few years. The last couple I have done are of course specific to their technology, but they are also trying to add more of the overall concepts and under the sheets knowledge of wireless that engineers should have. Anyone can hang an AP. What makes an engineer good is when they can see why connectivity is lacking or throughput is choking and understand the concepts and reasons behind those issues and how to properly conduct a predictive survey then understand the results of validation testing and make the appropriate changes.

Becoming a Wireless Super Hero – Part 2 will be coming soon where we will discuss the wonderful toys to add to our utility belts.

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: