Automation = f ( Standardisation )

Never forget:

If you haven’t standardised your IT-Environment, you can’t automate it.

Last week I had to automate some networking-tasks using Cisco UCS Director.

I knew it better, but I wanted to be kind and began to implement the desired UCSD-Workflow covering all individual aspects of the already deployed environment.

  • Took me one hour of work to realize that it was hopeless.
    • Ifs, Thens, Elses… I learned a new word in this context: „dowdy“ 😉

Nobody likes overengineered workflows

So, Automation is at least a two step process:

  1. Standardise everything you want to touch during automation workflows
    • dispose all existing bells and whistles
  2. automate popular tasks
  • Don’t waste your time automating rare corner cases.

What and how to standardize?

A quick brainstorming:

  • System Architecture / Logical Structure: Block-Building, Device-classes
  • Topology: Use the same interfaces to connect the same entities.
  • Numbering: Find a logical structure
  • Naming: Might be descriptive only – needs to be consistent, too

Linux: SNMP with Python

Background: I plan to design and implement a controller-based QoS-Solution with distributed control-plane using SNMP and RMON.

How to send SNMP-Requests in Python?

Why Python? It’s an arbitrary decision, every programming language might be sufficient. For the moment, I prefer Python for new projects.

I decided to try Easy-SNMP, since good performance and a nice python-programming-interface seem to be killer-features for me.

EasySNMP homepage
EasySNMP documentation

A development environment

  1. clone an ubuntu-server VM

https://allones.de/2017/11/17/linux-quick-and-…ab-vm-deployment/

  1. install net-snmp

sudo apt-get install libsnmp-dev snmp-mibs-downloader

  1. install gcc, python

sudo apt-get install gcc python-dev python-pip

  1. install EasySNMP

pip install easysnmp

Enable SNMP on a Router
Never ever enable SNMP-Access for everybody, don’t even think about it.
Use an ACL permitting only the SNMP-Manager.

ip access-list standard ACL_SNMP
    permit host 192.168.2.89

snmp-server community READ ro ACL_SNMP

! just as an example System-Variable
snmp-server location allones.de

Access the Router via SNMP
The router’s LAN-IP is 192.168.2.72.

I like the „Session“-Interface:

user@snmp-server:~$ python
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> from easysnmp import Session
>>>
>>> session = Session(hostname='192.168.2.72', community='READ', version=2)

Be aware to poll the Object-Instance, not the Object-Tree-Position.
Wrong

>>> location = session.get('sysLocation')
>>> print location
<SNMPVariable value='NOSUCHINSTANCE' (oid='sysLocation', oid_index='', snmp_type='NOSUCHINSTANCE')>

Correct: Specify an Instance-ID

>>>
>>> location = session.get('sysLocation.0')
>>> print location
<SNMPVariable value='allones.de' (oid='sysLocation', oid_index='0', snmp_type='OCTETSTR')>

Works!

How to access the return-value?
How to verify the Datatype?

I’ve been using the Cisco-developed TCL-Interface for years, the „snmp_getone“-command there, where you had to parse the return-value (a string similar to the „location“-Variable above) applying regular expressions… Weird.

Just remembering the blog post, which motivated me to learn TCL… Ten years old, how time flies!
Read: „SNMP with TCL“ by Ivan Pepelnjak

Might this be easy with EasySNMP?

>>> print location.value
allones.de

>>> print location.oid
sysLocation
>>> print location.oid_index
0

>>> print location.snmp_type
OCTETSTR

Isn’t EasySNMP beautiful!? 🙂

Linux: Quick and Clean Lab-VM Deployment

I often need for quick tests a clean Linux Server, a VM nowadays.

I decided to save DRAM in my virtualization host and to:

  • not use a GUI
  • SSH with standard text-editor are quite fine for me.

Ubuntu 16.04 seems to be a good choice to start with.

  1. Apply Updates,

sudo apt-get update && sudo apt-get upgrade -y

  1. install a text-editor //I like joe since it remembers me of turbo-pascal/wordstar 😉

sudo apt-get install joe

  1. change the hostname of the server-vm
sudo joe /etc/hostname
sudo joe /etc/hosts
  1. add a reliable (static) IP-Address
sudo joe /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens160
iface ens160 inet static
address 192.168.2.89
netmask 255.255.255.0
gateway 192.168.2.1
dns-nameservers 192.168.2.1
dns-search lab.local
  1. reboot the VM

There are other possibilities, but just ifdown/ifup won’t stop the dhcpd-client – the easiest way [but uncoolest, who cares?] is to reboot the VM, takes half a second…

sudo reboot

 

Todo: Create an UCSD-Workflow for this

Todo: Fix the buggy „always 1“ section-numbering

Cisco UCSD: Custom Workflow Task

this is maybe just a note for myself as i found out that the UCSD-Documentation is in polite wording „somehow incomplete“.

After re-engineering some existing workflow task-scripts and playing around a bit, the good news:

  • it’s simple and straightforward to create custom workflow tasks on your own.

Background

I wanted to create the name of newly provisioned VLANs automatically:

  • the IP-Subnet was provided by an IPAM, e.g. „10.2.3.0“,
  • the VLAN-Names should have fixed length, had to be padded („010.002.003.000“).

The workflow takes two task inputs:

  • the „network“,
  • the char to be used to pad the network-string to the fixed length
    • as special feature, this parameter is optional („Mandatory: false“)
UCSD - Custom Task Inputs
Custom Task Inputs

A javascript will build the padded vlan-name – the task output:

UCSD Custom Task Output
Custom Task Output

The Script fetches the inputs:

input.<Input Field Name>

a) mandatory input:

var subnet = input.subnet;

b) optional (with default-value „0“) input:

  • length „0“ => optional parameter not set

var pad = "0";
if (input.pad.length==1) {
  pad = input.pad;
}

The padded result is published to

output.<Output Field Name>

c) padded subnet

output.paddedSubnet = paddedSubnet;

 

The Script itself is straightforward:

function expand(num, size, pad) {
  if (num.length<size) {
    return expand(pad+num, size, pad);
  }
  return num;
}

var subnet = input.subnet;
var paddedSubnet = "";

var pad = "0";
if (input.pad.length==1) {
  pad = input.pad;
}

logger.addInfo("---------------------------------");
logger.addInfo("input.subnet = "+subnet);
logger.addInfo("using pad = ["+pad+"]");
//
var parts = subnet.split('.');
for(var j=0; j<parts.length; j++) {
  if (paddedSubnet) {
    paddedSubnet += ".";
  }
  paddedSubnet = paddedSubnet + expand(parts[j], 3, pad);
}

output.paddedSubnet = paddedSubnet;

logger.addInfo("output.subnet = "+paddedSubnet);
logger.addInfo("---------------------------------");

 

Cisco UCS Director (UCSD) as Unified Infrastructure Controller

Yes, I agree: this product name can’t get worse.

What’s not good with the product name „UCS Director“? It needs explanation!

Nobody in this world could guess it’s feature-set, everybody thinks it’s some additional umbrella-management on top of the UCS-Manager or UCS Central.

„Unified Infrastructure Controller“ would fit much better, since the UCSD not only automates UCS-Components, but the whole Datacenter (and more) including LAN/SAN-Switches, Firewalls and the virtualization environment like vSphere or Hyper-V.