AI-Driven Network Automation and Insights with Opengear’s Production Platform

Demo. So I'm Matt Whitmer. I'm, uh, as Doug pointed out, a solution engineer for Open Gear.

I've been here a little over four years. My background is network engineering. I've been in network engineering field for just about 30 years.

So I've, I've pretty much run the gambit of networks. Uh, today, you know, our demo, we're gonna go through, you know, some standard network engineering scenarios, um, design deployment operations and troubleshooting. We added a bit of, a little bit of a twist with it, uh, based off of what we did last year by adding a little bit of a, some agentic ai, as Doug pointed out on top of our UDO Op Open Gear solution.

So, I think we'll have a lot of acronyms that we throw at you. And Doug kind of mentioned some of them. Uh, some of 'em, uh, we're gonna use today are lighthouse service portal.

That's gonna be part of our provisioning that we're gonna do. We call that LSP. Uh, the smart management fabric is SMF, where you use that as well.

Uh, connected Resource Catalog, CRC, that's gonna be, uh, basically our reference design or our inventory that we'll show. And, um, yeah, those are the three ones that we're gonna use. Um, so part of our Open Gear solution that, that we like about it and things we've shown in the past is the extensibility and flexibility of our solution.

Um, you know, that's a foundational piece of open gear, being able to do things that are just beyond just a regular console server. So, you know, you use your imagination. It's es essentially a compute as well as switch router and, um, and console server, your traditional type of console server.

Um, there, you know, there's a lot of things you can do with it, and some things we showed in the past is being able to run. I perf here at Tech Tech Field Day, we've done, I perf with it. We've run, uh, a Docker container to do Wireshark.

We had a web UI, or, or actually a, I think it was a Windows ui, uh, that we did. Um, some, uh, Wireshark analysis on DHCP thousand Eyes agents, and a lot of different customized scripts that you can do on the, on the platform. So, just to, these next few slides are just kind of set the stage.

So this is the, uh, this is the high level network architecture that we're using here for, here for the demo today, as well as what we're doing here at Cisco Live in general. So what we're gonna focus on today is the network, the boxes on the left side, uh, where it says OG Lighthouse. That's, that's basically where what we're gonna focus on.

Uh, if you wanna hear about the rest of us stuff, you could go see our booth. You know, we have, we can, we have a partner there that we, uh, partner with SVA, that we can walk you through some of this other, uh, design stuff that we are doing as far as the demo. So this is our detailed network diagram.

This is exactly what we're gonna do here in the demo today. Kind of show this, um, it's, it's a little bit of a non-standard, uh, network diagram, and we'll kind of get into why, as you see as we progress through our, uh, progress through our demo. Um, so what is, we have four operation managers, which we call oms.

We have a couple different flavors of oms. Uh, we have Cisco routers, three Cisco routers, and then we'll have IO and then A PDU. This is basically what we're calling our reference design for this, for this demo.

So we have, uh, our CRC, what we call our connected resource catalog. All these devices in the, in the diagram are represented actually in this catalog, this connected catalog that we have right now. So we'll get more into this, this web app here in the demo.

We just wanted to set the stage to show kind of, uh, you know, what our reference design actually is. So the first, the first scenario we're gonna go through is design and deployment. And lemme to this slide here.

So what we're, this first scene here is we're, we're turning a network design into configuration data. Basically, you need a network architect or someone with some, some bit of a experience to actually do, you know, create a design artifact, which in our cases, uh, network diagram typically. So we typically have, you know, our reference design, like you showed, like we showed, well now a company or a, we're gonna call 'em Acme Co Acme Corporation.

They want to add a rack to their Utah location. So the, so the architect, he creates a diagram, get orders the parts, and now he wants to, he, as he has that artifact, he wants the diagram to represent, he wants to get that diagram, which is, represents unstructured data into structured data, something that we can feed into our network design, uh, and then pump out configuration data. So basically, here's the steps.

