Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Network Automation In The Field: Page 2 of 2

For this blog, I chose an automation scenario to start a packet capture when network utilization spikes on a specific interface. In my practice, getting packet captures based on events is a pretty common need. We tested features in Cisco's Embedded Event Manager. Other vendors like Force10 and Juniper also have scripting and automation environments that are being built into their equipment. Force10, for example, is taking a broader approach and looking to let engineers develop in many different code bases, like PHP or Perl. The language itself will not ultimately decide who wins or loses in the network automation arena. The features and functions that vendors expose to automation, will be a deciding factor.

Frankly, the installation is a little difficult. Cisco provides an easy-installer.tcl program that is supposed to set most things up for you. It did not. In fact, I tried two different IOS releases (15.0 and 12.4(24)T) and the most recent versions of all scripts and had no success with easy-installer. I did have success manually setting it up, and now that it is done, in retrospect, it was something that could be repeated pretty easily.

For the test, we set up a watchdog that would look at the load percentage on a particular interface every 30 seconds. If it got above 75 percent, we had the watchdog fire off a TCL script, which we downloaded from Cisco's website, that starts a packet capture for that interface automatically. It stopped collecting after 30 seconds went by or when the router ran out of the buffer space we allocated to it. This worked perfectly. We simulated traffic over the link to push the load and about 15 seconds later I had a .pcap file sitting in my TFTP directory to review.

The main drawbacks were the small maximum buffer size (1024 Kbytes) and the fact that if you wanted to know what was eating up 75 percent  of the bandwidth on your interface, you don't want the TFTP copy of the .pcap file to take up the remaining 25 percent when it is transferred to your central TFTP server. For the TFTP transfer, you could certainly write a delay into the export TCL script to avoid this. On the buffer size, you can do filters and limit the actual data stored from each packet, but you may still find it to be a limiting factor.

Overall, the automation worked very well, and our team was impressed. It was a small example that solved a very real problem for us and is just the first step along a path to leveraging automation more in our production networks.