Category 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 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!