Session Information:

Introducing an evolution in Network Verification and Automation Software

Session Transcript:

And I welcome you to the next session at the top of the hour, So, without further ado, I will run the video here, and you should be having access to that momentarily.

I'm going to turn off my video, And then you'll have the feed from the, From the front, from the content video directly to you from this point on.

Welcome to the forward Network's user interface. It's a modern, sleek and responsive HTML interface. At a glance, you can see the currently selected network and the currently selected point in time snapshot of data that was extracted from the production network.

For any given snapshot, you can see the full inventory of devices that were present in the snapshot. The inventory also contains detailed information about v-lans and VRS.

Back on the main screen of the interface, you have a fully interactive topology diagram that shows the status of the network at the time the snapshot was collected. I can zoom in and out, as well as click on devices and links to get additional information.

Let's look at the search application.

At the top of the interface, I have a search bar that enables two primary types of searches.

The first is free text.

Example searches include locating a host by a mac address or by IP address viewing devices and interfaces that carry v-lan traffic.

We're finally finding all devices with the SIS routing protocol configured.

The second type searches through all possible network behavior, and is enabled by the mathematical model we've built. That includes all possible ways the network can send packets.

Let's look at an example scenario.

As a member of the network ops team, I've just received a ticket indicating that users are reporting difficulty loading our corporate website.

So network is always the culprit.

This landed on my desk first to resolve.

Initially, I may run a couple of basic tests, like checking the website myself, trying a ping in a trace route.

But if that doesn't give me enough confidence to fully declare the network innocent, then I'm going to find myself down in the command line interface.

Trying to define the behavior of each network device, when presented with potentially thousands of lines of configuration and state.

This can easily consume tens of minutes two hours of an operator's time, over and over again daily. There is a much better way.

For this example, in our UI, I can simply ask the system how traffic flows from point A to point B Here, I searched for how traffic flows from the Atlanta internet edge, where customers enter my network, and how it flows to the virtual IP address serving the application.

I will further restrict it to HTTPS traffic that is delivered.

At this point, we now see all the devices and link's involved in carrying this type of traffic in dark gray with the rest of the network faded out.

On the left side of the UI, we see additional filters that allow us to drill down further within this search, if needed, based on known terms that will further restrict the results.

For example, I could add a restriction that I'm only interested in paths going through a particular spine switch.

At the bottom, we see the results of the search, which are all paths through the network matching our search criteria.

In this case, we have 32 unique paths since we've built in redundancy at each level.

Looking at the first path, we can see at a glance the type of processing performed at each device, whether it's Layer two, Layer three, network address translation, and access control lists, et cetera.

I can click on any device in the path to see a full description of how that device processes this type of traffic internally.

For example, this firewall is performing three types of processing: Layer three, network address translation, and access control.

We've done the hard work in this view of abstracting the user away from the underlying vendor specific syntax knowledge that is required to assemble this picture of how the device actually works.

For example, you can see how easy it is to understand if we look at the Access control section, which we see is permitting through packets.

Matching to destination IP addresses and to Layer four destination ports.

All I needed is basic network knowledge to understand that.

If I want to dig deeper though, into the actual vendor configuration, we make that easy as well.

By clicking on See, Device State, we've highlighted just the handful of lines of configuration causing this behavior for this type of traffic, out of the total 4100 lines of configuration on this particular device.

This was one example search, but the Search Syntax is incredibly flexible.

Other examples I could search for could include, if I need to take a device down for maintenance, I could search for all traffic that can flow through this particular device to see if I properly drained away traffic before I turn it off.

From a security force perspective, searching for all locations that could communicate with a particular host in the network, or the inverse, in case a host was compromised. All other locations that the compromised host could have communicated to.

Searching to see if the appropriate paths are set up in a network prior to deploying a new application.

We're searching for traffic that flows across overlays, an underlay, such as v.m-ware NSX.

We're finally searching for traffic that flows across an on premise infrastructure and up into a cloud environment, such as AWS.

Forward Network Search enables massive time savings for network and security operations, network engineering, and others that work in and around the network by giving them instant access to information that's highly time consuming and error prone to assemble today.

It additionally empowers individuals to understand the high level behavior of devices, that they may not be experts in the configuration syntax of making them more valuable to the organization.

Next is the verify application.

Earlier, I did a search for a critical path of traffic in my network.

My customers being able to communicate and load web pages from my corporate website.

As an operator of the network, I need to ensure the network is always enabling this path, and I'd like to always know that even in the presence of all, ongoing changes that need to be made to the network, that this still works.

With forward verify, I can take that search, save it as a check that the system will automatically verify.

every time it collects data from the network, four will also proactively alert me in the event the network no longer provides this path.

And as I'll demo later, what happened to cause it to change so that I can fix it swiftly.

My network also has a security policy that disallows anyone from the outside internet communicating with my application servers on any port other than HTTPS.

