Tag Archives: Cisco

Wash, rinse, repeat

  • How many times do you repeat a task before it should become a candidate for an effort around automating it?
  • What is the risk involved in doing the task again manually after a period of time away from it?
  • Is it more logical to ‘script’ the task and hand a simple standardised ‘tool’ over to colleagues than write a mini guide on how it’s done or show people individually?
  • Can I simplify a task by hiding complexity that only an SME needs to understand in a tool that uses only widely understood and meaningful inputs?

Questions that will probably get different answers and views shared if you ask different people… which is why it’s nice when a community reduces the relevance of the questions by doing much of the work for you?  (I use ‘2 or 3’ as a rule for the first question providing I could see a need for the task to be done again btw)

If you have developed PowerShell skills then you can programme against many systems in the data centre.  Cisco UCS is included in this.  It has a library of cmdlets.  This library has been put to some awesome use in script submissions for a contest that is currently running on our Communities site.  A great resource has been created on the back of that competition.

Here is the main page for the contest.  Here is the script repository.

I particularly like the easy-on-the-eye bandwidth check that Vallard Benincosa has put together and the comprehensive system health check produced by Brandon Beck following great work by Jeremy Waldrop!  We’ve used the system health check in our labs and it’s very handy indeed!

Advertisements

Give me what you’ve got!

Application Centric Infrastructure (ACI) gets me as giddy as UCS did, here’s a great demo video very recently published:

 

We’ll be looking at ACI from a number of different angles over the coming months…

Capturing DevOps – Part 2 of 2

In Part 1 of this update I briefly ran through the Cisco goUCS tool and how it can be used as a means to an end with regards to capturing XML passed between the UCS Manager java client and UCS’ main XML API.

In this ‘Part 2’ I’d like to push on right into the world of programming against open infrastructure systems.  Along the lines of explanations in previous posts, I mean ‘open’ in respect to how you interface and communicate with the systems to form provisioning and monitoring actions.

This shift comes under the umbrella of the remit of DevOps.  Like many terms used in IT, there’s a question mark over whether the term has an ‘etched in stone’ definition today; the full definition will take shape over time.  It is well enough defined to be able to identify meaningful technologies and trends that it relies upon however.  DevOps is essentially a response to the growing awareness of the disconnect, or “Wall of confusion” as it has been called, between software development and the systems supporting the running of said software applications.  I like to compare it to Systems Thinking and how you would pragmatically optimise the delivery of Business Applications without considering current-day people (i.e. structure and skills) and toolsets to a point where they become inhibitors to a given business’ ICT ideology.

Note. I'm not a programmer.  A lot of this stuff is quite new to me so I'm explaining things from that view point. i.e. somebody near the far end of the 'Ops' side of the DevOps movement.

Over the coming years you can expect to see efforts to address the conflicting skills, backgrounds, motives, processes and tools associated with the two different starting points to delivering a software application.  “Agile Software Development” initiatives in many business sectors and verticals could be one of the major stimulants for speedy change in the way things are done.

If you’ve not got a programming background the app that we’ll be getting onto soon could definitely jump out at you in quite some gory detail that looks quite frightening at first!  I took a first look at it and thought ‘hmmm, not for me’ anyway…  Please stick with it though 😉

Here is what we essentially have today:

StackComm

Here is where the app that I’m introducing you to sits… API-calls downstream in all cases, SME input at the app level (previously the ‘Speakers’ each time something needs doing):

GeneralAPITool Placement

Sorry about the hazed text on the left – that’s a ‘save to image’ thing… those tags are vNet (virtual network), pNet (physical network) and vService (virtual network service e.g. firewall) -> they merge together to create network containers.

As you can see, the app that’s identified in the diagram hasn’t got a fancy name, and before you see it I’ll state that it also doesn’t have a massively intuitive interface if you’re not a SW programmer.  It was written by a colleague of mine, a chap called Rob, who does some programming as a hobby… that’s right, a hobby… tut! why can’t I be like that!?

The app can be found here: https://github.com/ciscodev/GeneralAPITool.  There is a “Download Zip” link on the right hand side of the github page.