You know, the architect creates the diagram. Diagram represents the data the team wants to get that, the deployment team wants to get that into something. They can use some configuration data.

So he uploads this app, he uploads his diagram into this app, which generates basically A-J-S-O-N with all the configuration data that shows in the diagram. And then that, that data, that data then is pushed to our inventory manager and is now part of the reference design. What we're going to show you today is, uh, one facet of the application that we've built.

And the, the idea here is that the, the earlier diagram that, uh, Matt just spoke to represents the existing network deployment, right? That's kind of the, the, the level set, the, the basic design that's deployed in the network. Now, they wish to deploy a new rack, and that's depicted by this, uh, this darker gray box over on the right hand side here.

So we've got LSP shown there, which is the cloud hosted portal we use to enable, uh, automated enrollment of open gear console servers into our central management system called Lighthouse. We've got, uh, a, an open gear, uh, serial console server there, the OM over in the, the right hand side, and there's an additional Cisco router. So the, the network architect has created an updated diagram that includes those additional elements.

So with the web application that we've, we've built, we can take that diagram and we can convert that to structured JSON data. We're not going to go through that because of just in the interest of time, right? We want to really get to some, some more interesting things a little bit later.

But we've got a screenshot of that, that function here. Everything that we're gonna talk about today, and everything that we're gonna show you is real. It does work, and it's integrated, as Doug said, on top of the existing open gear APIs and features and functions that we have in the product.

So what we've done here is we've, we've taken the updated, uh, network design, we've converted that to structured JSON data, you can see it listed on, on the left hand side there. And we have a button at the top of the application labeled push to CRC. So push to the connected resource catalog.

What we can do with, with that button is basically traverse the, the JSON document, extract all the pertinent information in it, and upload that to the, the inventory. Now that we don't want the ai, this is an AI assisted application, I should say. Uh, we don't want the AI agent to hallucinate, we don't want it to make things up.

We want it to only make use of factual information that it's able to extract from the diagram. And we did have some difficulties, uh, with that when we were putting this application together, but we've been able to, to corral that and, and get it to work in the way that we wish. Okay?

So we've, now that we've had the, the architect, basically he un he uploads his design, we now have that in our reference design in our CRC. Uh, we can move into the next phase, which is we're gonna stage it. So now we have a, you know, we stage this at a integration lab, essentially, so a var prior to sending it out to the site.

Um, So, you know, here's, here's, these are basic steps that you go, that basically go through. So, you know, step one, the sky he gets, he pulls all the equipment, cables it up, powers everything on, uh, step two, everything's powered on, everything's good to go. Um, and this is where the provisioning, some of the provisioning, some of the things that we do as open gear kind of enable this process.

Um, the first, so once it's powered on, we have an operations manager device. In our case, it's an OM 1208 that is actually in the rack that all the connected devices are, are managed by. So it reaches out as soon as you power it on.

It has an internet connection. It reaches out to LSP and LSP that our lighthouse service portal. Um, basically it provides a way for you to have visibility for your assets for the open gear devices, and also do some zero touch provisioning over the cloud, over the internet.

Once you, once you connect up, you can set up a configuration bundle in the Lighthouse service portal. The OM reaches out to Lighthouse service portal, grabs its configuration, and then it automatically configures. So in the past, we had folks use USB keys or whatnot, or manually configure it, and there's some security implications there.

And then if you have, you know, hundreds of devices, hundreds of open gear devices, that can be cumbersome. So this allows you to basically zero touch provision just by turning it on and having an internet connection. And if it's, and if it's, uh, cell connected, uh, same thing will happen.

Um, so once it, lemme kick this off, so once it, uh, once the OM gets its configuration calls home to Lighthouse, then all the connected devices, something else we did is we hosted the configurations for the actual routers that are hanging off of it on the om. So once the OM registers gets its lighthouse, uh, service portal enrollment, lighthouse enrollment, then we kick off, kick off a ZTP process, where now a Cisco router goes, grabbed its configuration and basically goes through the standard ZTP. You know, everyone's kind of went through that.

