Tuesday, 29 December 2015

CiscoConfParse and Paramiko - an Engineer's wet dream

Ick,  I know.

Python has long been the language of choice for engineers looking to make their day go that little bit quicker or easier.  With deepening skill levels, more and more complex repetitive tasks can be disected and segmented into functions and reuable code, such that a competent scripting engineer can go from blank page to automated process in a matter of hours in most cases.  It is for this reason that I sit here to write this - an advocacy for ALL Cisco engineers to down tools and spend however long you need to get good at this.


Monday, 29 June 2015

Why I bought an AirConsole


Today I was reminded what a great git of Kit the AirConsole really is.  Its essentially a box that gives you Serial Access to a device via an RJ45 (Cisco pin-out) using WiFi, Bluetooth or wired, using a web GUI, or a bonkers driver setup on your machine.

For me, I use the AirConsole at work in a jack of all trades way.

  • I cable the Serial Dongle to the Router
  • I have a WiFi client profile configured that will auto join my (pervasively configured) corporate dirty network.
  • I have a WiFi AP setup in the AirConsole that securely presents a new network that I can join to access the Serial Port
  • I have NAT configured on the AP->Client WiFi so that I can still access the internet from that client Laptop
  • I have the Ethernet port configured to bridge with the AP interface, so I can get a wired device to connect to the Serial setup, and the internet.
So, most of the time what I find myself doing is plugging in the AirConsole, then going to a nearby desk and connecting to the AirConsole Web interface via HTTPS over the dedicated WiFi.  I can then configure my box, and still access the internet.  

If you are a sadist you can use these units via Bluetooth paired with your iPad or Nexus.  I tried that, and whilst it worked well, I didn't consider it to be a major benefit to me - the interface via touch screen is a bit dangerous for production configs!  

Where this gets more interesting, is when you look at the Private Server setup.  I bought my AirConsole in the "Pro" variant.  Its the same device, but includes a code for a single seat of Private Server licensing.  You need a seat per AirConsole you connect.  I have then deployed a Private Server OVA into my DC, and configured it appropriately.  So, when my AirConsole is able to access the internet, it calls home, and registers the session with the Private Server.  I can then centrally access all of my running units, and interact with them over HTTPS. You can then extend this to build expect scripts, which is a nice way to provision kit, or to automate diagnostics, particularly if you are using the tablet setups.

This presents a few interesting use cases. In my world, I'm acquiring these for each of my Engineers, and roaming units for each location where Opengear boxes are not economical.  It ensures that my guys have a common consistent way to using serial access, and avoids the recent issues with dodgy Chinese PL2303 USB/Serial clones not working in Windows. 

The GCPS Tunneling can be a bit slow sometimes, and you end up with laggy sessions, but when you consider that it allows me to share that session with another technician, it can be really useful for training, or debugging an isolated device without relying on other screen sharing tools.  Using the Web Interface terminal is lag free and very slick.

They recently upgraded the product line and as a result, you can acquire for just $150, a 4 port, hard wired unit (the Mini + 4 port FTDI adapter), to build a fully featured, internet accessible terminal server setup for a lab.  This too is something I am looking at.

In summary, I like the fact that I only have to carry a little white box and a short wire to access all my terminal stuff - it takes up less room in my bag.  I also like that I can use it for straight up Wifi - Wired bridging, and for internet sharing in hotels - ignoring the Serial element. Its very multi purpose and something that saves me time. 

Sunday, 28 June 2015

Using CallManager APIs for fun and profit: Part 4 - Python End to End

So by now you can use SoapUI and Python to read info out, and can utilise SoapUI Test Cases to validate, and deliver changes to the CallManager system.  Again, please do ensure you have reviewed parts 1-3 before entering into this post.  Its entirely contextualised within the series.

Up until now what we have been doing is quite focused on a single object being added or sense checked.  In this, the final post in this mini series we will be looking at an end to end python script that can be used to add a new end user to the system, with pre and post validation.

