Like all good things, network automation emerged during a foray into something totally different. I set out to write about network packet capture and some tools and techniques that you can use to gather more information about your network, to troubleshoot problems and finally, to end all of the finger pointing when there is a problem. As I started thinking of the first step in this process, collecting the packets themselves, I spent some time considering the challenges that you would face along the way. Chief amongst these challenges is the fact that unless you have already invested in a huge traffic collection infrastructure, or are utilizing an analytics company, you will probably not have the traffic captures that you need when you need them. Without those captures, discussing packet-level analysis is a moot point.
This led me to thinking about how and where one might do triggered packet captures based on network events, and how you could automate this process. Up popped Cisco's Tclsh scripting and network automation scripts, which it refers to as Embedded Event Management, along with a world of possibilities that I think most engineers are not aware exist.
First, let me say that this is a new area for me, and one that I am busy testing, but at first glance many switch vendors have realized that network engineers need the ability to work like software engineers in order to cope with the rate of change in their networks. By this, I mean that the engineers need to be able to take their own intellectual property, the experience that makes them effective, and bottle it into a reproducible nugget that gets distributed across their environment and adds immediate value.
Want an example of this? Assume that you have a network interface that serves a remote retail branch and that every few days the link is pegged to 100 percent utilization and users complain of application response times. You have several choices in how you can collect data to deal with this situation. At the most basic level, you can use bandwidth monitoring software and technologies like NetFlow to know the "what" and "when" of this overload. But while NetFlow is a great traffic accounting package, it doesn't allow you to see the details of a TCP or UDP conversation, and the devil is always in the details.