Rob’s aim was to create a straightforward API-calling SDK-type tool relevant to the infrastructure elements that we, in the Cisco UKI DC Team, deal with day-to-day rather than doing everything ad-hoc and specific to a given solution or product.  UCS Director includes a lot of what we’re doing in a much nicer interface but we wanted to see under the hood a bit more from a programmability perspective.  It came about after we ran a “Lunch & Learn” session on “Programmability” and we wanted to automate the login and delivery of XML to Cisco Prime Network Services Controller during that session.  Rob’s bigger idea was to develop the tool further to be able to login to many systems and have some of the needed XML already catalogued.  Hours of ‘hobby time’ both developing the app and cataloguing XML from what I can see!  The app that he’s posted on github has a structure and catalogue to run against Cisco UCS but it can be expanded to support other systems easily enough (Rob has a newer version that he’s working with…).  All of the systems that we work with have an API guide available.  After the app has been downloaded it needs to be unzipped onto a machine running Python… because it’s written in Python… with these modules available (default modules):

Side Note.  It's worth mentioning that the path of least resistance is probably to clone/create/spawn a Linux-distro VM and run from there.  It works fine on a Mac, Windows just might cause you to be looking at things that are unassociated with the app...

 

I’ve unzipped, what have I got in front of me?

Once unzipped, the application has 3 levels of directory and file structure, these directories present a hierarchy of the application, the application’s modules/classes etc. and some pre-built XML files.

Here’s the layout:

File Structure

The top-level files are where you’ll spend most of your time.  Under the “data” directory, the directories then get into the particular system that we’re sending requests to.  That’s “UCS” alone in this case.  The XML files have been catalogued as part of the app in the “b” directory (‘b’ for B-Series UCS).  This is basically what we were doing in Part 1 but many XML strings have been captured instead of the single one that we did.  The classes reference each of the XML files and provide the context needed to deliver them + log.  Some of the XML files are targeting specific areas of the UCS system.  Those XML files will be indexed in the relevant class… e.g. “network-MAC-pools.xml” is for MAC pools stored by the system so they sit in the “network.py” class as a re-usable ‘module’.  This modularisation is the right way to write an app such as this.

To use the app it’s wise to use an Integrated Development Environment (IDE).  I’m using Sublime Text, you can use whatever you feel most comfortable with.  If we open the “main.py” file within the IDE you’ll see a starting point of the application – there’s a lot in there!  There are dependencies across the app as you move through the classes (which are like re-usable modules) and XML files.  The relations break down as the following:

GeneralAPITool Dependencies

Each of the arrows above has a pointer aimed at an inheritance statement (identified as an “import” line).  The inheritance of a given function is basically in the opposite direction to the pointer; the class is ‘sucking in’ what it’s pointing at.  If we were to add a new system, such as Prime Network Services Controller, Prime Data Center Network Manager, Nexus 1000v (VSM), etc. we would add directories under data folder in line with that system.  E.g. Nexus could be ‘/data/nexus/classes/’ + ‘/data/nexus/xml/’ with classes and XML broken down as appropriate.  The new system would then be imported and added into a new class using main.py as a guide.

What do all these imports give each of the modules?

Let’s walk through some of the diagram briefly…  All of the purple modules are Python modules and they each do a particular pre-built ‘standardised’ function that some of the newly written classes reference.  e.g. urllib2 offers a pre-built way to interface with a HTTP-based API (i.e. REST or SOAP) as it’s a library for opening URLs.  The hyperlinks listed further up in this post provide extra details on those default modules.  We then move onto the application’s classes written for this app.  The “main” class is where you drive the app from (in this case it has code populated for UCS).  It has an ability to log including error logs so that explains the arrows to the appropriate module + class.  For “main” to drive things it relies upon an understanding of the managed system.  The import of “ucsclass” gives it that logic for UCS.  “ucsclass” then in-turn pulls on the logic of more specific ‘UCS sub-function’ classes; hierarchical and modular in a logical sense.  It also logs errors…  Lastly, the only other newly written classes unaccounted for are “myFunctions” and “XMLFunctions”.  “myFunctions” is the engine that delivers XML to a system.  It makes use of “XMLFunctions” which is a class used to load, capture and manipulate XML.  Manipulate?  We need to manipulate XML because of the authentication mechanisms built into the way many APIs work.  In the case of UCS a successful login gets a CookieID sent back in the response from the UCS system.  The same CookieID then has to be present in every other request to the system otherwise it seen as an unauthenticated session.  “XMLFunctions” does the relevant parsing and editing to make that work.  Both “myFunctions” and “XMLFunctions” also need to log errors…

 

How do I use the app?

As a first step, I would suggest that you quickly update the address and authentication details of your UCS instance.  The UCS instance could be a real system or an instance of the Cisco UCS Emulator.  This edit needs to be done in “main.py”:

UCSInfoWe now have a valid starting point for the application as far as managing UCS is concerned.  What’s all of this endless code in main.py though?  Well, it’s actually ‘everything you would ever want to do with UCS’ and the reality is that you may only want to do a subset of what’s been coded.  So, the second step is actually to make a copy of main.py and give the new file any name that you want.