So it's just a standard, uh, CTP process. And then once that gets done, we can actually take those devices. We'll show this in there, we'll show this in the demo is it'll automatically discover devices and then populate into our, our, basically our inventory, our CRC.

And then once you do that, you can run a diff we have a diff utility that we set up that you can kind of see the difference between the, the network design and the reference design. And you'll be able to see that things will, those devices will actually add, automatically update, and then once that's done, you ship it to site and they can run the process again. Very good.

So what we're showing in this, uh, this, uh, screenshot, this is a list of the, uh, assets that are in the reference design. This is data that was extracted from the, the network diagram and this list of the actually discovered assets. So we have an application that runs on the Open Gear console servers, and it reaches out using passive discovery techniques like L-L-D-P-C-D-P, it can do, uh, serial port, uh, based discovery as well.

Uh, we, we did some things with op, but we took that out because ops just not terribly useful. You don't get very much back from that, but it, it does give you a mechanism to discover the, the actually deployed set of devices, uh, that are in the network. And then you can make a comparison between the two.

Right? So there's your, uh, in, in this slide we've got the, the reconcile devices, which are assets that are in both the reference design, and they're actually discovered in the deployed network. We've got two or three extra devices there, not really quite sure why those are there, but, but they're there.

That's maybe something that the network administrator should take a look at. And we've got two missing devices. These are the devices that were in the updated network diagram, but they've yet to be enrolled into Lighthouse, and the router has yet to be provisioned.

So this is a, a, a screenshot of the Lighthouse Service portal. We just put this in, uh, for context so that the audience can get a, a sense of, of where this fits. This is a, a, a cloud hosted service.

Customers can log in here, they, they can see their, their purchase assets, the serial numbers, and they configure the information necessary so that the console servers can automatically enroll into their on-prem lighthouse system. Okay? So now I think we're back to you, right?

Yeah. So this, this screenshot shows, okay, we've, we've run our LSP enrollment, uh, we powered on, we powered on the operations manager, and it's enrolled in Lighthouse. It gets automatically detected and reconciled with our, with our network design.

So now you see the top arrow there. I know it's really small, small font. Um, you can see the top arrow, that's the actual OM registered, and now it's, it's online and it's, it's talking to our CRC.

The bottom arrow is the Cisco router. It's still working on a ZTP. So it hasn't enrolled yet.

It hasn't, it hasn't got that con connection to the OM or to our smart management fabric to reconcile, be a reconciled device and be something in our inventory. So right now you can say it's going through the actual ZTP process. Okay?

So now it went through it ZTP process and it gets enrolled. Uh, it, it gets enrolled in, has its configuration and it's reachable through, through the smart management fabric to all the way up to Lighthouse and to the CRC. And then once this happens, you know, we have the reconciled devices, we have a new updated reference design.

Um, things are good. They run the diff, this is the diff utility, and the integrator can now ship it to site. So for this, this scene, okay, this is just a quick, you know, okay, we received it at site, we sent it out to Utah, and now the actual p folks on site, they're gonna unbox rack, uh, the racks and install.

They're gonna unbox it, cable, it, power it up. And then what'll happen is, uh, the whole rack will go through the same process minus the ZTP of the, uh, router, obviously, 'cause all that stuff's configured, but it'll call home the lighthouse. The om will call home the lighthouse, it'll do a double, it'll check itself against the CRC and say everything's okay, or everything's not okay.

Um, and run a diff to see, you know, if there's missing devices or, or whatnot. So let's say it gets there and a cable, a power cable come, became, uh, loose on the router. So once you do that diff it'll say, Hey, this, this thing's not online, this router's not online.

And it'll alert, it'll alert, uh, the knock or whoever's managing this from, from the home office to say, Hey, we need to send a tech out to go check this out. And you might have that, you can have that sensored, uh, you know, you could, you could check your port logs, your serial port logs, or you, you can have sensors for your power to see, okay, this power is gone. So the tech goes out and he resolves it.