As you will see in the final script, we have had to jump forward significantly in our python engagement in order to deliver on the goal of mimicking the test case we defined in SoapUI. You will find use of programming constructs such as if statements, functions, arguments and return codes.  

This will potentially confuse people new to the programming world, so before we dive in too deep, I have decided to start the post off with something I call a "train of thought" script.

Whenever I start out on a new script, I tend to look at a problem and how I might solve it manually.  I then embark on a process of bashing that out into code pretty much as a single linear script.  This is both highly dangerous, and highly effective.  It gets you a working proof of concept, which is good. It also gets you two problems, where previously you would have had one!  The next steps from that, is to review the code fully, and look where you can pull stretches of processing out into functions. Once you then have the functions working in isolation using the python cli, you can then re-do your script, including endless comments and a tidy layout to support it.

Any developer will tell you this is a terrible idea.  I am not a developer.  This works for me - YMMV.

It may not have escaped your notice that there was a significant gap between this post and the last 3.  Part of this was Work commitments like Cisco Live US and the inevitable catchup of 2 weeks out of the office.  The other part was the not insignificant pain I had ham-fisting this script together.  I wanted to keep it simple, whilst also keeping it as close to the SoapUI work as possible.  Apologies for that delay...


Thursday, 11 June 2015

Live from Cisco Live US 2015!

This week is a first for me.  I'm at Cisco Live in San Diego.  It's been pretty awesome so far I have to say!
Full Disclosure, I was brought here by Cisco to talk to Analysts about ACI. However, I should also point out my only session was closed door feedback on why we chose the solution, and how its helped us to date.  Since we are only at the early stages, it was a short conversation.  I thank Cisco for their hospitality, and for allowing me to access Conference Level sessions that my explorer level pass would not normally allow.

So the events started for me Monday where I was up with the birds attending a Breakout session on ACI coding.  That started off a little dry, but I was pleased to say by the end of it, I had started to understand concepts that were not previously clear to me, and learned a few new things as well.  

The Keynote was an unsurprising surprise.  OK GO opened the show, which I loved.  The Marketing VP has the most confused accent, and you could tell she had been briefed to sound trendy, and that *never* works for anyone. Be yourself! Then Chambers was hilarious.  The content was good, the engagement was great, his conversational style was a little neurotic truth be told, but the messaging he had was remarkably close to the stuff we have in our business; innovate or be left behind, transform now and transform regularly - act fast.  What was a little difficult to swallow however, was the handover to Chuck.  It felt too staged, and it left me (and others) thinking that he was literally a JC sock puppet.  I doubt that is the case, but that's what it felt like in the room unfortunately.  Time will tell, but I expect that it was just a midguided introduction...

Tuesday was also pretty good.  More sessions, more content and whilst sometimes the sessions didnt live up to the billing in the notes, it was all useful stuff. The revelation for me has been the DevNet zone.  Its my firm view that ACI's success relies on the ecosystem around it expanding at a pace equal or higher than the market consuming it.  Thats a tough nut to crack, but so long as people are going to get what they need on demand rather than chasing release notes and providers, the sales will continue to come. 

As I made my way through DevNet I could see plenty of walk up desks with access to labs and sandboxes, and an engineer nearby ready to assist as you pick things apart.  I spent a good few hours bashing out ideas with engineers and have even made some tweaks to part 4 of my CUCM API series.

In the evening we were invited to the Analyst dinner, which was surprising not least because we were sat on a table with the so called MPLS quartet (Mario Mazzola, Prem Jain, Luca Cafiero and Soni Jiandani), who collectively are responsible for the success of the Datacentre product line.  Not all of them made it, but it was a great discussion, and the food wasnt bad either!

On Wednesday I decided to make DevNet and the Hub my home for the day.  I started with the loot scoot and proceeded to wander around to pick up random codes.  However, it wasnt long before I was stopping at each pod to listen to the guys presenting their wares. I naturally gravitated to the SDN pod and ended up spending about an hour listening to Chad Peterson talk about all the cool things he had built for NXAPI. What impressed me more than anything else is that he is a CCIE Route/Switch guy. He is not a Developer at all. I then sat in on some coding classes with Mike Maas, and did some time in the sandbox labs. The most exciting news there was that APIC-DC is going to be in the freebie sandboxes very soon.