Once the copy of the file has been opened you’ll want to know which bits should remain fixed and which bits are for you to play with.  Everything up to here needs to stay:

Do Work After Lines

Anything beyond those lines is where you can test using a python app to read and write against UCS using its API!

 

How do I use it… practical examples:

Hmmm, let’s scroll down this mind boggling text… and… yep, how about we spread a few things across a few files…  Here’s the flow:

  • File 1 = Get some information about the UCS Fabric Interconnects and print it to the console.
  • File 2 = Print the VLAN DB to the console -> Create a new VLAN -> Print the VLAN DB to the console.
  • File 3 = Print the org list to the console -> Create a new org -> Print the org list to the console.
  • File 4 = Remove the previously created VLAN -> Remove the previously created org.

File 1:

  1. Keep “getFIDeviceInfo”, “getFISystemStats” and “getFIFirmwareVersions” def sections below the lines highlighted above and save a new file.
  2. Edit the list right at the bottom of the file to change what information is fed back to us (i.e. a main.’def’ line to ‘print’ each of the items above.  So, that’s “Main.getFIDeviceInfo”, “Main.getFISystemStats” and “Main.getFIFirmwareVersions”).
  3. Correct a typo that I’ve noticed under “def getFIDeviceInfo”: “blades = self.ucs.getFIDeviceInfo()” should actually be “blades = self.ucs.fi.getFIDeviceInfo()” as it needs to reach down to the “fi” class.  I’ll mention that one to Rob!
  4. Run the file.

An output:

File1

File 2:

  1. Keep “getAllVLANs” and “createVLAN” sections below the lines highlighted above and save a new file.
  2. Re-order and edit so that there is a copy of “getAllVLANs”, then the “createVLAN” def and then another copy of “getAllVLANs”.
  3. We need to differentiate the first and second run of “getAllVLANs”.  Append “1” and “2” onto the end of each def entry.
  4. Edit the VLAN name and number to whatever you want within the “createVLAN” def.
  5. Edit the list right at the bottom of the file to change what’s printed to display what we want (i.e. a main.’def’ line for each of the items above.  So, that’s “Main.getAllVLANs1”, “Main.createVLAN” and “Main.getAllVLANs2”).
  6. Run the file.

An output:

File2

File 3:

  1. Keep “getAllOrgs” and “createNewOrg” sections below the lines highlighted above and save a new file.
  2. Re-order and edit so that there is a copy of “getAllOrgs”, then the “createNewOrg” def and then another copy of “getAllOrgs”.
  3. We need to differentiate the first and second run of “getAllOrgs”.  Append “1” and “2” onto the end of each def entry
  4. Edit the Org name and tag to whatever you want within the “createNewOrg” def.
  5. Edit the list right at the bottom of the file to change what’s printed to display what we want (So, that’s “Main.getAllOrgs1”, “Main.createNewOrg” and “Main.getAllOrgs2”).
  6. Run the file.

An output:

File3

File 4:

  1. Keep “deleteVLAN” and “removeOrg” sections below the lines highlighted above and save a new file.
  2. Edit the VLAN name and then the org name to match what you created in each of the def entries.
  3. Edit the list right at the bottom of the file to change what’s printed to display what we want (“Main.deleteVLAN” and “Main.removeOrg”).
  4. Run the file.

An output:

File4

Voilà!

 

What now?

Walk through the code lines and work out what they’re doing.  Work out what classes reference what and why.  Have a play with the app.  Build on it if you feel comfortable.  Feel free to ask any questions in the comment section of this post or send me a message via “ASKSOR” which comes up when you hover over “ABOUT THE BLOGGER”.

Capturing DevOps – Part 1 of 2

Ok, so “Capturing DevOps” might be taking it a bit far as far as this post is concerned!  DevOps, however, is a subject that I’d like to go into more detail on so that’s why this is part 1 of 2… but for now I’d like to stay true to my promise of showing how to capture the XML sent to and from UCS’ RESTful API.

Capturing raw XML is a relatively straight forward thing to do to be honest.  At the end of the day, a contiguous block of XML is ordinarily wrapped in a common IP packet and therefore capturing a relevant IP packet and looking into its payload data will give you a lot of what you need.  This is a little different to CLI and carriage returns…  Wireshark can help with IP packet capture, including XML (or JSON) data of course.

XML becomes useful to a DC or Infrastructure SME when you can look it as a human with a basic understanding of what is being sent/received and then work back from there to translate it into something less like computer code.

