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.

node_exporter in VyOS 1.4

So it turns out that if you want metrics from VyOS, your two options are SNMP or Telegraf (towards InfluxDB).  SNMP is one of those things t...