Once he resolves it, uh, it'll go through the discovery and diff process again, and then hopefully you'll get that final look where everything's in the reconciled devices, and then your operational sites up. Alright, so next scenario, uh, we're going through is, uh, an operational scenario. So, you know, everything is up and running, everything's fine.

And your security, your, your security organization says, Hey, we want you to do an audit, a vulnerability audit at this location at your Acme co-location in Utah. So what we've done is we've set up, we've, we've set up in our, in our web app or our lighthouse web app, uh, the ability to check, check for vulnerabilities, specifically based off of the version of software you're running. And, uh, do a CV eight check.

So, you know, you can see the, uh, walkthrough here. You know, we conduct a, uh, vulnerability audit. Yes.

These are checked against CVS only, or is it checked against? Like, So in this, so in this app we're just doing cvs, cs, yeah. But yeah, CV are getting at that would be, but I mean, that's something you could set up.

It's just, you know, in our case, just for the, you Gotta have something to look At. Exactly. Exactly.

So, you know, we, we will walk, Andy will walk through this, but, you know, the user prompts the AI to do look for CVE impacts, AI goes and looks at checks, some websites, and then it'll output, and then you can generate a report. Okay, great. So there's a web application, uh, what we show in this part of the demo here, here's our discovered resource catalog.

These are all the devices that are actually in the network. You can see over on the right hand side here, we have this check button associated with each of the, the devices. So if I, if I press this, the application's going to reach out in this case to, uh, an online Cisco CVE, uh, application that they've, they've kindly hosted for us, or not for us, for, for customers in general, but we're making use of that.

And it's pulled down a list of the, the current vulnerabilities for this device based on the, the, the model of equipment and the installed firmware version that we found on the device. So this is, this is nice, right? You can, you can click through to this and you can, you can see the information that Cisco's provided, that's fine.

Um, but we're gonna bring a little bit of AI to this part of the, of the demonstration here. We've got this button at the top which says, analyze with ai. We click on that.

What the web application does is it uploads this list of vulnerabilities accompanied with a suitable prompt, and it sends that information to, uh, in this case it's using, uh, um, chat GTP. And we're gonna get back an executive summary based on these, these CVEs that we displayed here in a moment. Is it, is it simply a summary of the CVEs, or is it the summary relevant to my config it at the moment?

It's just based on the CVEs. Yes, but that's a, that's a great idea, right? This is, we're just putting our toe in the water seeing, you know, what works, what doesn't, how can we take this forward?

This is something that we could do fairly easily for, for the demo today. So here's an executive summary. Uh, it's showing us the, the most critical vulnerabilities and the, the areas of the product that are affected.

There's some statistical information about the distribution and the type of, of the severity and, you know, what sorts of vulnerabilities are have been published for this device. There's a summary of the affected components, and there's some suggested mitigation step. These are Cisco CLI commands that the network administrator could run in an attempt to maybe mitigate some of these issues.

And it's also reordered the, the vulnerabilities for us. So, you know, this can be exported as a, as a PDF or as a CSV file. So you know, you can take action with that.

There we go. It's coming up in numbers. So that gives you a, a task list that you could then work through later and take care of these, or pass them off to your s SecOps people.

And we can do the same thing for, uh, open gear devices as well. We choose one here, just choose this one. We get a different list of vulnerabilities.

We click analyze with ai. We're gonna get a, a different set of commands. It is aware of the, of the model and the manufacturer of the equipment.

So it's gonna suggest commands that are more appropriate or appropriate to the command line interface for this particular equipment. And you can click through these again. There we go.

Okay. So we've got, uh, some vulnerabilities identified, prioritized, uh, and then some, some suggested mitigation steps. And this is one of the interesting things with AI is you don't always get consistent and predictable results.

In this case, it didn't propose any command line commands that we could actually use to address some of these. Sometimes it does, sometimes it doesn't. So that may be an area for us to focus on to, to improve the prompt and maybe train the ai ai train the LLM to be able to get more meaningful results back from it.

