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.
There is indeed a lot of scripting going around. Googleing for ideas and solutions takes you to questions 99% of the time, instead of solutions or leads to them. In the end, I usually end of reinventing the wheel, while i’m sure there are people driving around already.
Luckily, there are some nice thorough bloggers like you, that help save the day. :-)