NXOS – Bash scripting at the CLI

Every now and again you see a snippet of complex CLI syntax that gives you pause for thought. Last week I saw the command below in a change procedure. The command was being used to verify baseline BGP neighbor state and re-verify after a policy change.

show ip bgp peer-template eBGP_Peers | egrep default | sed 's/default://'  \
| tr -s '  |\n' | tr -s ' ' '\n' | sed 's/^/show ip bgp nei /' \
| sed 's/$/ adver | grep \//' | vsh

I was a little daunted by the complexity of the command at first. I was slightly embarrassed too, as I had no idea what the command did. I learned that this command finds all neighbors which use a named bgp peer-template, and lists the prefixes they advertise. In this post I’ll break down the command and share the love about NXOS CLI and bash scripting. Continue reading

Does config automation demand inflexiblity?

Imagine you’ve just designed and deployed a data center. It was hell but you are smiling. Your design is homogenous, simple and elegant. A greenfield datacenter full of shiny, identical network devices. Because the design was so consistent and repeatable you scripted the generation of the device configurations without too much hassle. This is a network with an easily ‘provisioned’ network configuration.

But day-one provisioning is only one part of the puzzle.  The real prize is a centrally ‘controlled’ network configuration, where all config changes happen centrally and a configuration policy is enforced for the lifetime of the network.  Whilst this seems like the holy grail, you need to understand that you will have to trade some flexibility to reach this easy-to-operate nirvana.

Continue reading

Get more juice from your network lab

Photo by http://www.flickr.com/photos/clemmac/ – some rights reserved

We have a network lab?

Spirent presented their new lab-management software, called iTest Lab Optimizer, at network field day 4 recently.  Their product name isn’t catchy, but it is very descriptive and addresses a market need.  The simple fact is that most lab networks don’t get optimised to their full potential for some of the following reasons:

  1. Nobody knows what is in the lab (or that one exists) – Inventory Management
  2. The availability of the lab devices is unknown  – Availability and scheduling
  3. The patching status of the devices is uncertain – Fixed undocumented patching.
  4. Setting up your device-under-test is hard and takes time,  so you try to prevent other users from mangling your config. – DUT config management