I went to a trade show for NetBrain recently, and one thing that kept surprising me was how much people knew about NetBrain’s Dynamic Maps, yet how little they knew about Runbook Automation. One of NetBrain’s core technologies and a very compelling feature for network engineers is the Runbook tool – NetBrain’s solution for script-less automation.

I get that the word “automation” might be intimidating network engineers these days, because of the learning curve with programming languages, because complex business processes are hard to map, and because technology marches on; people may automate something, and then find they need to re-do large parts of it when their environment changes in the slightest.

NetBrain has produced an incredible tool here, which is not only user-defined but is done entirely without scripts. By parsing individual tasks into the Runbook Automation tools…

…suddenly the network engineer can create complex and abstract tasks without ever having to write a line of code. In this post, I’ve gathered and parsed information from our support staff and investigated 6 of the most common automation use cases NetBrain clients are implementing on their network.

#6: Collecting Data for Incident Escalation

Here, the client has created a Runbook to gather OSPF data from their network. Once all of the data is collected and visualized, it will be made available to more senior members of the staff who are troubleshooting a network issue.

This might look like a complex diagram, but let’s break down the process of what exactly is occurring here.

1. A custom Qapp is highlighting and gathering all of the routing information present on the designated environment, and compiling this information into several notes that are placed on the Dynamic Map. Here, in this example, all of the relevant OSPF information –
2. A second Qapp is monitoring the running status of OSPF – it’s simply highlighting the neighbor count and OSPF routes on the map.
3. A batch CLI node (which is the automated execution of CLI commands, more on that in #2) is collecting relevant information about these devices in order to have more useful information to be escalated to higher tier engineers.

This is important for several reasons.

First – this reduces the overhead involved in troubleshooting; team members no longer need to duplicate the retrieval of basic information from the network in order to do their job properly. It also enables multiple teams, like networking and security, to work together in the event of breaches or security incidents since everyone’s working from the same frame of reference.

Second – this Runbook also creates a snapshot of the network at a certain point in time and can be used when planning out future network changes to avoid possible errors or outages.

#5 & #4: Integration with Service Now / “Just-in-time” Automation

Any IT department that gets large enough is going to need a ticketing system, among other services. Where this gets tough is when people find themselves hopping through different applications and silos in order to find all of the relevant and necessary information in order to troubleshoot an issue, or when a change process becomes stuck because it hasn’t received a stamp of approval yet.

NetBrain offers its own internal verification system, but it can also integrate with third-party ticketing systems like ServiceNow.

Being able to link ServiceNOW tickets to a map comes with multiple benefits.

1. Change management events can still use ServiceNOW as an integrated approval platform, instead of creating multiple areas where people need to sign off on network modifications.
2. The map of a problem area or potential network change can be directly linked to the ServiceNOW ticket, allowing everyone who has access to the ticket to also have access to the area of the network being affected, creating an enhanced degree of visibility for IT processes
3. Problems that receive a ticket can trigger NetBrain via API to create a map of the problem area. (aka “Just-in-time” automation)
   

This diagram is showing a ServiceNOW ticket being created and linked together with a NetBrain Dynamic Map, as seen through the NetBrainMapURL in the top right corner. This map represents the ‘problem area’ identified with the ticket. During ‘Just-in-time’ automation, the system performs basic diagnoses such as an Overall Health Monitor and Raw CLI data collection (seen in Runbook Automation Tools) and provides this information to the engineer as they arrive on the scene, eliminating the time they’d otherwise spend performing the same tasks.

The best part is, this isn’t limited to one application. Any ticketing system with an API can be integrated into NetBrain to achieve the same effect.

#3: Compliance Checks

This Runbook is automating and recording the results of compliance checks. In this specific scenario, the client needs to know if the devices contain unsafe community strings, strong password encryption levels, SSH access, and VTY timeouts beyond safe thresholds. Afterwards, it will take a configuration snapshot that will be archived for the user.

This type of runbook is useful for several reasons

First – If you are ever in a position where you need to provide security information about your network to a third party, this Runbook will streamline your compliance timeline down to a matter of minutes.

Second – This information is incredibly valuable to security and networking teams, as they’re notified of potential security issues that may be lurking in parts of the network they don’t deal with on a daily basis. Once they have this information, the #2 Runbook would come in handy!

#2: Automating Command Line Execution

Here, the user is issuing commands in batches to multiple devices on the network. Once these commands have been executed, they can be saved as their own Runbook. Thanks to a robust CLI parser library, NetBrain can execute a wide range of data collection and troubleshooting commands on just about any vendor that has a CLI. If you need to regularly pull specific information from a device about, for example, interface configurations, ACLs, VLANs, virtualized infrastructure, routing tables, NetBrain likely already knows the specific actions you want to enter, and has them available to you in the ‘Execute CLI Commands’ pane. From there, it logs into the device or devices and collects the information for you.

This is useful because it essentially automates a troubleshooting solution into a button click. If the Runbook itself clearly defines what the commands are meant to do, the Runbook can be effectively passed around the networking team and used to resolve this issue quickly. Speaking of which, this hems very close to the #1 choice in this list.

#1: Troubleshooting Repetitive Complex Issues

An aggregation of the strongest parts of the previous automation use cases, this is a clear front-runner for “most automated task.” Half-documentation, half-troubleshooting, a use case like this also demonstrates the if/then nature of the Runbooks – depending on the results of certain steps, different branches within the decision tree are activated.

This diagram seems to be rather complex, but follows a similar (if more involved) tree of logic that all runbooks follow. Once the original Qapps (Monitor OSPF Neighbors, Highlight OSPF Configuration) are done gathering intelligence, we encounter the first ‘branched’ Runbook.

If the OSPF states of certain devices are not established, the system will present the user with 5 variant Qapps to troubleshoot various ‘non-functioning’ states (Not Established, INIT state 8, Loading, Two-Way State, and Exstart or Exchange State). Based on the output of the data collection, the user can take multiple branching troubleshooting paths through the runbook, each containing a slightly different set of processes and commands to help tackle the issue at hand.

As you can see, NetBrain has a lot of out-of-the-box automation capabilities that can help with troubleshooting, documentation, and service integrations. It is as essential to the feature as its robust discovery and Dynamic Mapping features.

It’s easy enough for beginners to pick up, but robust enough that power users won’t easily reach the upper limits of what it can accomplish. With a Runbook pointed at the appropriate network or business processes, an engineer is empowered beyond what they’d normally be capable of.