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

#end

#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 JusticeSuperfriends-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.