So That's the, the CVE portion, uh, of the demo. Now we wanna talk about, uh, log analytics. So one of the mechanisms that we've built into the web application is, uh, the ability to stream log data from the connected resources and from the open gear, uh, console servers, take all that data and ingest it into, uh, a vector database.

So you can see some of the logs, uh, streaming in here in a few seconds and updates. And then what we can do is we can do analytics against those logs. So we can, we can ask it questions here.

Uh, we're going to give it a fairly, uh, generic question, a prompt here and see what it can come back to us with. Now, this particular AI implementation is running on-prem, so the logs are not sent out to a cloud hosted portal. This is all running, using, uh, an alarm model.

Some of the other features in the application were built using chat GTP. And this is just part of our process to kind of explore the, the, the capabilities of these different agent AI systems. Question, uh, Josh from Diversified.

Mm-hmm. Uh, when you mentioned where you're running the LAMA model, is that something that's in the lighthouse system, right? And that's where you're correlating all of the data or this log data is getting sent to?

Not yet, no. We, we've got our Lighthouse system, this application is hosted on AWS Okay. So It's, you know, it's private cloud, but we didn't take the step of integrating all of this as a lighthouse feature set.

So it's, it's done some analytics on the logs, uh, it says appears to be nalytics system, some interface issues there, some error messages. Interface is not found. Um, we have deliberately set up, uh, uh, a port flapping issue in the logs.

Uh, and when we run this on some occasions, depending on what log data is, is in scope, right? At the point where the analysis is done, uh, you will get information back from Agen AI about those port flapping issues. Yeah, essentially what we have, we, we, we set up a, a fail case basically in our, in our demo lab in, in Utah.

So we have a OM 2248 that's sitting there, and it's connected to a Cisco 37 50. And I basically create a spinning tree loop on the 37 50. We have port logging on for the, um, om on the om for that specific serial port.

So what's happening is, is the Cisco 37 50 is sending his logs and sending his logs to the om, actually, it's just reading his console. And those characters are basically getting sent, forwarded up to our, through Lighthouse to our LLM, um, as if you look at the log view logs. So it's a way, so you can go, oh, you know, the scenarios being, Hey, you know, we have a network, we have a network that's kind of going slow.

We have a complaint, you're at a knock, and users are complaining, Hey, this is going slow. And in order to not have to read through all these different logs, you know, tons of log data we've set up where you can just go query, Hey, we wanna look, we wanna look for some network issues, potential network issues on our, and the AI helps you out by analyzing those logs and looking for you, looking for those logs for you. So it says interface flapping.

So that's, you know, that's not quite correct, but if you read the actual, if you read the actual, uh, text there, it says, Hey, we show we have this MAC flap notif that we're getting, which, you know, if anyone's used a 37 50 or an older older catalyst switch, that's, that's basically the, you know, max jumping between ports. It's a spinning tree loop. And that enables you to go, Hey, I could go look at this.

And it specifies, you know, it's, this is on fa, you know, what is it 4 0 37 and 4 0 38. So then a tech can go down and, hey, I'm gonna go look at this port, I'm gonna unplug that cable or whatever device. I mean, I, I would, uh, Sam from wwt, I would caution you against inferring that, because that's standard functional behavior.

If a wireless client moves from one, Sure, sure, you're Gonna get a Mac flap notice, right? Right. And so how do you differentiate between proper mac flap notice and inferring that there's a loop, right?

Those are some pretty dramatically different. Yeah. So, so arrive at, so, so one of the things we, you know, when we we're doing this is looking at it, is to get to, you have to be able to, you know, train that your AI or your model to, to know what to look for.

And, you know, we're, we're, ours is not trained up just because of the memory context and things like that. So in the instance for the demo, we were just, you know, we want to create a pick out something, we wanna pick something out, and yeah, you're right. But, uh, uh, you know, it's just a way, but yeah, you have to train that so you, you don't get those, um, erroneous, you know, messages like it said, interface flapping, which is completely different from MAC flapping, right?