Today is a half day for me, as my flight back to the UK leaves at 4pm, so I went to one last breakout, and spent the rest of my time in DevNet.

In short, CiscoLive has been incredibly useful.  The Technical Seminars are good quality, and well timed to balance content depth and being able to stay awake! I also think that the explorer pass grade content is an absolute steal for $49.  My colleague an I discussed the merits of the full conference pass, and whilst I found value in it, we both struggled with the difference in price between the two.  He made a good point that much of that technical seminar detail could be obtained for free via your SE on a one to one basis, so I guess its a margin call there. The extras like the Customer Appreciation Event and some of the Dinners are great, but I wouldn't buy a Full Pass just for that obviously!

If you are in any way a Cisco shop, then you should be here on an explorer pass as an absolute minimum. You will definitely fill your time with content at that level.  If you have any particular plans for expansion, migration or significant change, then the uplift to the Full Pass is a good idea.  At both levels you can do meet the engineer and buy tectorial time as well, so honestly, you should put it on your radar.  I fear that it wont be long before the DevNet zone becomes its own pass level with associated costs.  Do not make the mistake of thinking that's purely for VARs/Third party devs however.  There is a lot of content targeting engineers that need to bridge the gap.

In the meantime...  


Monday, 1 June 2015

Using CallManager APIs for fun and profit: Part 3 - Changes

In this the third part of my mini series on using the CUCM API, we start to get further into the Ju-Ju, and check web app changes via the API, before then going on to make a change via the API itself.

As before if you haven't gone through the previous two posts then please, head back to the start and we will see you back here shortly.

Whats your motivation today?

There are two reasons why you might want to use an API in your day to day changes.
  1. Validating a change
  2. Making a change
APIs and scripting are a great way to ensure that whatever it is you just did, worked as you expected. First we will look at using SoapUI to ensure that what we just did worked the way we wanted it to. As an aside - this is a very common use case for SoapUI Pro, and I would strongly recommend that you consider a full Pro Licence for this product.  I get no kickbacks, nor benefits from being an advocate of it.  I just think it does the job they intended, and it can be really good to be able to define a massive heap of tests, and run all of them with a single click.  It makes your change validation process vastly quicker, and your outcomes more reliable.  as we get to the end of this post, and the series I think you'll see what I mean.

Sunday, 31 May 2015

Using CallManager APIs for fun and profit: Part 2 - Python

In this part 2 of my API adventure, i will be looking at repeating what we did Part 1 via SoapUI in python using the suds library.  If you haven't read that yet, then really, please go back and do that. This will not be wildly useful otherwise.

Getting SOAP-y with Python suds

Yeah I went there...

So, we have a process that allows us to programatically look stuff up. Only its not very repeatable, and therefore not much use yet.  With this post I will take you through the creation of a python script that mimics what we did previously - finding things, and showing them to you.

For brevity, I am not going to take you through setting up Python and installing suds.  With respect, if you can't figure that out yourself, you probably shouldn't be playing with this stuff anyways.  Its also a post in and of itself, and plenty of others have covered it well.  I am also using Ubuntu for this work.  You can use OSX pretty much interchangeably since its all *NIX based.  Windows will work, but I warn you now, its quirky.  Obviously I don't provide any sort of warranty with anything I do here, and whilst I will try to help people who feedback about problems via windows, my initial response will probably be, "can you not use linux instead?"

So. Much like when we talked about the 4 sections of the SoapUI request, we will look at 4 sections of our Python script
  1. modules
  2. required variables
  3. API "proxy object" creation
  4. obtaining data via the proxy object

Friday, 29 May 2015

Using CallManager APIs for fun and profit: Part 1 - SoapUI

This is one of those posts that I will constantly refer back to... ;)

In my day job it's clear to me that we need to automate more and more of the dumb day to day stuff.  One of those things is Leavers and Starters on our phone system.  


