Jason: Hi. My name is Jason Baudreau. I’m joined today by Vin Smith, our Senior Trainee Engineer, David Femino, one of our Senior Solutions Engineers, and Shivani Phadke, who’s a Senior Pre-sales Engineer at NetBrain. You’ll hear from each of them later in the presentation. Today we’re going to be showing you what’s new in NetBrain’s latest release, version 7.1, but don’t be fooled by this incremental name change – this is a very big release.
NetBrain 7.1 brings a lot of new innovations to deliver better visibility and enhanced automation. This release also delivers on many features you’ve all been asking for:
• Enhancements to the dynamic map, which make it an even better user interface for your network.
• Support for SDN solutions, to extend visibility and automation across complex hybrid infrastructures.
• An enhanced change management module to better integrate with your existing change workflows.
• Next generation automation capabilities, which are driven largely by NetBrain apps and executable runbooks
• Proactive scheduled automation to deliver what we’re calling problem-based monitoring
• A new runbook to improve collaboration within your team.
I know about half of the people on the call today are not yet NetBrain customers, so I’d like to start with a brief overview of NetBrain’s technology and the challenges it addresses. We’ve talked with many network teams, and we found that they’re struggling to meet the demands placed on them. There seem to be two drivers for this. First, the networks they manage are becoming more complex. More often they are hybrid environments with physical, virtual, and now, Software-Defined devices, but that hasn’t changed how teams interact with them, that’s really still done one box at a time, through the command line.
The second factor is the number of tools used to manage the network. A lot of our customers tell us they already have too many tools, and half of them are shelf ware, right? They’re not being used. The challenge is that each tool is essentially a data island. So, when it comes to operational tasks like documentation, troubleshooting, making changes, or cyber defense, network teams are basically trying to connect the dots between all the tools, all the windows they have open, the CLI windows in those tools, etc., and this is very manual and time intensive.
We saw this as an opportunity and a need for a single integrated platform to provide better automation and visibility for any network. And with NetBrain you can manage your entire network through one console using a dynamic map as the user interface. First, NetBrain performs a deep network discovery to essentially decode your network’s design. Regardless of whether you manage an all Cisco shop, or if your network is a hybrid of physical and Software-Defined infrastructures, you can manage the entire environment in a single context; the context is a map.
Second, leveraging API integration to your tools. NetBrain can collect any third-party data and display it on the map, and you can turn this data on and off as you need it. So this ability to collect and analyze data quickly allows you to automate key tasks across your workflows, whether it’s for documentation, troubleshooting, again, changes or cyber defense. So let’s take a look at a few examples.
Here’s an example of automating network documentation.
This network has hundreds of remote sites which are accessible from a single overview map, and you can drill into any site to see it’s layer-three and layer-two topology and underlying design. For troubleshooting, here is an example of a slow application.
The application flow has been mapped across the network, and the underlying impact has been identified. Vin Smith, later on, will walk us through what’s new in the capabilities for troubleshooting a little bit later.
For network changes here’s a workflow to fix a security vulnerability using a change runbook, which you see on the left side of the screen here.
Shivani will show us this new runbook in action with a live demo, a little bit later on. And here’s an example of how NetBrain can map a security attack propagating the network to help you better understand its impact.
And if you have a security information and event management solution, maybe like Splunk, you can integrate it with NetBrain to trigger this kind of diagnosis at the moment an event is detected.
So in today’s webinar, we’re going to talk about enhancements to NetBrain’s two core technologies, the dynamic map, again, the user interface for network automation, and the executable runbook, which provides the knowledge interface – as we call it – basically, a way for the experts in your organization to document their network “know-how.”
So next, let’s talk about what’s new with the dynamic map in NetBrain 7.1. First, we all know that network documentation is one of the most important ways network teams share knowledge, right? Whether for onboarding new hires, or deploying a new network service that you need to actionize across the team. And network diagrams have historically helped to document that new topology. And we’ve had network playbooks, or runbooks, they’ve been used to document the network know-how, for example how to troubleshoot the new deployment.
In NetBrain 7.1, we’ve made the process of documenting network knowledge easier than ever, by allowing network experts on your team to customize a single, easy to access view, which includes information relating to a specific topology or design. That can include troubleshooting know-how in the form of a runbook, as well as history data and unique notes that the expert wants to share. They can do this in an easy to access location, and we call this Network Context. You can think of a Context as a way to document every aspect of a design to make it easier to operationalize across the team, or maybe as a brain dump from the network design team to the operations team.
Next up, we’ve talked to a lot of customers who love being able to map any part of the network in seconds, but they also want a group of pre-defined maps that look more like the traditional Visio diagrams they used to create by hand. So, before NetBrain 7.1, there was the auto layout capability to make the map layout more clean, but it didn’t provide the user the ability to perform an auto layout which could match their own preferred logic. For example, to align with their unique naming conventions, for example.
So, let’s say in the data center, where three-tier architecture is common, you may want a map to be laid out like this with the core devices at the top, the distribution in the middle, and access which is at the bottom. So now in 7.1, you can customize a layout template to use this pre-defined logic, and you can then apply that layout across many sites, automatically.
The third new capability relating to dynamic map is my favorite. It can be better integrated with your other tools to help you visualize any IT data in the context of a map. So within a typical NOC environment, it’s not uncommon to have a dozen or more tools, right? For fault monitoring, capacity accounting, performance, or security, the so-called FCAPS suite of tools. And each one of these tools is effectively a data island. It’s difficult to access and correlate information when you need it, say for troubleshooting.
Through REST API integration with your existing network management ecosystem, you can tie all this data together. NetBrain’s data view can be used to dynamically turn on and off information from each tool, and this is achieved through customization which you can do yourself, or we can deliver this as part of our services engagement with you.
Let’s take a look at these three enhancements in action, for the new auto layout, context map, and API integration. I’d like to introduce Vin Smith.
Vin: Thanks Jason. Now, before I cover some of the dynamic mapping enhancements in our latest release, let’s quickly review a simple way to create a dynamic map for our new NetBrain users. My network has been discovered in NetBrain turning it into a searchable comprehensive data model. I could search for lines in config files, hostnames, or IPs, to learn about the network, and through this search, we can create a dynamic map on-demand.
NetBrain creates topology maps embedded with configuration details. We can simply select neighboring devices to be shown on the map to instantly create an up-to-date topology diagram of the network. Our enhancements to the dynamic maps aim to easily provide context to engineers. For example, this area of the network could be running PGP, multicasting, or QOS, and engineers need to visualize different datasets depending on the task at hand. In our latest software release, we have made major enhancements to managing and organizing your network using the network pane.
The network pane provides both built-in and customizable views to organize your infrastructure devices. Whether you need to quickly find which devices are running a particular routing protocol, or which devices are running a given technology, like multicasting. NetBrain administrators can set up different views to help their team navigate complex networking environments.
When user selects a device within the network pane, a number of customizable context maps appear automatically. I could quickly drill into layer two or layer three neighboring maps, sitemaps, or custom diagrams from this view.
Imagine being a new network engineer at an organization, trying to familiarize yourself with the network and technologies running. Simply selecting a device allows you to view this device in multiple contexts, it’s a part of my core network, and it’s part of a critical application path, and I can drill into the relevant map with a simple click. As Jason mentioned, we have made the process of documenting network knowledge easy as ever. For each context map that is displayed, NetBrain administrators can configure both a runbook and data view to be associated with a given context map.
If I am new to an organization and need to troubleshoot a routing issue, NetBrain power users have already defined a view with the relevant routing data present when I open the map. Notice that there is also an OSPF troubleshooting runbook opened as well, so I can collect relevant information quickly and efficiently. All the network views and context maps are customizable within NetBrain. Let’s quickly walk through how easy it is to create these with our latest version.
I’m going to edit the OSPF 140 area context. First, we’ll give it a context name, and a description if desired, then we can select which devices we’d like to be a part of this view. Here, I’m selecting a group of devices. Next, I can select which context maps I’d like to include, sitemaps, L2, L3 maps, or any existing map saved on your NetBrain server. Our last step is to be able to assign actions to particular context maps. Here we can see we have the OSPF action assigned to a particular context map, within this OSPF action, you can see that there’s both a data view and a runbook template assigned. We’ll be able to check for OSPF running status and have an OSPF data view present when we open this context map.
The next feature I’d like to review with everyone today is how to create your own layout template. To demonstrate this, I want to bring up a network diagram I threw together. Now, this is not the neatest network map, none of the built-in templates give this diagram justice.
So I’m going to create my own layout template within NetBrain. Let’s go ahead and take a look. To get started with this, I’m going to navigate to our start menu and select the map layout manager, from here, I’ll be able to create my own templates to use. So I’ll go ahead and go to our layout style, I’ll create a new layout style, and call this, “Data Center Example.” The first tab that appears is you get to pick and choose which style of layout you would like to use. Notice that each layout style has different layers on the map. For each layer, we can associate a specific tag to that layer, in this example, I’m going to associate the core distribution and access tags with layers one, two, and three – keep in mind this is 100% customizable though.
After you assign your tags, you then need to go ahead and assign tags to devices, so that NetBrain knows where to put the devices on the new layout. The last tab to review is a Layout Association tab. You can associate this newly created layout with the existing device groups or sites to easily organize your network maps. The last step here is, I want to be able to try this layout out, so I’ll go ahead and I’ll save this template, and now I will navigate back to that original messy diagram. I’ll right-click the map and select auto layout, now our data center example is present. I click the auto layout and I have a clean network diagram that is easy to understand based on the layout that I created. Pretty slick, right? We hope this saves everyone time and frustration creating a beautiful dynamic map.
This last section is going to review the enhancements we have made to our data view technology, which allows you to achieve a single pane of glass for all your network data through the dynamic map. Data views can help decode the network design by pulling information directly from the network devices to visualize on the map. Your organization may choose to use these data views to enhance a diagram with notes containing tribal knowledge, or even notes on known issues or bugs within a switch running a particular firmware.
Jason mentioned specific enhancements to NetBrain’s API integrations that I would like to showcase. NetBrain can pull data from third-party systems like a 24×7 monitoring tool to make data correlation even easier. We have also added the ability to add hyperlinks in your data views. So if you need more information from your 24×7 monitoring tool, simply click on that hyperlink directly from NetBrain. We have made these improvements to eliminate the need for engineers to jump around 30 different tools working with 30 different data islands. All the information that you need to efficiently manage a network can be accessed through the NetBrain interface. This example shows us viewing data from ServiceNow, and we’ve even added a hyperlink to quickly jump into the open incident that we saw on our dynamic map.
I hope you have enjoyed taking a look at some of the mapping enhancements we have in our latest version of NetBrain. Back to you, Jason.
Jason: Thanks Vin. We think the ability to access the information from any of your tools right from the map is going to be a game changer. Next up is something we’re really excited about, and that’s support for SDN environments. A few months ago we were at Cisco Live and we spoke with many of you about SDN, and we learned that Software-Defined Networking solutions are already becoming heavily adopted. We also learned that there’s a fair degree of concern and trepidation as many of your organizations are looking to embrace this wave because it’s very new. There’s this fear of the unknown, right? It’s because it requires a new way of thinking about the network, no longer box by box, but through a centralized SDN controller.
The two most popular SDN solutions in the market today are Cisco’s ACI, and VMware’s NSX. They represent two very different philosophies on SDN. Cisco’s answer – it does separate the control plane from the data plane, but the underlying fabric, that spine and leaf architecture, they’re hardware switches. So Cisco’s focus is really on the application policy and the provisioning of that policy through orchestration. NSX, on the other hand, employs a more, you know, “pure flavor of SDN” by truly virtualizing SDN functions like routing and firewalls in software, which runs on VMs.
So, no matter the SDN solution your organization may choose, there’s a set of common challenges for SDN adoption that we’re hearing about. First, there’s a skills gap since network teams are less familiar with a centralized control plane and application-centric approach to managing their networks. Second, both solutions offer some management capabilities through their SDN controller, but in both cases, that controller is really not meant as a standalone management solution. Its main function is policy orchestration. And nor does that controller offer a way to manage the hybrid network which extends really beyond the SDN fabric. And last, SDN brings a high degree of abstraction to network policies. And this makes the network more complex by definition. So, when everything is working well, this is one of the greatest advantages of SDN, but when something goes wrong, that abstraction makes troubleshooting extremely difficult. For example, the SDN fabric may have hundreds of applications running across it, but for a specific application, what is the underlying network responsible for delivering? And that can be very difficult to answer.
To introduce how NetBrain 7.1 helps demystify SDN for Network Operations teams, David Femino will run a live demo using Cisco ACI.
David: Thanks. As Jason mentioned, NetBrain 7.1 now has the capability to discover and map SDN environments. In this demo, I’m going to use Cisco ACI as an example of how this works. So to help us narrow the skills gap and really demystify SDN, we’ll first look at the NetBrain network pane, which separates three distinct views to help us manage our ACI environment quickly and easily. They are: the fabric POD view, which will show us physical connectivity between our infrastructure. The tenant view, which will show us overlay and underlay information. And then the application-centric view, which will allow us to really dive deeper into the application focus.
Each of these views create what we call context maps, and the context maps are pre-built maps that are generated by the system to provide us all of the information that we need. First let’s take a look at the fabric POD view, and when I click on my POD, I can see that there is a physical network context map that’s already created for me. So I’m going to open up this map, and I’m going to be able to see the physical connectivity between my spine, leaves, and the APIC controller.
Now, this is a NetBrain dynamic map, meaning that we can use features such as extending our neighbors. If I take a look at the leaf one, I’m able to extend other devices that are connected to it. In this example, I’m extending traditional devices such as firewalls and routers. I can also use other features such as NetBrain’s data views to overlay more rich information from these devices. So I’m going to use the maintenance information data view as an example to really find out a little bit more about my devices.
On the left-hand side, my traditional devices, this maintenance information is being collected via SNMP and CLI. Where on the right-hand side, the ACI infrastructure, we’re getting this information from the APIC controller directly. This allows us to view and manage our hybrid environment in a very consistent way.
Next is the Tenant view, which is really broken up into overlays and underlay maps, which help provide us a deeper context on the application itself. So the overlay map shows us a breakdown of the different VRFs, the VLANs associated with them, and the endpoint devices without showing any layer two connectivity. Now, we can also use data views here as well. In this example, I’m going to highlight the endpoint groups associated with the endpoints. So app one is an EPG prod app one.
The logical structure map also shows us the endpoint groups and the contracts that are between them, and also any external firewalls that are associated. So. to further enhance NetBrain and NetBrain’s use of Cisco ACI, let’s take a look to see how we can use NetBrain to help troubleshoot an issue on our network. So, to get started, imagine that we were told that there’s an issue with the web server and we only know the IP address, well, we can use NetBrain to map out the path of an end-to-end traffic flow across our hybrid infrastructure.
So, in this example, I’m using my gateway router, and then we have the IP of the web server. And we’re going to map on port 80 because we’re only interested in the web traffic. So by mapping this out, NetBrain was able visualize an end-to-end path starting from our traditional infrastructure, through our ACI environment, all the way through to the web server. Now, we can see here, other things across the NetBrain path that we may not have originally been aware of. So, for example, on the firewall, we can see that traffic was permitted on ACL 100, for port 80. And we can also see here from our load balancer that there is actually a virtual IP associated with that web server’s address.
So very quickly, first, we can see that we know all of the devices associated with this path. Let’s run the overall health monitor to see if our network is in fact healthy, and here we can see that all of our devices are in fact green and that we’re able to successfully reach those devices. So, what can we do next? Well, we can see that this virtual IP was translated to something different, so to 109253.10. So let’s go back to our network pane, and this time I’m going to look at the application-centric view, and I’m going to search for that IP address. What this is going to allow us to do is find the VRF, and more specifically, that web server. And we also have two context maps created for that IP address as well.
So let’s take a look at now what the underlay map. The underlay map is going to show us the underlying network devices and interfaces configured for this VRF. So here we can see back – it’s kind of a merge between our POD view and our other views. And if I run a data view, I can run the overall health monitor on this as well. And what I’m going to take a look at now is that we can see that, in fact our web server is up, but our app server is down. So this is all the endpoints that are dependent for this VRF, and we can see that the app is down. So, meanwhile, while we were able to reach our web server, there was nothing feeding into that web server. So, using NetBrain, it allowed us to quickly locate the VRF and analyze the health on our physical components to decode our app dependency mapping to the network.
The last thing that I really want to show is how we can use API integration with the APIC controller to achieve just-in-time automation. So I’m going to log into my APIC controller, and I have my leaf switch up. When a defined event occurs in the APIC, such as a port being shut down, the APIC will send out a notification via REST API from NetBrain.
NetBrain will listen to these event notifications and immediately trigger the generation of a map and run a sequence of customizable diagnostic steps in a predefined runbook. So in this case, NetBrain has already created this map from that port shutdown. And all of the results are going to be saved with the NetBrain map so that an engineer can look review at a later time. So when the engineer opens up the map, they’re going to see this runbook on the left-hand side that was already executed, so we can see result one, and I can view the results. And I can see the health of my spine and leaves, everything looks good.
The next component of my runbook was actually running the show interface brief command, and when I look at the results here, it’s going to show me that a note was drawn that ethernet 1/35 is down, that was the event in the APIC controller that triggered this runbook. So when I click on the actual show interface brief output, I can see that port 1/35 is admin down. This was able to show us very quickly what event occurred visually on the NetBrain map, and how we can use NetBrain to help identify that issue. Back to you, Jason.
Jason: Thanks David. As you saw, version 7.1 allows NetBrain to enrich its discovery and modeling engine through integration with the SDN controller via REST API. You saw how this data model is then applied to provide hybrid visibility, end-to-end pathing across the SDN fabric, and a host of other automation capabilities to help troubleshoot issues across the infrastructure. I want to point out that SDN has now offered us an add-on module which turns on this capability. Also, since we didn’t have any time today to show a demo for VMware as NSX solution, please contact us or email your NetBrain account manager if you’d like to learn more about that.
Next, I’d like to talk about upgrades to the change management module. NetBrain’s change module was meant to address four challenges across the change life cycle. First, when it comes to defining a change, it can be easy to fat finger and make a typo because you need to execute command after command. That’s why when it comes to implement the change, teams are more likely to think of it as plug and pray, than plug and play, where it just works, right? So they’re really just crossing their fingers and sort of hoping for the best. And in the end, really, there’s no easy way to validate the impact of the change or guarantee that it doesn’t really create a problem downstream. Again, that kind of speaks to that plug and pray mentality, right? So to show how NetBrain is addressing this change challenge, I’d like to introduce Shivani to conduct a demo featuring integration with ServiceNow, Shivani.
Shivani: Thank you Jason. Hi everyone. In this portion of the webinar, I’ll be showing you how NetBrain can help you streamline the process of pushing out changes across your live network environment, all the while auto-documenting all the work that is done. To start, we can go ahead and define a new network change task, I’m going to call this, “Remove unsecure SNMP string.” Oftentimes, from an overall security point of view, it is important to not only correctly plan the changes, but also ensure that the changes have been approved by management.
Here we can see NetBrain’s default change workflow. You can define the changes in this first step. In the execute phase, notice the grayed out execute button indicating that none of the changes can be pushed out to these devices unless they have been approved by management. NetBrain also gives you the ability to go ahead and take snapshots before and after pushing out those changes. These snapshots could then later be used to validate the changes themselves.
In this example, in the designing phase, NetBrain’s Qapp has already helped us identify the two devices that have unsecure private and public SNMP strings configured. We now only need to work on these two problematic devices. So let’s go ahead and adjust our device scope. You can load the commands to be pushed out from a set of predefined templates. One simple click allows for the commands to be loaded per device within the space, to be executed to the device itself after approval. At this point, we have completed the design and will need to request for change approval.
In version 7.1, NetBrain can now perform integration with your existing change approval process. A change can be requested and approved either directly inside NetBrain or via integrated third-party ticketing system, like ServiceNow, or BMC Remedy. For the integrated approval process, we’ve customized a NetBrain app to trigger ServiceNow to create a new ticket and fill in some fields automatically. Let’s quickly go ahead and add that Qapp. Here you can see how easy it is to modify NetBrain’s default change management workflow.
As you can see, NetBrain automatically generated the ticket for you. Now, let’s go into the ServiceNow UI, refresh the page, and here we are able to see the ticket that was automatically generated by NetBrain. The engineer can pass the NetBrain change ID along with the change URL to the network administrator.
Once the ticket is saved, the approval status will be updated to Requested in ServiceNow. As the network administrator, you can now decide to either approve or reject the change and the status will be updated in NetBrain. The benefit of integrated approval processes is that your existing ticketing system will have all the network change approval history in one place, and be able to track back when needed. Once the change is approved, we will get into the main change management workflow.
First, we take a snapshot of the network before the change with all the information you would like to benchmark to be used as change validation data point later. You can pick and choose between configuration files, route tables, ARP table, or any of the data or conflagrations of a device. As we can see, NetBrain is logging into each of these devices and collecting all the data that you would care for.
Now, we will move to the execution step. Here, NetBrain performs a hostname pre-check to make sure we log into the right devices, and you can choose different modes to push the commands. Commands could be executed across multiple devices simultaneously in batches, or individually per device. In this case, let’s go ahead and execute the changes. Here we can see how NetBrain’s logging into your devices and actually pushing out those changes across your live network environment.
After the execution, we take another snapshot of the same three data points that we would then use to validate the changes. So let’s pick our configuration file, route, and ARP tables, and have NetBrain retrieve the data for us for the specific devices. Once NetBrain has completed taking the snapshot, we can then move on to the comparison phase. So let’s go ahead and pick our timelines. Here we can see that the vulnerable SNMP strings have been removed. To visually verify that the change went according to plan, we can also go ahead and re-run the original Qapp.
And here you can see, none of the devices on the map contain private or public community strings. Once a change has been successfully delivered and verified, it can be archived within the system. Back to you, Jason.
Jason: Thanks Shivani. As you saw in the demo, it’s easy to define changes using a change template. How NetBrain integrates to your existing change review process, which is often done with a ticketing system like ServiceNow. How pushing a change can be done automatically across multiple devices, and easily rolled back if necessary. And perhaps most importantly, how NetBrain’s comparison engine in Qapps can be used to proactively validate a change. I like to think of this as really troubleshooting before there’s a problem, right? Within a change window.
Next up is one of our biggest topics, we talk about this everyday with customers who are struggling to meet SLAs, and introduce troubleshooting times, and that’s using dynamic map as a troubleshooting interface. So this effort to reduce mean time to repair, it’s actually the repair that’s the easy part, it’s what we call MTTI that takes the longest part. So what’s MTTI? Well, you can think of it two ways, right? It’s the mean time to identify the cause of the problem, or just as often it’s the mean time to innocence. Of course, the network is guilty until proven innocent, right? We all know this, but the burden still falls on the network team to prove that innocence.
So in NetBrain, we’re obsessed with making troubleshooting easier for teams. We start by looking at the life cycle of a typical incident, most of you probably already have a monitoring solution to help you detect potential issues, maybe something like solar winds, or SEV1. Usually, the first response comes from a help desk, or tier one. This team will check for common issues, but they usually lack the deep knowledge for the tougher problems, so escalation is often required. Tier two has that expertise, but many of their diagnostics that they still have to run are very manual. The other challenge is that the hand-off itself isn’t very effective. The work done at tier one isn’t really captured or shared with tier two.
So the vast majority of outages last over an hour, oftentimes exceeding SLAs, and causing huge costs impact. And the last question is, will this happen again? Can I learn from this outage to make the network more resilient in the future, less vulnerable to a similar outage happening again? To introduce how NetBrain is driving even more automation through the troubleshooting life cycle, I’d like to bring back Vin for a live demo.
Vin: Thanks Jason. To discuss some of the troubleshooting enhancements in our latest version, I’ll run through a real-world example to show how NetBrain easily integrate into a troubleshooting workflow. To get started with this example, we’ll looks in my incidents of ServiceNow, we have an incident open for slow application, and we’re given a source and destination. So I can use NetBrain to map out the network path. So I will start by navigating the NetBrain’s A to B path calculator, typing in the web server as my source, and the database server as my destination address. This path calculator allows us to find the path on layer two or layer three, and even refer to historical data.
Since this is a troubleshooting example, I’m going to use a live network data to be able to build my A to B path map. In this version, the majority of network tasks conducted from your dynamic map are recorded by NetBrain’s runbook. For example, if I do a simple ping check by right-clicking a device on the map, a runbook is automatically opened with this step. These runbook’s are automatically capturing my troubleshooting workflow, and all of the data collected is saved in the runbook.
Our latest version of NetBrain allows users to use a dynamic map of a problem area as a collaboration platform. All of the data and troubleshooting steps are saved, so no duplication of efforts occur if it gets handed off to another team. We have been using runbook automation to speed up the troubleshooting process. I just ran an overall health monitor to review key performance metrics, and I’m reviewing CLI data collected from all the network devices along this A to B path.
Let’s say that I’m a tier one engineer doing some initial triage, if I get stuck and need to escalate the problem, I can do it directly from NetBrain. In our latest release, users can tag other engineers or call out device information within a runbook. In this example, I may need help from another engineer, so I can tag them in the runbook. They would get a notification within NetBrain which provides a link to the dynamic map and runbook with all the collected data.
Now, nothing is lost in escalation. All the steps our tier one engineer took to resolve the issue is documented within the runbook with the supporting data readily available. Also included in this release is a new automation function known as a Gapp. In layman’s terms, a Gapp connects two or more Qapps together in a logical manner, so the results of the first Qapp can be used to filter devices and scope for the second Qapp.
Let’s take a look at an example. The first part of the Gapp checks for interface errors on all the interfaces present on the map. If it finds errors, it launches another check to look for common causes only on the interfaces that contain errors. Keep in mind, the building blocks of this feature are NetBrain Qapps, meaning the automation checks are 100% customizable. Users can create their own automation procedures to be included inside of a Gapp
And of course, with NetBrain, we can take these automation capabilities a step further, and have NetBrain triggered into action by a third-party system without human intervention. Let’s navigate to that original troubleshooting example, but this time we’re working with a fully integrated version in NetBrain. This incident being open in ServiceNow triggers NetBrain to map out the problem area, run a customizable runbook, and send a URL back to our Incident Management System. We call this just-in-time automation. NetBrain collects data at the time an incident or event occurs in your network. Our tier one engineer doesn’t need to spend the time collecting data or running checks to find the root cause of the slowness. Instead, engineers can simply click on the map URL to begin analyzing the data NetBrain collected automatically. We believe this will drastically speed up the troubleshooting process at any organization.
And it looks like we may have found a configuration issue where the duplex settings between two switches are mismatched. Now after the fix, how do we prevent the same problem from occurring again in our environment? The latest version of NetBrain has introduced an automation scheduler where we can schedule Qapps and Gapps to run on a regular basis. This scheduler allows users of NetBrain to continually monitor for underlying network problems. NetBrain users can set up email notifications if a check produces a warning or error alert, and also define the scope of devices to run against. It could be an existing device, a site, a group, or even an A to B path. You then configure a Qapp or Gapp to run and define a frequency.
A 24×7 monitoring tool may provide alerts for symptoms of a problem, like high latency, or broken response time threshold. This Qapp scheduler allows for targeted monitoring of specific factors to prevent a recurrence of problems in your environment. Back to you, Jason.
Jason: Thanks Vin. So, in the demo, you saw how tier one was able to automatically document their troubleshooting process with the new runbook. You saw how tier two could review all the previous findings in the shared map, and then augment the runbook with his or her own codified knowledge by adding their own automation capabilities. Through NetBrain’s enhanced API integration, you saw how much of the process could be automated just in time, at the moment of the event detection. And finally, Vin showed the new automation scheduler which allows you to schedule Qapps to run, which monitor the network for underlying problems proactively.
I know we’ve covered a lot already, we’ll conclude with a set of other enhancements that we didn’t have time for a live demo. For those of you who missed NetBrain’s one IP table from previous versions, it’s back in NetBrain 7.1 to provide a single resource of all IP Mac and ARP data in one place. You can now Telnet or SSH through a party console directly from the map just by right-clicking on the device.
We’ve introduced what’s called variable mapping. This makes it easier to create Qapps which work across multiple vendor devices, and leverage more data sources such as CLI, SNMP, or API, for writing a Qapp. So for all of you power users out there who are customizing your automation with NetBrain, this will be a very welcome addition for you, so look for more information about variable mapping.
For NetBrain administrators, we’ve created a service monitor where you can see the health of NetBrain servers, along with other details about your NetBrain management. And there’s still more, including expanded Meraki support via API, auto update for hardware device drivers, new architecture and performance, and the ability to deploy NetBrain in the cloud.
I know we covered a lot today. Naturally, you probably have more questions and more things to dive into, so if you’d like to learn more, I highly encourage you to register for our free online training. We’ve updated our course catalog for NetBrain 7.1 and included many new topics in the training materials as well, including, SDN management. For more information visit netbraintech.com/resources/livetraining.
For customers with an active maintenance agreement, you can now request your free upgrade, visit info.netbraintech.com/upgrades. Wanted to thank you again for joining the call today, we’ll be here still to answer your questions, so please keep those coming in the next several minutes through the chat window. And in many cases, we’ll answer those questions aloud over the phone line for the benefit of everybody else who’s listening in. So please stick around to listen in or to ask your questions. Otherwise, be sure to have a great day, and thanks again so much for joining. Bye-bye.