So let's confirm the network meets this policy by modifying our last search to look for all non HTTPS path's paths we don't want.

Let's add this as an isolation check that says that from my organization, a secure network never has these paths.

Both of these checks we added, now land on the verify section of the platform.

Within Verify, we have two types of checks, predefined and search checks.

Predefined check's, focus on configuration best practices, that should be correct throughout your network.

Examples that are failing in this demo environment include ensuring that all ports in a port channel are up and connected, and then v-lans are consistent on both sides of a link.

The screen is just a few of these checks turned on. There's many more.

But we've added all of them because a customer told us that they had a major outage, because they weren't actively watching these. We like to think of them internally as landmines. They may be innocuous right now in your network.

But even a small change that in and of itself is perfectly safe, can trigger one of these to blow up and cause havoc.

Moving to the Search Check's section, this is where you can add fully custom checks that correspond to your environments, including the two that we added earlier.

At a glance, we can see that the Check We added earlier, for our customers, making it to the web application, is passing.

The network is providing this connectivity at this point in time, which is great.

Unfortunately, if we scroll down, we can see that we're failing the security test because our system has exhaustively explored where every packet could go on the network and found pass that violate the security constraint.

Imagine the difficulty you'd have tried to enumerate all possible ways traffic can flow in your network with port scanners in humans. It's tractable.

With mathematical model of the network, we can make this a snap, let us know, diagnose it.

When I click on Failed, I'm returned to the search page that now shows all the paths, the traffic and flow that violate my stated security policy.

Let's explore the first result and see what's happening.

Putting my security hat on. I should block this type of traffic as close to the source as possible.

So, it will look at the path and look for the first firewall that should be blocking the traffic.

OK, I've found it, and when I click on it, I'm then going to look at the Access control section to see what's happening.

Eyeballing this I see that this firewall is permitting traffic to a couple of IP addresses, which is fine, but In addition to the HTTPS port, which we do want, it's also allowing through port 22, which, which is SSH, something we don't want.

I can confirm and see where this is happening by clicking CEE Device State.

And if I I have all the config causing this, sure enough, I can see the porte object matching SSH.

So to recap, in just a minute or two, I was able to define a security intent for my network, discover that it's currently being violated. And further find out what I believe the exact line of configuration is that is the smoking gun causing the violation.

Think about doing this in your current system today and the time and energy involved.

Next question is, Well, I'd like to fix it, but I'm also concerned about collateral damage for any changes I make to the network.

Specifically for access control changes, we can give you that confidence using our predict application.

I'm now going to try making a change to this network, but only in our Safe Sandbox.

And then use for network software to tell me how that change will impact the overall network behavior based on the intent that I've added to the system via the Verify App, as well as any searching I'd like to do.

First, I'll click Edit in Sandbox.

Then, I'll outright delete the line, allowing in SSH. I'll click Save to Sandbox, then I'll click Analyze Changes.

The system is now going to take the last full collection of data from the production network, apply the change I just made to it, then re compute all possible behavior for the network.

Then, finally, it will re test all Intents we've added via the Verify App. And give us a nice before and after comparison, if we make this change to the production network.

For now, I can ignore the predefined checks that I didn't attempt to change, that were and are continuing to fail.

But if I look at the outcome of my security check, the system is telling me that, Fix, indeed, solve the violation. And then, for that particular intent, I'm fully secure.

But what about the rest of my network behavior? Did that change impact anything else?

Scrolling down, I can see that all other checks that we're passing continue to pass.

So I've got far more confidence that I can now use whatever existing workflow I have for making the actual changes to the device, and have it be successful.

After that workflow is push the changes to production, though, we aren't done yet to provide maximum confidence of the network's behavior.

We'd want to collect another snapshot of data after making the changes to production and confirm that no errors occurred during that process, and that our verification checks continue to pass as expected.

In summary, forward networks enables your operators to get instant access to complex network information they need constantly in their daily jobs. This enables them to be superhumans, working more efficiently with a higher degree of network agility supporting mission critical network communication, while simultaneously decreasing risk with network verification.

And Tom mute myself a big thank you to Fort Networks for making that video available. And for providing the technical insights related to advanced network management. We want to thanks again, for it now works for the support and sponsorship of this event, and the making accessible and no cost for global participants. Now, at the top of the hour, we're going to welcome Dominique Rose, who is the Director of Customer Success Engineering, and Lean I X, and that dominique's going to talk to us about an ... Cloud transformations and governance.

Over 70% of digital transformations are not meeting the expected outcomes they're looking for. And a part of that has to do with Cloud migrations, Cloud transformations, and the management and governance. And that Dominique is going to go deeper into that subject and that we're very much looking forward to his presentation. So please do join us back at the top of the hour with dominique's presentation on Cloud Transformation, and Cloud Governance. Thank you for now, and I'll see you back at the top of the hour.