goUCS is a tool that can help with that when looking at UCS.  goUCS has quite a wide remit.  Its purpose is to capture actions and make them repeatable (i.e. adding variables where needed).  We are just going to use it to do the capturing bit today.

Where to start?  First a snapshot of what goUCS is in a little more detail… I’ll copy and paste this because… well, it’s easier:

goUCSDesc

Secondly, I’ll just mention that the setup is straightforward enough for me not to bore anybody with the details.  Download zip, extract it, add folder to system path.

Thirdly, let’s party!  Here are the steps in straight-talking language:

  1. We open a UCS Manager session.
  2. Within a cmd window we go to the extracted goUCS folder and navigate to the “bin” sub-folder.  “goucs filterlog logtail” is then entered.
  3. We go back to UCS Manager and perform a configuration task in the GUI that we would like to view the XML for.
  4. We then go back to the goUCS window and then copy & paste the XML dump into a text file.
  5. We use the XML as we see fit.

Straight-talking images:

goUCSFlowImage

Now, “We use the XML as we see fit” is quite an interesting area.  UCS has a python SDK that you can download that’s very capable – something to maybe take a look at…  However, a colleague of mine decided that he wished to create his own ‘focused on what we want to’ SDK that can be used across all of the RESTful APIs within our data centre stack including the UCS API that we’ve focussed on above.  This allows us to move to a model of programming across hw and sw infrastructure components all from one tool (notwithstanding that UCS Director is actually the right option for that kind of control…).  The capturing and storing of XML for given actions was part of his app development.  In the next part of this update I’ll be running through how that app works and practically demonstrating what ‘DevOps’ is about.  Until then, I’ll leave you to do some batmailing on your batphones!

Humanised security and the real world

TIL opening up the possibility of abstracted security policies probably produces just as many questions as it does answers.

There is often a big bonus to be had from having people from multiple areas of expertise in the same room when they share a common goal but have their own institutionalised view on the uniques of their organisation and the IT platform(s) hosting their apps.  In the case of a particular meeting I was involved in (and I will mention that I’m not typecasting the people involved into the rather blunt description above!), it made approaching the realities of moving from a data centre security model historically defined by the traditional coupling of endpoint ‘location’ and ‘identity’ to one that doesn’t have that “burden”.  This new option could potentially be put under the huge umbrella of ‘software definition’ which, metaphorically speaking, is now an umbrella that has the niagara falls crashing on top of its 2 square mile surface area with a 4 foot tall man cowering underneath!.

On a basic level, the advent of distributed virtual firewalling (and the diminishing no. of designs based on a multi-context service module approach) has addressed:

  1. The problem of hairpinning through an aggregatory/central stateful device to support a virtualised server and desktop workload environment.
  2. The avoidance of larger sizing of firewall appliance(s) when compared to historical sizing (i.e. this includes paying more than we have in the past).  This would be needed to deal with additional East-West [10GE] firewalling in a virtual environment hosting multiple security [sub-]zones.
  3. The ability to position multiple firewall ‘contexts’ close to the virtual workload on commodity x86 hosts… tied to the workload in fact… thus, they’re also mobile and potentially mult-tenant in nature.

In addition, the close proximity to the virtual workload has also added the ability to understand and tie-in with the platform that it sits upon better – i.e. the hypervisor.  It’s possible to define policy based on ‘humanised’ items such as definitions that we put in names and IDs.  For example, very simply put, the name given to a virtual machine could automatically cause it to inherit a pre-defined security policy.  The identity of the endpoint and its location are then separate.  We’re no longer talking about IP host addresses + prefixes when agreeing on where to position or drop VMs.  A server/virtualisation subject matter expert (SME) is no longer potentially looking for the path of least resistance because ‘we know that a virtual network in the drop-down list for vNICs is pinned to a firewall ACL more open than the one above it in the drop-down list’… ‘I just want want to get this working’ is perfectly understandable.

The questions though… How do I take my existing E-W associated firewall policy and migrate it into this new world?  Do I mimic it all?  Do I standardise more general options and drop into those?  Would that actually work?  When the automation engine or an administrator drops a VM into a given virtual network how can I wrap a security policy around that without adding new rules and policy each time?

It’s much easier when I have a blank canvas-style shiny new data centre or all of the services/apps/’tenants’ are completely new!

 

An attempt at answering the above from a Systems Engineer’s perspective…

…based on currently shipping Cisco products such as Cisco Nexus 1000v and Cisco Prime Network Services Controller + Cisco Virtual Security Gateway.