We employ Cisco CallManager, much like the rest of the world, and if you have ever spent any time with it, you will know that its VASTLY over-complicated to manage.  A single extension on someones' desk requires (at least); 

  • an End User object
  • a Device Profile (extension mobility)
  • a Phone object
  • a Voicemail profile
In order for these to exist and function you need access to appropriately configured 
  • Device Pools, 
  • Calling Search Spaces, 
  • Partitions, 
  • Regions,
  • Clusters
  • Gateways
All of this ends up being at least one person's full time job once you get over a certain level of employees. 

There are various functions within the standard Web GUI including the entertainingly named "SuperCopy" which cuts the admin burden from about 40 mins per user of manual click-type, to about 20 mins.  A valuable 50% saving in time, but that's still 20 mins of click-type that we could all do without. 

There is however, a rather rich (read: confusing) API for CallManager called AXL, which with the right amount of time and dedication can be tamed.

Over the past 2 weeks I have been mulling over my own SuperCopy scripts in python, with a view to swapping the 20 mins of click-type for 10 questions and 10 seconds.  The right hand page will be to add phone provisioning into our existing Account Setup automation over AD, thus eliminating all manual operations for leavers and starters entirely.  If it works, we look to gain an entire head in our team back on a full time basis to focus on break/fix and engineering improvements - a MASSIVE win.

I have said before, that the role of the Network Engineer is moving further and further away from fingerbashing CLIs.  If you cannot embrace APIs and scripting, then its my job to tell you that you are making yourself obsolete. Fabrics and flows are already replacing the classic tree architectures and packet based switching.  Our jobs are no longer about making things work and more about optimising whats there.  APIs and automation are how we as engineers stay ahead of the curve, and in employment.  On top of all of that, its more fun as well...

Thursday, 21 May 2015

The SDN Conundrum...

Oh how the world has changed since I started out in the wonderful trade.

We used to have VLANs and subnets; switches, routers and firewalls.  People would moan things didn't work and we did a traceroute to figure out why.  We would bash out a fix, and if it broke, we would bash out another.  It was the wild west, and that was fun.  Cowboy hats were standard issue.

Then along came the bad guys, and with them, the policy doctors.  Changes became more structured and requirements became more complex.  Environments spiraled out into wider geographical areas and management became less about break fix and more about tightly structured architecture.  The industry responded with protocols and toolchains, each with their own use case, and bit by bit, the sector split up into the key areas of WAN, DC and Campus.

Product portfolios splintered and expanded, use cases became more and more tailored and expansive, until now, most enterprise network admins have hundreds of devices in geographically diverse locations, each with their own subtle differences.  They tend to adhere to policies, and usually templates, but the nature of the beast today is that no two unique devices are configured truly the same.

End result is that managing enterprise networks, which almost always encompass all three key areas, is no trivial task.  To counter this, management have to invest time and money into training and drills to ensure that engineering changes are tightly controlled, and defining standards to as far as possible enforce uniformity into the environment.  The net result tends to be simplified troubleshooting (win), at the cost of slower mean time to delivery and diminished capability for rapid reaction to events (lose).

This is surely not a one size fits all summary, but i'd be surprised if some if not all of that rings true to a large amount of my peers today.

Again, the industry has responded.  In this, the era of devops and scripting, many vendors have looked to enable automation into their equipment, however, automation isn't new.  SPs have been taking CSV files and regexing templates for TFTP delivery since the 90s.  The first batch of automation we have seen recently has been an extension of that - essentially allowing machine control of the CLI, without that interim step of regexing a config template.  Big whoop. The configs still diverge from the template over time and all we have done is decrease rollout times.  Management and Maintenance is in no better shape.

The true leap forward has been with a phrase that fills most old school engineers (me included) with fear and trepidation - Software Defined Networking (SDN).


The even-ended number problem in Go and Python

 During the Go Essential Training course on LinkedIn, the instructor sets up a problem for you to solve. The solution is in the next slide o...