Response: Scripting Does Not Scale For Network Automation

screencapture-etherealmind-com-scripting-scale-network-automation

About three weeks ago Greg Ferro from Etherealmind posted an article entitled “Scripting Does Not Scale For Network Automation“. It’s quite clear from reading the article that Greg really is “bitter and jaded“.  While I agree that there are challenges in scripting they also come with some large rewards for those that are able to master the skill.

In a subsequent comment Greg really hits on his point.. “We need APIs for device consistency, frameworks for validation and common actions. But above that we need platforms that solve big problems – scripting can only solve little problems.

I agree but for now we need to work with what we have available, and that’s no reason to stop scripting today. That said scripting is not a tool that’s going to solve every problem in IT. It might helpful for initial deployments, provisioning, backups, monitoring, testing, etc. but it’s rare that scripting will solve every problem. I personally employ a combination of commercial management solutions with scripting to achieve my goals. I’ve worked with the following methods and technologies: EXPECT/TCL, SNMP, PHP, PERL, XML, NETCONF. These all have their individual challenges but each can be used in their own fashion to help automate a task or process depending on the task or the vendor in question. If you need to-do something once or twice there’s no need for a script or automation, but if you are going to-do something daily or weekly across dozens or hundreds of assets then a script can be extremely helpful.

The point of writing a script is really two fold in my opinion, first to automate the task but more importantly to remove the human error element. I do a lot of my work in the wee morning hours when the eyes are bloodshot and the mind isn’t always as rested as it should be. It’s easy to make simple stupid mistakes repeating monotonous commands on dozens even hundreds of switches or routers. A script helps to actually do the work and it makes sure that I won’t accidentally blow something up, I’m really there just to monitor for problems or issues.

It should be no surprise that there’s effort required to maintain a script, it’s just like a commercial vendor maintaining a product. Here’s the changelog for a Perl script I maintained between 2003 and 2014  that utilized SNMP and TFTP against Avaya/Nortel, Cisco, Motorola/Symbol and HP gear. You can see some of the challenges that Greg referred to in his article;

# Changes:
#
#     May 04, 2011 (M.McNamara) added support for HP C-Class GbE2c and legacy P-Class GbE2
#                               thanks to Karol Perkowski for his code addition
#     Dec 28, 2010 (M.McNamara) added additional code to support ERS4500 being slow TFTP transfer
#     Dec 27, 2010 (M.McNamara) updated CISCO-PRODUCTS-MIB to cover ciscoCBS3120 blade
#     Dec 20, 2010 (M.McNamara) updated ASCII routine with OID s5AgSysAsciiConfigManualUpload
#     Aug 31, 2010 (M.McNamara) added routines to handle binary and ASCII data for Avaya ERS switches
#				also added code to keep 4 archive copies per device
#     Dec 02, 2009 (M.McNamara) cleaned up code added additional debug routines
#     Oct 23, 2008 (M.McNamara) added support for Motorola RFS7000 Wireless LAN Switch
#     Oct 22, 2008 (M.McNamara) added support for ASCII configuration files for Avaya ERS switches
#     Oct 10, 2008 (M.McNamara) added support for Cisco switches
#     Jan 22, 2008 (M.McNamara) added support for HP GbE2c (C-Class) switch
#     Apr 24, 2007 (M.McNamara) added support for WS5100 3.x software
#     Oct 24, 2006 (M.McNamara) added support for ERS1600 v2.1 release
#     Sep 29, 2006 (M.McNamara) added support for BayStack 470 PwR 48T
#     Oct 20, 2005 (M.McNamara) added support for Baystack 5510 24 port also added 
#				Ethernet Routing Switch (formerly Passport) 8600 code
#     Mar 01, 2005 (M.McNamara) incorporated a sub to check for the presence of the
#				proper filename on the TFTP server (/tftpboot) thereby 
#				eliminating the first script "readytftpbackup.pl"
#     Feb 25, 2005 (M.McNamara) added the ability to retry a failed backup
#     Jan 13, 2004 (M.McNamara) some minor bugs throughout code base
#     Jan 06, 2004 (M.McNamara) implemented a workaround for the Passport RAPID-CITY MIB 
#				> 3.2 problem, copied OIDs for Passport 1600 into 
#				 existing MIB along with required MIBS and added sub 
#				to handle 1600s
#     Jan 05, 2004 (M.McNamara) issues with SNMP MIB for Passport 8600 v3.3.4 is presenting
#				problems with the Net-SNMP perl modules and the old MIB 
#				cannot identify the newly added Passport 1600 switches.
#     Dec 11, 2003 (M.McNamara) resolved issue with Passport 8600 not backing up properly
#     Sep 17, 2003 (M.McNamara) added code to incorporate all BayStack switches into backup
#     Oct  1, 2003 (M.McNamara) added code to email status report to notify@acme.org
#				also added Perl script to weekly crontab

Will the scripts I write today be useless in two years, possibly but that’s pretty much the case with anything these days including your phone, your laptop, etc. While we wait for something else to come along the the scripts I write and maintain will be very helpful in making my job easier and making me more efficient.

Cheers!

PS: I’ve finally cleaned up the Scripting section of my blog, fixing all the broken links and updating all the code.

{ 0 comments }

Your customer needs help? Tell them to hire me!

831838_16000623-scale

This is a little off-topic but I've probably let this slide for too long and unfortunately I've been going around with this bent up anger for quite sometime now and it's time to vent and rant. I provide a blog and forum to the community as a way to help educate people and hopefully learn a little something myself along the way. I'm generally interested in targeting the actual end-user, the network engineer or system administrator that's working for Acme Corp. or Wayne Enterprises or the Umbrella Corp, hopefully you get the idea. Inevitably there will be a reseller or […] Read More

{ 1 comment }

CrashPlan filling up your SSD?

crashplan

Over the weekend I actually had some downtime and was hoping to play a little Planetside 2 until I noticed that my Windows 7 desktop was down to only 8GB of free space on my 256GB SSD.  A quick check with WinDirStat found that I had over 133GB of files in C:\ProgramData\CrashPlan, even though I had installed the software into D:\Program Files (x86)\CrashPlan. I've been testing CrashPlan for the past 30 days trying to decide if it was the best tool available for me to use in backing up the numerous desktops and laptops throughout the house. I had been […] Read More

{ 0 comments }

100% Cable Patching in the Closet?

590347_68559935

With the move to a new organization comes some adjustment and occasionally some surprises. While my last employer was very rigid and bureaucratic, my new employer is extremely flexible, deplores 'process for the sake of process' and is extremely fast paced. There are pros and cons to everything in life although I'm not going to talk about my employers today. Instead let's talk about patching in the closet, sometimes referred to as the ICR (Intermediate Communications Room) but more often referred to as the IDF (Intermediate Distribution Frame).  There are a few different mindsets when it comes to patching the […] Read More

{ 2 comments }

Network is Slow!

KONICA MINOLTA DIGITAL CAMERA

Those are the words that almost every network engineer loathes to hear, the "network is slow". And those words are usually spoken by folks who really have no idea of how the network works let alone the understanding to quantify the word "slow". In my past life I had built a fairly large dark fiber metropolitan network where the smallest link, outside of remote VPN offices, was 1Gbps. I spent years training the IT staff around me to understand the difference between a under performing application, an overloaded server and a congested (slow) network. In that past life I rarely […] Read More

{ 2 comments }