There is a possibility that this effort is part of a larger DC-related project.  A move of security policies may have to include historical definitions of firewall rulebase as other bigger shifts in the DC architecture are quite frankly enough to handle.  We have existing VMs with a naming standard but its not always as granular or ‘selectable’ as what we’d prefer.

My feeling is that the process could look like this:

Migration to VSG

The idea above tags workload in order to identify it easily while not initially linking to any definition of policy.  Nothing is broken by the names of port-profiles but you have an identifier readily available for when you need it (which comes in the latter stages of the flow above).  We can collect the port-profiles and other attributes in groupings (which go by the name of “vZones”) ready for use when needed but a ‘big bang’ approach hasn’t been necessitated up front.

vCenterDropDown

Nexus 1000v view

PNSC

Opinions may differ:

I’m fully aware that my thought process around this subject may go against the thoughts of my peers, individuals or collectives more observant than I and those that have visited this subject a few times more than I.  I’d be interested to hear just what you think about this.  If we look at the future of application hosting you have to feel that this step change is necessary, how different organisations choose to get there will of course differ.

 

Supporting background information in the blogosphere and t’internet:

A brief port-profile introduction
A more in-depth overview
IP Space VSG 101

 

p.s.  For those looking at CLI and thinking ‘Tut’, there are APIs available!

A blogger’s perspective (1st post)…

The year is 2003 and “the boy” is handed his first view of console access to a Cisco switch by a chap going by the name of Mr Ken Worthy.  He gets shown a basic configuration and then a mission starts, a mission to know every little detail about that and every switch and router that they have along with their capabilities, to nail-down the perfect configurations for the particular organisation that he works for and to make the process of adds, moves and changes as optimised and ‘catalogued’ as possible (some network monitoring sensors were disabled in the making of…!).

The need for one such optimisation arises because he is fed up of being pestered to move interface configuration lines from one port on a switch to another port on another switch when he has more pressing and pro-active work to do; there’s a team dedicated to moving IT equipment between desks/buildings and the network changes are the only bit of the process when they need to involve someone else.  He starts by defining some smart port macros for different types of endpoints and pushes them out to every switch.  These macros have variables in them, most notably for the VLAN(s) and L2 security toolkit options that should be configured – different endpoints, for many reasons, sit in different segments.  This makes the process a little faster and standardised but the network team are still involved in this routine and basic task.  He then works with a developer in the IT team to write a web-based application (after evaluating the market for such a tool… that of course would have to be zero or next to zero cost…).  This application will give the ‘move team’ their own means of doing the same task, notably without involving said “boy” or his colleagues.  The app user selects switches + pre-authorised port numbers and the app accesses those switches, defaults the port configurations, and then lastly, it applies a macro with the relevant variables defined.  With the advent of app/server virtualisation and shared services initiatives the same app becomes more relevant to work in the DCs.

What he didn’t appreciate at the time was that he and his colleagues’ were performing a 5* example of what was wrong with the provisioning and changing of ICT services.  Work-day time, personal time, overtime; time and money put into customising-against and optimising a very basic process that could even have been done before by someone else or be a standard need everywhere.  He also later found out, while blogging at http://rbcciequest.wordpress.com, that one of the config lines in one the macro was incorrect.  How?!  He knew the switches and their options inside out, he’d tested it, he’d asked an expert… human error was obviously still a possibility, and now it was being repeated within a non-standard app.  There are many other stories to tell, especially when looking at the to-ing and fro-ing in the DC in the aftermath of this time!

The business’ simple requirement was to move staff, an app had been built, the app had a requirement of the network, the requirement was for the app itself to trigger configuration changes across the network by accessing multiple touch points and then dropping a static script written in a network-device specific language (CLI), replacing variables point-in-time.  It was all too complicated and specific.  Yet, it was still beneficial and worthwhile.

It’s now 2014, the apps are more complicated and demanding, the criticality of ICT to core business is on a different level compared to then, uptime is vital and there are often much bigger inefficiencies as the one described above.  Data Centres are at
the core of ICT services and ICT is an enabler (and disabler!) of business
more than ever before.  We’ve got a lot to look forward to, much non-trivial learning has been brought with us from the past, the top-down push of cloud consumption models are displayed in the innovation and [application programming] interfaces that are here today.  This blog is about looking at this new wave of service consumption models, technologies and dedicated solutions.  Let’s cross the chasm and destroy the hyperbole!

FYI The next couple of posts will be hold a theme of ‘Real-world programmability across the DC stack’.  They also won’t be written in the 3rd person!

About this blog