Or port flapping. It's different from Mac flapping. Um, so yeah, that's, uh, we pretty much walked through our, our demo.

I mean, any questions I guess at this point? Question, uh, Josh, uh, do you have the ability to swap out the, uh, model choice, uh, that you have? You, you mentioned Lama earlier, I was curious if there's an ability or roadmap or feature that could, that could open that up for us bringing other models in or an API to some private AI model that we've got running.

We, we do, we actually had a, a, a drop down selector in the, in the web application that you could use to choose the model. And we, we just pulled down six or seven of them. We took that out for the demo, just kind of to kind of keep the focus.

But yeah, that's a, that's a great thought. And that's something that we were, we were playing with ourselves just to get, you know, exposure and experience to the, the capabilities of the different models. And, you know, they're not all created equal, right?

You get better results for one, for some things, better results for another, But these models are models that you are running, you couldn't tie them into. Yeah, that was my second part of my question, is if we were running a private AI cluster and we had our own models trained on our own data, right? How could we, how could we have that network model being pulled from right.

Via API into, Yeah, as long as those integration points exist, right? It's not terribly hard to set up API keys and tokens and whatever else you need and be able to, to make use of a customer's on-prem AI system, private ai. Sure.

Perfect. Thank you. Yeah, thanks.

Uh, thanks for, uh, you know, coming through here and I think we just wanna open up to any other questions, uh, at this particular, uh, particular juncture. I think there's a couple of, you know, key things that, um, sometimes it's hard to demo this stuff, um, and watching the, the early pieces, but in essence, you're almost taking the equivalence of a, you know, a crayon drawing, being able to ingest that, turn it into, uh, data that represents the, the actual network, and then in real time be able to update that inventory. And there's a lot of things you can do with that, whether it's security vulnerabilities or whether it's other compliance things, tying that into other compliance tools.

Um, and then really the next steps, uh, you know, throughout this, there's a lot you can do with the CBEs that we didn't, uh, you know, share show here either. And some of those comments, I know we're, we're coming out, when you get into really analyzing, uh, log data, um, a lot more training that has to, has to go on in there. And, you know, I think even from an LLM perspective, uh, in retrospect looking back, uh, we'd probably change, you know, that out.

Now, I do think it's important if we can run locally, sometimes you don't want to expose your data, um, outside to the, to the wider universe, as Andy was saying, it doesn't really matter. Uh, lighthouse runs in AWS what we just showed here. We just happen to have the AI stuff running in a different instance of, um, of a WSI think it's actually GPU based, isn't it?

Um, you know, versus, uh, where we're running lighthouse. So in essence, that's all, even though it's, you know, public cloud that's still, uh, kind of a private deployment of that. And it's because you may not wanna push that data outside of your own own perimeter.

So hopefully this generated some thoughts, gives you an idea of some things that we're, uh, that we're thinking about. Do you have any roadmap, because it feels like this is a early development, right? Like along some features and capabilities you showed here today.

Are there areas of interest that you haven't developed yet that you're looking at around these AI capabilities that you can share? Yeah, I think we've, we've taken, you know, the production system as Andy was saying, and we're just taking advantage of, um, you know, the APIs, the interfaces on that to be able to extract them, build, you know, the, the agents that we've showed you and go, all right, you know, how kind of exploring the feasibility of it, both technically as well as, you know, how would it work from a business, you know, perspective. So yes, this is, um, very early kind of develop developmental work.

Um, you know, conceptually you could do the same thing yourself. There was nothing that would stop anyone from going out and, and taking open gear production system and doing what we just did here. Uh, I don't think that's how it'll probably be consumed to your point by most folks, they don't, uh, they'd probably, you know, want it more packaged, uh, than that.

And so as we experiment with it more and more, kind of hone in on it, um, then it'll get more real, really for the, for the product management team. Okay.