by Amena: Good afternoon and welcome to NetBrain’s webcast, “Preparing for Successful Hardware Refresh with Network Automation.” My name is Amena Siddiqi, and I’m the Senior Product Marketing Manager here at NetBrain. Joining me today is Joel Byam, one of our senior engineers.Before we get started, I’d like to go over a few logistics. We’d love to keep the presentation interactive, so please feel free to engage with us via the Q&A panel at any time. We’ll be checking the Q&A during your presentation and responding to questions as we go. We’ll also save some time at the end of the webcast to answer any remaining questions over the phone. So with that, let’s dive in.
So it’s almost the end of the year and a lot of organizations are currently involved in or preparing for a hardware upgrade. This is a fairly common use of end-of-year budget. Networked devices may need to be swapped out for a variety of reasons. For example, an upgrade may be needed to support new deployments with technologies such as VoiP, SDN, FabricPath, QoS and so on. Other common reasons include having to replace devices that have been designated end-of-life by the vendor, business best practices and place limits on hardware change and age, the capacity needs of new applications may require more port density on devices, or new business continuity requirements may come into play based on more stringent security frameworks. All of these reasons and more may be driving the need for a network refresh.
Now, traditionally, network teams are budgeted for hardware refreshes, about every three to five years or so, for edge refreshes at the access layer, or wireless access points. And it’ll be 10 years or so for the much more expensive and risky core refreshes of the data center. However, the piece of technology advancements and the various needs of the business have meant the core and other refreshers are happening in faster timelines and in a much more ad hoc fashion now.
If you’re preparing for an upgrade, before you begin, you’ll want to make sure you take a careful look at the existing infrastructure and balance the need to make the best use of already-paid-for hardware, with new requirements for security, capacity and resilience. And you want to do all this without disrupting business and throwing money out the window. Refreshers are expensive, not just from the point of view of hardware purchases, they’re also daunting in terms of head count and staff augmentation costs. Typical organizations will often refresh hardware in stages during low traffic periods, for example, on nights and weekends, and will frequently hire outside manpower for the job.
A network refresh can introduce a significant amount of risk into your network infrastructure. As with all changes, there is a chance for human error to creep in. Tasks that are highly repetitive and manual are especially prone to this and these projects are fraught with plug and pray anxiety. We’ll show later in our presentation how automation with NetBrain can alleviate much of this.
To give an example of how a small detail can cause massive disruption, you may recall about a month ago, we saw at nationwide internet outages because of a misconfiguration at Level Three, an internet backbone company and Enterprise ISP. The misconfiguration that caused all the havoc which related to a routing leak issue that created a ripple effect of problems all across the country for internet providers like Comcast, Verizon, and Cox. These outages really reinforce just how precarious connectivity really is, and even how mundane tasks can introduce instability into what has become a vital service. And this was just a configuration error. Imagine how risky it is rip out entire racks of equipment.
But a structured approach can help mitigate much of the risk, and a network refresh will typically take place in five phases, each with its own set of challenges. To ensure a successful transition, you want to begin with a careful analysis of the existing infrastructure. This will help you determine the equipment configurations that are necessary for the new network to fully support both the current and future needs of your organization. A testing and validation step should bookend the implementation both before and after. The new design will have to be validated in a staging environment prior to implementation. And after deployment, it will need to be tested again, undocumented.
Implementation itself, can be a tedious series of small tasks as individual configuration needs to be pushed out one by one. During this phase, fail-over scenarios will also need to be tested and documented, and sent for approval to its Change Advisory Board. Finally, even after the new network is up and running, that does not mean that all hurdles have been cleared. Engineers usually just hold their breath on Monday morning after our network refresh. Should anything not work as expected, a rapid rollback maybe necessary to ensure an interrupted service.
With a new design comes with unfamiliar network. For instance, just switching vendors and having to move over from a encrypt network to ISIS or SPI, or vice-a-versa, the lack of internal expertise and familiarity with the new routing protocols and design can make troubleshooting and other day-to-day tasks slower and much less reliable. Now, good documentation practices can help alleviate much of this and we’ll see further on how NetBrain can help you digitize best practices and expert knowledge into executable runbooks for knowledge sharing within the team.
I’d love to talk a little bit about the visibility challenge, when it comes to growing and increasing complexity of our networks and our ability to understand the visualize those networks. Eighty percent of network documentation is reported as out-of-date by the users that we surveyed in early 2017. That’s a very large number. Only 3% of those same users reported CLI as far too limiting because you have to work with one device at a time. It’s very manual and very slow. And at the same time, they also reported a challenge with far too much data because it’s difficult to find contextualized data when it’s spread across many, many tools. Finally, there was also a challenge with knowledge sharing. A lot of tribal knowledge is locked into the mines of the subject matter experts or into their notebooks or personal notes. That really limits the ability of teams to share best practices.
Let’s begin with the phase one. The challenges in phase one are the typical challenges of visibility: Missing or limited documentation of existing network infrastructure, the limited understanding of application requirements and traffic flows, and the limited understanding of the existing design, security, routing, layer, tube and so on. NetBrain really shines in this area because it can generate automated documentation and network diagrams to shed light on all of these areas. With that, I’m going to pass it over to Joel to show you how NetBrain helps.
Joel: Thanks, Amena, for setting up our foundation. Now for this portion of the webinar, we’ll focus on phase one, and that’s going to be just understanding your existing infrastructure. Now, one of the challenges of any network refresh projects or hardware refresh project, is to have an in-depth understanding of the existing infrastructure. Many of your expenses may come from just getting a baseline of your network. If you’re doing this task with an in-house team or a third party, you’re going to end up spending a lot of time and effort for just doing the initial evaluation.
Now with NetBrain, we are able to discover your entire network by using just some basic information. This will involve your SNMP read-only community strengths, and on top of that, your SSH or Telnet logins for CLI access. Now instead of combing through tons of devices and tons of documentation, we can toss them into a single seat IP and NetBrain can do a neighbor walk through of your environment to discover your devices.
Now, from here, NetBrain going to go ahead and initially contact that first device, pull up some basic information like configuration files, data tables, routing tables, ARP Mac, CDP information and so on, and then from there, be able to look at additional details to be able to support third party applications as well. Now, when NetBrain’s going through and collecting information, we’ll be able to build that layer two and layer three topology so we can see some details around your network. Now, from here, you can be able to easily discover your network, create dynamic maps, get full inventory reports, and you could ultimately eliminate the cycle of scrambling to get accurate documentation just for it to be out of date in a matter of weeks and in some cases, even days.
Now in this example, we’re going to walk through how we can use NetBrain to upgrade the hardware for one of our branch offices and how it can make a useful platform to make it much easier. Now, moving over to the actual environment that we’ll be working with, we are able to do proactive and reactive approaches to a hardware refresh. And instead of having to go through the manual process, we can reduce time to collect data and be able to increase any team’s efficiency during medium to large scale projects.
Now to set up some context, what we’re doing is we’re setting up our network within two different sections. First, our production network, that’s going to hold our actual devices, and our staging area that’s going to hold the devices we’re going to be upgrading them to. Now, the staging area, everything’s already connected and we’ll jump into that, but first, let’s go ahead and collect some information from our initial production network so we can look at some details. Now to do this, I’ll organize everything using my overview map so I can get that 10,000-foot view of the network. Here we can see I have my HQ, my HQ routers, and on top of that, I have my Burlington office and my branch office. This is the branch office we’re going to be making those upgrades to. You’ll see we get some basic information here, the number of devices, and even customize it further to get more information.
Now to jump in, we’ll see that we have a full topology that’s available. From this topology, we’ll be able to see some details around our network. We’ll be able to see layer two and layer three interfaces. As we zoom in, we can see the information that’s going to be utilized. Now, as we go through this process, we’re going to start pulling data, looking at basic level two information, and then go further using what we call Runbooks to visualize information and get some more details in a standard work form.
Now, from the information that we have, we can start looking at layer two information and start pulling details from the devices using live data. Traditionally, you’d log into these devices with CLI Windows, maybe PUDDY, maybe secure CRT, what have you, to be able to pull up information and go through it step by step, device by device. In this case, we can use NetBrain’s Instant Qapps to be able to pull that information. So let’s say I want to look at interface information, I can simply type in “show interface.” We’ll see that we have multiple entries here, starting from interface status, interface switch port, showing the number of devices that it matches as well, based on the actual CLI commands that we’re using. So NetBrain not only gives you a filter of the search options, but also filters it based on the device types that we have. Now, being that NetBrain is powered by a parser library, we’ll have tons of parsers for different vendors that we have that NetBrain will be able to filter between.
Now, the way our parser library works, just to go into a little bit of background before we jump into pulling up the information is you’ll see that we have sample outputs for different devices and different device types. In this case, we’re looking at IoS devices. So you see that standard show interface output, seeing information from each one of these devices where we have highlighted data and each one of these pieces of highlighted data is associated with the variable. From here, we can take these variables and simply drag and drop them on the map. So if I want to look at my basic configuration of my interfaces, I can look at bandwidth data, I can look at maybe delays and let’s go and look for another piece of information like maybe MTUs.
Now, from here we can start dragging and dropping information. Once we collect the data, NetBrain is going to pull up those details, overlay it on the map, and then we can see the information. So generally looking at the eight devices on the map, we’d have to issue eight commands and then sift through each one of these pieces of data to be able to accurately get this information.
Now NetBrain can be able to deliver this data quickly, easily and effectively without us having to go through a lot of effort, manually going through each step. Now, this is just the first way we can collect information, we can be able to even save this data as well. So, the great things about these Instant Qapps is that it’s not just one-time data retrieval. We can actually reuse these. We can set thresholds, define alerts as well. Let’s say for instance, I want to set my bandwidth within a certain range or a greater or less than a certain value, NetBrain will be able to give me a hot spot of that information. If I want to continuously monitor to see if anything changes, I can be able to use this, and this can be done for interface counters or anything that changes within the actual outputs in general.
So now we have the information here, we can see hours, minutes and seconds. We can adjust this as needed, and we can save this Qapp. So if I ever wanted to reuse this Qapp, use it for another task, we can be able to save this and have that information. So let’s go ahead and actually save this right now. We’ll call this basic interface configuration.
Now, from this data that we have, we can save this Qapp and we can reuse this. So now instead of us having to be stuck with a single Qapp with a single map, we can share this amongst the team and essentially expand our tool belt to give us more functionality.
Now, as Amena was saying before, a lot of the heavy lifting and a lot of the work that goes through collecting this information is going to be done individually or maybe by teams, but nonetheless, it’s going to all be done by hand. So here, we’re going to use are Runbooks to capture all that data in a workflow.
So using my Runbook, we can see that we have multiple steps along the way. Each one of these Runbooks essentially contains Qapps, CLI commands, looking at built-in tools and customized tools that we can use to be able to collect this information. So for instance, if you wanted to do a quick compliance check, we can check our password encryption, check port security status, or even ACL Rules and SNMP. In this case, we’re going to collect a batch of information and we’re going to be looking at our hardware refresh phase. So this will be able to encapsulate that first phase, collecting the batch of data that we’ll need. So the first thing we’ll want to do is collect a baseline, get a device benchmark of our environment. So here’s what we have as a snapshot and NetBrain is going to collect config files, routing tables, ARP, Mac, CVP and so on. And you’ll see the data that’s collected here as well. We can apply this to the map and start going through each one of these steps.
Now for the first step, we’ll do that initial benchmark. You’ll see here that we can select data, be able to put tons of information within the map, and you could see from the plethora of information we have, we’re really not missing a ton of it. Now, let’s say for instance, we wanted to put in some customized CLI commands. We can add in some show commands here, some Getter display commands, so that way we can really round out our needs. Now we can go ahead and start off collecting our data, having NetBrain take care of all that heavy-lifting for us, so we can visualize our outputs.
All right, perfect. So we’re getting all the information we need, so we can go ahead and jump to our next phase. Excellent. So now that we have our information completed, we can always come back and recall those results and see the information. So from general configuration files, general data tables from route ARP, Mac and so on, CLI commands, and a live blog. So now we have all the information we’ll need.
So the next step on the list is collecting a batch of CLI data. Now we can go ahead and put a list of commands and have NetBrain login and issue all of these commands to these devices. So now jumping through each of these. Some of these commands may work on some devices, some may not work on others, solely because of the different device type, different vendors and so on, in which NetBrain will alert you which ones aren’t working, but in this case, we can be able to see the results, see all the details around those, see our showIP protocols, get all of the results from those devices just to make it much easier for us to see the details.
Now, once we have this information, we can just continue on the road. We’ll go ahead and take a look at our OSPF configuration. We can already zoom in and see that NetBrain is going to be able to show us that OSPF configuration as well, but what we’ll do in this case is be able to look at that in more detail from using our Qapp.
Now, here we can be able to design OSPF at a glance, be able to see the results and see details directly on the map. So you could see that NetBrain is going to change the map based on the information that’s collected. So now we can see our OSPF area, we can see our cost, and now we can actually have NetBrain highlight the information based on the interfaces on what area they’re associated with, whether their backbone, whether their stub areas – being able to also show us the roles of the devices as we go through. All right, so we can see we have some ASPRs and some AVRs as well. On top of that, we’ll get full configurations. So now we can see our OSPF config for this specific device, be able to see the networks that we have assigned and even be able to see additional information.
Collecting VLAN Trunk information, that this is going to be for layer two data as well. So previously we looked at are basically layer two config, now NetBrain will be able to highlight our actual trunk ports for the VLANs.
All right, great. So we see we actually have one trunk port here, have this link that’s been highlighted, showing us the actual interface which port mode trunk on this interface. Now, one thing I also want to point out is that our Qapps can do more than just highlight information on the map, but what we can also do is be able to create CSV files. Our CSV files can be able to collect information live from the devices and then put that in the chart, so now you can export that data and be able to hand it off to your team in-house or maybe even to a third party if you’re utilizing that for some of your changes.
Now, we’re going to go ahead and take a look at our SNMP group version. Remember, we want it to go ahead and check the SNMP settings for devices because we’re going to be upgrading our devices to not only support SNMP V3, but also to be able to support other technologies as they come out to kind of future-proof ourselves.
So now it can be able to highlight the information, be able to the details on the map, and we can easily see all of our devices with SNMP V2C that’s enabled. So now we have our results being shown on the map, again, we can get the devices that are outlined and we can go ahead and take that last step here where we check our basic interface settings.
So now as NetBrain is collecting the data, we’ll be able to highlight those results and then be able to even export this as well. All right. We see we have that CSV file with MTUs, delays, duplex settings, bandwidth as well, queue strategy and reliability. So we’re really getting a lot of data from these devices right off the bat.
So now that we’re finished collecting data from our Runbook, we can see that we’ve gone through all the steps, all the information is embedded in the Qapp and we can even see some of the data that’s here. So from our six activities, we can see it in our activity log, we can have the information and easily export those results as needed.
Now, before I go ahead and wrap things up, let’s collect some additional details. There are two more things that I want to check before I really package this up, send this out to our design team as well. The first thing is going to be able to check our paths, right, so what’s really important is not just the devices and their configurations, but how those configurations hold up when we send traffic from end-to-end.
So in this case, I’ll go ahead and draw a path from our SJC core to our SCL core. This is my path tool. I can visualize that information and then be able to even choose the data set analysis as well. So from layer three paths to layer two paths to be able to select which protocols I want to test and even be able to look at the data sources. So let’s going to go ahead and start here. So remember that SJC core…and we’ll use that SCL core.
So now that we have these in place, we’ll draw that path out and NetBrain is going to calculate the path from end to end, showing us the bi-directional flow of traffic. So now that we have this information outlined, NetBrain can give us some details around this as well.
Now, from the data that we have available, we can see the results that we’re getting from these devices are looking at ACLs, mapping, checking destination, input VRFs, VPN peers, all the way down to policy-based routes and actually looking at the round table. So we do a comprehensive analysis of the dataset from either live data or even cached data so you can get a historical view of the network.
Now that we have this information saved, let’s go ahead and actually save this data as a path. So I’ll call this my primary application, and save that. So that we can always be able to reuse this in the data model and be able to see the information. Now you can see other paths that I’ve saved in the past, where we can actually be able to drag and drop that information and show that data.
Now, the last thing on the list is getting that final report of our information. We can use NetBrain’s inventory report to visualize the data. So now instead of you having to create these manual living documents of Excel reports, we can be able to have NetBrain take care of that on its own. So here we can get general device reports from all of the devices in our network – showing us models, version, vendors, and serial numbers. We could see interface reports to be able to see how many interfaces are actually being utilized. And with our summary report, we could really see the total number of modules, total number of interfaces, total numbers that are up, that that are down, that are connected. We can really customize and get some in-depth detail of what’s being used so that way we can prevent any over under engineering of any future projects that may be happening.
Now in this case, what we’ve done is we’ve also created a customized site for the Burlington location, so now we have a report where we’re going to see all of our devices within our Burlington map, total of eight devices. We can see the software versions, serial numbers and even export those results into an Excel file or CSV file. Now when we’re ready, we can just go ahead and export that and get a final result. You can see NetBrain is exporting the results. So now that we have these results ready, NetBrain will be able to show us that information.
Now we have our final report showing us our host name, management IP, device type, management interface, all the information that we wanted to see, all organized for us or created so we can be able to have this information to, again, handoff eternally or share with other teams.
Well, that pretty much covers what we have for our first part of the demo, essentially understanding what we have in our environment, taking a look at our interfaces, taking a look at our connections for layers two and layer three, automating some processes using our CLI commands or our Instant Qapp, and really getting into in-depth analysis of our existing environment.
With that being said, I’ll go ahead and pass things off to Amena to continue on with the rest of the phases.
Amena: Thanks, Joel, for the extremely informative demo. As you can see from the demo, NetBrain helps eliminate a lot of the manual work associated with creating network documentation. NetBrain can discover the network instantly, both the topology and the design and create documents dynamically, exporting them to network diagrams to Microsoft Vizio and exporting asset reports to Microsoft Excel. Finally, NetBrain also helps keep these documents up-to-date by performing a recurring benchmark that can be scheduled on a regular basis. This eliminates a lot of that manual labor that network engineers have to go through entering show commands into the CLI just to collect all this information and populate it into Vizio diagrams.
So let’s move on to phase two. In phase two, the challenges have to do with gathering the correct requirement to the future technology and capacity needs to business. We want to think about the long term and design a network infrastructure that will meet the needs of the organization for years to come.
Moving onto phase three. In phase three, the challenges have to do a documenting and validating the new network design. Engineers have a limited ability to test key traffic flows and fail-over scenarios without deploying a new design in the staging environment or a virtual environment created with simulation tools. I’d like to pass it over now to Todd Bristol, one of our customers who uses NetBrain to validate network design using one of these simulation tools. And Todd’s on the line here with us today. So over to you, Todd.
Todd: Thanks, Amena. So let’s go ahead and talk about the use case where we use NetBrain to validate our network design. We were handed a requirement to design and implement a solution that provided redundant connectivity into AWS from our data center. Some of the immediate design challenges we faced here were route poisoning, inbound route filtering, inbound route redistribution, outbound route filtering, outbound route redistribution, inbound traffic steering and outbound traffic steering.
Production doesn’t have to be the place where we begin to understand and master the complexity associated with new technology. So we decided the best thing to do would be to create a sandbox environment which didn’t really exist, where we could test some of the complexities associated with this new design, not to mention simulating layer three AWS connectivity back to our data center over two 10 gig connections. As we were building our lab environment, we pointed our NetBrain instance toward it and discovered that we now had the ability to study and document the art of an outage and become intimate with the complexity of new technology away from production.
For example, I could study the differences between my BGP, OSPF and rip tables as I fail-over from one path to another on every router across a layer three path. I could also get graphical representations of my traffic flows, before and after changes. NetBrain not only helped us validate our network design, but allow us to become intimate with the complexity associated with new technology and also allowed us to study up close the art of an outage.
Okay Amena, I’ll hand it back over to you now.
Amena: Thanks, Todd, for joining us today on our webinar and talking to us about how you use NetBrain in stimulated environment to review the design and evaluate fail-over scenarios. As you can see, this translates very well to network refresh project quite similar design review and evaluation needs to take place.
Now, I’d like to talk about phase four: implementation and testing. In this space, the challenges have to do with extremely manual process of pushing out configuration changes one by one to each device, which is extremely time consuming and prone to error. In addition, it’s difficult to document and track the changes that have been made in this manner and it’s also difficult to roll them back if necessary once they’ve been pushed. So I’d like to invite Joel back for another demo to show us how NetBrain can automate the change management process and enable much more streamlined implementation and testing during a network update project.
Joel: All right. Thanks, Amena. Now that we’ve evaluated our data from the previous section, we can now turn to our staging area, where we’ve already connected our devices and configure their base access config. So NetBrain issue commands and do a basic discovery. We can implement the changes that will allow us to port over the configurations from our previous devices over to the new hardware.
Let’s go ahead and jump into our map so we can see that information. So I just went ahead and reused the overview map to see this information just so we can have some consistency across the board. Now jumping into the staging area, we have that full dynamic map of information, so these are our new devices connected just how we have them before and now we can see our basic connections for these devices.
Now, from the data that we’ve collected so far, we’ll be able to use this to port over those changes to the new devices. So now for the sake of the demonstration, I’ll go ahead and put a change that won’t impact the devices directly. Again, this is a demonstration, so we just want to illustrate this information. Now to do this, I’ll use my network change tool. Now that we have all the information evaluated, we’ve been giving our marching orders on the steps to take and what changes to push. So, here we can go ahead and use our hardware upgrade. Now, a hardware upgrade gives us a workflow of steps to take, starting from our benchmark, going to our baseline device configurations, our customized configs, and our benchmark two, where we’ll do a comparison all the way at the end to, in a sense, double verify that we have made the changes that we’ve defined.
Now, let’s go ahead and I’ll walk through this now. So starting from my benchmark, I’ll take that snapshot. Now, one thing to notice is that again, you’re getting the same information from the previous benchmark, except right now I want to focus on the configuration file. Keep in mind, we can add or remove information from this, if needed. So I have to get rid of the CLI command. We just go ahead and get rid of that and I add this to the standard set. So now that we have this information, let’s go ahead and start that. Again, you’ll notice that NetBrain is collecting a data folder, you know, from the actual year, the actual month and the actual day. It’s showing us the time of day as well, so that we will have the timestamp to refer back to.
All right, so now that we have this, we can go ahead and do that baseline device config. So now here’s where we’re going to go ahead and make that change where I’m going to push those SNMP strings. Now, let’s go ahead and start this. again. You’ll be using this for VTI information, SNMP information, checking for basic ACLs. Anything that’s going to be consistent across the devices, we want to go ahead and add it to this stage here. So now I have my SNMP strings, I have the information here, but keep in mind, if we ever need to roll back any information, we can actually toss information to the rollback section as well.
So I’ll just go ahead and put ‘nos’ in front of these. That way we can undo that SNMP string, right? So we have our change, we have a rollback. I’ll go ahead and append it to the devices. You’ll notice that we added all of the strings here, and keep in mind, we can even add additional steps if we needed to. Same thing with the rollback as well, I’ll append these, too, just so that way I can go back to it if I need to.
So now that I have my changes defined. I know exactly what I’m going to change. We can still go ahead and start that execution of the changes. You’ll notice that we have different options either executing all of our devices sequentially, simultaneously or execute devices one at a time. In this case, we can issue each command one at a time and see the outputs from that. But for the sake of expediency, which is really what we want to do here, let’s go ahead and execute all of these simultaneously.
Now that I can execute the results, we can jump to each device to see NetBrain prepare the configs as a safe to the advice. We can actually CLI into that to issue the commands. You can see the final results. Now, this is exactly what it would look like if we were to issue commands in mass. So now you’ll see that some of them take, some of them don’t. So this may not be the exact configuration for the actual devices, but that’s okay because we know some of them take some don’t and it won’t be able to change or make a big impact if they don’t take.
So now that we have the results here, we can go on over to the next step, where we can put in those customized configs, add them as we need to, maybe interface information, maybe specific routes that may be sitting on a certain route or anything like that. And then we can go to our benchmark two. Now here’s where to take that second snapshot of the network, again, only focusing on the config files so we can see those results and changes.
All right, perfect. So we have our timestamps here. We can go to our comparison and see those final results. So now we have our timestamps, both of them at 2:17 and 2:20, 14:17 and 14:20 respectively. We can check the available data that’s shared between the two of them. So we can look at our configuration file, do a quick comparison and now NetBrain can show us the changes, the differences that happen between the devices. Looking at this first core device, jump to the next, see that first configuration changes so that the bites are different, and then now we can see the two additional strings that were added, a rewrite and a read-only string. So now that we have this, we can verify that we have the information in the map, we see the details that are available, and we can go ahead and have this shared and sent up to the team for final documentation as well.
So now that we verify that the changes were made and they were pushed to the devices, we can now double check as well all of our previous information that we tested. So one of those would be the path. We want to make sure that our network is flowing in the same. Again, this is easy hardware upgrade, not a complete deconstruction, collapse or expanding of a network. So we’ll use our path tool again and we’ll check that SJC core and the SCL core.
All right, so now we’re going to go ahead and add in our SCL core. Perfect. We’re going to run that path again. So on NetBrain is able to recalculate that information and you can see that our path was the same from the previous example, right? So now we have these details available. We’d see the information that’s there and be able to share the data back and forth as needed.
So now that we’ve validated our actual routing tables, we know everything is the same, let’s go ahead and check to make sure those changes have been taking and we can reevaluate everything that’s taken place. So one thing we can do is either, A, use our previous Runbook, or we can actually leverage our benchmark to do something really cool here. Now, let’s go ahead and jump into those.
Now, within our benchmarks, we can actually schedule those tasks that I mentioned. So you’ll notice that I took benchmarks previously during the course of the actual demonstration by doing it live on the devices, but here’s where we can have NetBrain take benchmarks periodically. So we could do this hourly, daily, or weekly to make sure we keep an up-to-date record of our network. On top of that, we can define a device scope, retrieve live data so you could see the wealth of information we’ll be collecting. Again, CLI data that can be customized so we could even add in templates that are pre-built and even customize those templates as well, and then add the additional operations. Now here’s where we can really show how we can automate those Runbooks, automate those CLI commands even further.
Now, from our Qapp based operations, we can load Qapps into the benchmark. So now we can see all of the tools that we’ll be using to check the information that’s been changed so you can see these results, device age, port security, VLAN information and so on, have this data embedded into NetBrain so every time it runs this benchmark, it will be able to revisit that data. So that means once we collect the information, they’ll be able to show up in data views within the map.
So here we can see the different information pieces that we have. We could see our interface errors, monitor variables periodically look at our health monitor that was run. So we triggered NetBrain to run a health monitor in the course of this. We can zoom in to be able to see CPU and memory utilization, other information around the devices, VLAN information and so on. So we can be able to see all of these details around the devices to see routing protocols, all the data that we have configured within the environment. So now that we have this information verified and everything has been validated, let’s go ahead and pack up our devices and then send them off to be implemented. Let’s go ahead and pass things back over to Amena.
Amena: Thanks, Joel. As you can see from Joel’s demo, NetBrain helps alleviate a lot of the manual labor associated with change management processes. You can use NetBrain to define changes using configuration templates and then push out those templates to all devices at the same time. The changes can be executed automatically, but it can also be rolled back if necessary. They can be visualized on dynamic maps and Executable Runbooks can be used to validate the changes against design and compliance requirements.
And with that, we’re onto phase five, addressing operational challenges. In phase five, the challenges have to do with the limited knowledge that the engineers are now going to have of the newly deployed network. That’s going to make troubleshooting another day to day tasks much more challenging. In addition, as further changes are rolled out, the network documentation continues to become more and more obsolete. So I’ll invite Joel back for another demo to show us how NetBrain can help during this phase with the network upgrade process.
Joel: Thank you, Amena. Now, the goal live date can be very nerve wracking day for many engineers, so many possible variables can affect the performance of a network. Now, so far, we’ve been able to go through extensive validation of our designs to really get an understanding of the changes that have been made within the network. But during anytime we put anything online, there’s always a risk of issues happening. So we can use NetBrain to actively check what’s happening in our environment.
Now, the first thing we can do is use our Runbooks to visualize this data. Here you can see that our Runbooks range from just general compliance to even security and just general troubleshooting. So, we can be able to check for information within our network. For instance, we can use our overall health monitor to see details within the environment, just giving us a solid understanding of what we have. So now when the operations teams can be able to use this to see the performance of a network, you get a solid understanding of what’s there. You can even be able to share that information with the team.
Now with the details that are being collected, again, everything is being saved in that data view. So you can always bring that information up and down and turn it off if needed. Another thing we can do to be able to visualize data is being able to just check for any of the path analysis that we’ve done. We always want to make sure we’re staying on top of the way our traffic is flowing in the network and seeing if there are any deviations. Now, instead of constantly running them from the top of this path bar, we can actually use some pre-defined paths that we’ve created here. Simply running any one of these paths from the live network, we can actually drag and drop this information directly to the map to overlay these details.
Now, NetBrain is going to show me the information of my ingress and egress paths, showing us how traffic’s flowing within the network so we can continuously stay on top of any existing path flows that are happening. Now, of course, while this is all running, we can be able to visualize data in multiple formats. So aside from being able to view it from the map, we can leverage dashboards to see these details. Now, we can see we have routing protocols specific information, health specific information, and even topology specific information. But so far, what I’ve done is I’ve created an overall health monitor to see information from the dashboard perspective.
Now, from this site status monitor, we’ll be able to see multiple perspectives of the devices. From one side, we can see a map, from another side, we can be able to see device details, so now we can be able to get the best of both worlds from being able to see all the information aggregated into a single space. Now, from the new devices that have been deployed, we can see that our interface link error chart is completely clear. We have zero errors that are populating, so that’s great. Our interface traffic charter showing us some peaks and valleys, interface utilization is giving us some information and we can quickly jump through any one of these configurations to see details around our devices.
We have data tables showing us the total number of neighbors that are up or down and the actual routing protocols and number of routes that are learned. Mac tables are available as well, along with routing tables, too. So we can really get some information out of our devices. This’ll generally take us quite a bit of time to be able to monitor, compile and then be able to document as well. Now, since we know that our network is working as expected, we can be able to round everything out with a final word document. So now we can actually export this information, get a final template, and then share this data. You’ll see the various widgets that we can export and be able to give us some really detailed information about our network.
So now as NetBrain is exporting this data, we’ll be able actually downloaded and view those results. All right, perfect. So we’ve successfully exported the document. Just go ahead and jump in and see that. So now from our site status monitor, we can be able to open this up and then see the information. We actually have that download. Let’s go ahead and take a look at that now. I’ll just go ahead and scoot this over. Perfect. Now, from our site status monitor, we’ll see that we have a fully editable and customizable output here, so we can actually edit this information, we can be able to see device details, device properties, and so on, and we can be able to change the data that we have exporting within NetBrain.
So now everything is hyperlinked, we can jump to device details, see information around our environment, be able to see layer two and layer three interfaces being shown and really give us some standard visualization of our network so we can wrap everything up and have that final package. In short, we’ve shown how we can use NetBrain’s dynamic maps to view and organize network devices, analyze our configurations through our CLI automation and Runbooks. And lastly, implement changes to our devices with our change management. I’ll go ahead and pass things back to Amena. All right. Thank you very much.
Amena: Thanks, Joel, for another great demo. As you saw from Joel’s demo, NetBrain can help in operations in a number of different ways and help you visualize network performance allowing you to perform health checks from time to time and monitor the performance of your devices. It can also help you automate troubleshooting diagnosis, automating a lot of the manual and repetitive tasks associated with troubleshooting and performing design checks. It can also help keep your documentation up-to-date by performing recurring discovery benchmarks.
So let’s recap how automation can help you prepare for a successful hardware refresh. You can automate network documentation with NetBrain for requirements and design review. Dynamic Maps help you gain deep visibility into the network. An automated network diagrams, inventory, and design documentation can save crucial time spent in collection analysis of data. NetBrain can also help you perform compliance checks. All of this can be done both in staging and after deployment.
NetBrain change management capability enables you to push out configurations and easily roll them back if necessary. Finally, you can use executable Runbooks to help automate compliance and just sign checks, quickly identifying misconfigurations and streamline troubleshooting workflows during operation.
If you like what you saw today, you can request a custom demo live through our website at netbraintech.com/request-a-demo.
With that, I’d like to thank you for joining us today. Joel and I will remain on the line for the remainder of the hour to field your questions. Please keep them coming for the Q&A window. We’ll try to answer a number of them out loud over the phone as well. Once again, thanks for joining us and have a great rest of your day.
