Infrastructure as code in the AI era: how to get started and what’s new

Hello, good morning, everyone. Welcome to this new expert insight series and network as code. Getting started. Today we have Ed and that they will take.00:08As to this series and they will explore different topics, very interesting topics. And yeah, so let's let's let's just get started. Over to you, Rasman.00:20Floor is yours. Thank you David. Hi, everyone. Yeah, so we're gonna give a couple more minutes for people to join. While doing that we were thinking to touch on.00:30A platform that was introduced and presented as well in Cisco Live, which, which we call Cisco IQ, and let me let me share my screen.00:45Okay, I hope the screen is visible. Okay, good. So Cisco IQ is a platform that Cisco has built to help you gain.01:01You know, make most, make the most or make more out of the visibility on your purchased inventory. So basically.01:21This is a free tool. This tool will provide a view on on the entire infrastructure the entire base that you have, and it will allow you to gain visibility into things like CVEs.01:33When we talk about vulnerability to understand where you are with your service contracts, where you are from a an iOS, e.g., perspective in terms of the last day of support.01:52Gaining general awareness of your infrastructure so you can be up to date and be able to keep pace with, you know, with, with the latest developments, but also, you know, in case there are problems or vulnerabilities that have been discovered so you can be immediately.02:07Notified. On top of that, this is an AI native platform. This platform.02:27It's gonna, it has an AI agent embedded and that agent will allow you to query basically all the information inside the Cisco IQ helping you with different types of reports have help helping you focus on just a specific part of your info.02:34Structure on a specific device and understand the situation of that device again from a last day of support perspective, from perspective and many more things that will continue to to be active, to, to be added. So the goal is to help you be as proactive as possible.02:54While you keep an eye, and a control over over your, your inventory.03:15How do you get this? So as I said, it's it's a it's it's free, right? So you can enroll if you are already a CX Cloud customer, you will be able to migrate all the inventory and the contracts that you have registered within CX cloud into Cisco Cisco IT.03:23Two. And here we have the steps.03:42And then if you are a new customer, then you can just register for the platform and start adding the contracts or, you know, your purchase orders and everything so that you can start populating your, your inventory. After that you will be able to use all the capabilities that are already built into the product.03:47There are sessions that have been delivered at Cisco Live that go in deep in each of those capabilities, even give you a look into the roadmap. Our goal for the session today is not focused on this. The goal is just to create awareness that this is something that it will bring you a lot of value.04:08And that it's available today and that you can register your, you know, purchase inventory, but you can also connect it to other products that you have maybe purchased from, from Cisco Cisco cloud products like Meraki controllers and so on. So.04:26And so forth. So with that, I'm gonna stop sharing. Let's see. We have 32 people already registered. I think we're good to go, right? We're good to start and kick off.04:46Is that ok Ed, David? Okay guys. Good, so let me let me share again ok going to presentation mode.05:06Good, so the topic for today is infrastructure as code, right? And the goal for today is to basically walk you through what infrastructure as code, but more specifically what network as code is.05:25And how it can help you. We're gonna give you an overview, you know, of all the different components. We're gonna have a lot, a lot of demos, but we also gonna try to touch on how does this play within this, you know, AI fast based world. Is, is this still.05:44Right? Are we wasting our time automating in 2026? Have we wasted our time automating or doing automation, you know, in 2025?06:04Is that something which is absolute obsolete, right? So I guess that's kind of like the elephant in the room sometimes. The reality is that, you know, AI is here, and from the beginning, my opinion and you know Ed's opinion we.06:16Really believe that.06:36Automation is actually part of the foundation to make AI successful. It will help focus it and it will help make it more predictable. And we're gonna keep that trend across this entire session and try to build a piece by piece why we believe that that is the case.06:38My name is. I'm joined by my colleague Edmore. We both are part of customer success team. We are part of the adoption team. We're mainly focusing on, on service provider mass scale, infrastructure, but actually for me and.07:00And we also look.07:20We look at the situation or the solution across the domains, right? So, that's where actually automation comes in. That is where the value of automation usually gets extracted from. The moment when we get to cross domains and we are able to do things that help us be more efficient.07:23And have a better visibility and get to a standardized situation.07:43So before we start, what I wanted to do is just to get a feel of the audience also just to kind of, you know, give you, an opportunity to interact a bit with us and we have this poll and, if it would be ok with you, please just scan the QR code.07:49And just tell us like are you considering right now to integrate the AI in our, well, there's a typo in there in our processes. And the three options are like I'm still trying to figure this out. We are already testing some of the AI tools and actually we are way ahead of you.08:07And we already using AI and this is already part of our pipelines or, you know, our day to day work. So, thank you. Here we go. We have the 1st person that broke the ICE. Thank you very much. So still trying to understand the AI. Let's give it, you know.08:2705:10 more seconds, and then we're gonna just continue with the with the session. Okay, that's good. Three people, thank you. I think we have like close to 40 people registered already so I think we can do at least ten.08:45Let's get to ten so we can get like a wider base there we go, it's good to see that we have people that are already using AI to have AI.09:03Part of their processes. So kudos to you. Okay, that's good. We're at eight people. Thank you very much. I mean if we look at this, it's mixed, right? And it's fairly evenly you know distributed.09:20Which is kind of, you know, true with the situation where we are right now. AI is moving extremely fast, introducing it into, into our environments is not a straightforward process. AI is not very predictable, right? It's a probabilistic.09:40In nature so it it will predict what it will be it will do next, it will not guaranteed specifically. So what it needs in its help, it needs help to be more focused. It needs help to be more deterministic, right? And that's what we believe automation is capable of doing.10:00Right, so thank you. We are at eleven people. So I'm gonna just continue, but thank you very much for sharing sharing your opinion and where you are right now. And we're gonna try to, you know, address all three points. But again, this is an introduction session, so we're not gonna go extremely deep into any of the topics we're gonna go very.10:18However, there will be sessions that will follow this one. So one will be in the week times, which will be focusing on SD one. And then in September we're gonna continue with a series of three more sessions where we will take different domains and we will also go more into the AI piece.10:38So for today, we're gonna look at the evolution of the network, right? So understanding a bit the architecture, so I'm gonna walk you through that then Ed is gonna take over and it's gonna go through the use cases and the compliance and validation. And at the end I'm gonna come back and.10:56I'm gonna try to kind of show you how we can use simple steps to help AI be more focused.11:16But also kind of to give you a glimpse of what could be if AI would be comb combined with networkers code. Okay, so with that said, how do we usually start, right? So.11:24We focus on what we actually want to to achieve. And usually that falls, in general that falls into these four pillars is not necessarily limited to it, but the gen, the the biggest part for would fall under these four pillars, right? So we're looking at.11:41Productivity and when we think about productivity eh, we, we think about, ok, what does it make sense to consider for automation that would help me do more or would help me do things faster or both, right?12:00In a manner that is, you know, that I can trust. So that's that's where, productivity sits and those are usually the outcomes that most kind of desire desire for. Once we do that, you know, we're gonna introduce a faster pace into the environment, right? So we're gonna generate more conf.12:20Integrations we're gonna generate we we're gonna spa we're gonna, you know, enable more services for the different business units. So that will introduce more and more and more work. So the question is how do we continue to keep an eye on that? How do we make sure that we get.12:40A way to properly audit it and stay compliant. How do we make sure that we make it simple to gain visibility and be ready especially if we are in high regulated environments like financial sectors or healthcare and so on, right? How do we have a a proven.13:00A simple way of gaining visibility into the change, the change life cycle. So that is where compliance stands. As we introduce more and more information especially with AI, right? AI would maybe even more.13:20Improve our speed into in introducing new capabilities, right? And that brings with it also, security concerns, right? So yes, we get to the point where we are able to, you know, get gain a good visibility, but also how do we keep a track?13:39On, hey, do I have there been vulnerabilities that have been discovered? If they are discovered, do I have the flexibility and do I have the speed that I need to be able to implement patches? E.g., to get those fixes in, especially for the known.13:58For the non fixes, so that's that's what it is meant by security, right? Some it's an aspect that we really need to take into consideration. And then the last but not the least, you know, it's availability. So introducing automation provides predictability.14:18It provides you with the tools that will allow you to have a better control over the over the network over the infrastructure itself, which in turn it will give you the possibility to have a more available available network.14:37Network or to remediate problems faster or to detect issues in a faster manner. So these are the four pillars.14:56And this is basically, you know, what drives the curiosity to automate sometimes or the need to to automate sometime. So we don't necessarily know most of the time where to start or what makes sense, right? But, as far as we start at this point.15:07Point we can identify like, hey, I want to work on productivity right now. Let's, let's see what are the things that we feel that are extremely exhausting extremely repetitive. How do we put that into a workflow? How do we put that into a pipeline? How do we turn that in and automate it? So with that in mind now.15:27Let's have a quick look at, at the infrastructure, right? The architecture. And, what I like to start is at the point that.15:47Cisco and other vendors as well, but you know, in our case we have, we have invested into the infrastructure that we provide our customers since many many years and build the capabilities that actually enable, enable networks.16:00So we enabled infrastructure as code. And those, you know, at the beginning we you were at the beginning and still it's the case, right? We do a lot of things through CLI. We automate through through scripting. But then we have introduced and we have defined our config.16:18Integrations and we have defined the features in our products leveraging data models. And that provides a structural view or structural data a structural representation of the capabilities of of our devices, and that's valid for you know.16:38Well, if not all, most of them, if we think about ISXC XR, and XOS and so on and and so forth. But then we have introduced the ability to access them, right? So here we talk about restconf, netconf, you know, the APIs and the ability to keep an eye on when we call this like model.16:58Moving forward, we have introduced controllers and the controllers provide us never higher level of a struction.17:20But they do build on top of the 1st two, right? They for for the older devices, they will use CLI for the newer devices, they will be able to use the data modules, the data models, the APIs, and so on, and so forth. And when we think about as code, then we think about tools that are.17:29Allow us to provision the infrastructure, leveraging all these capabilities like Terraform and Ansible and Cisco has built modules for Ansible and providers for Terraform for our operating systems. We are maintaining those and.17:49They are actually, you are actually gonna see them in action in ed's in that section. So the main message here is there are capabilities right now that you as a customer.18:08We are also using, and we are also using to do automation, right? They start from, you know, the, the most basic and they go to the most advanced. The message is that if you're already doing that, the question is not how do you redo that or rewrite that? The question is how do you.18:23Bring that into a pipeline and combine it with something else so you can make the automation more more concrete, right? To make to make a bigger impact and gain more value out of the automation that you're building. So if you, e.g., have catalyst center or if you have SD one, you're gonna see.18:43In the next session, right? It doesn't make sense to go and write something in Python that would simulate that already these controllers are providing, you know, the question is how do you leveraging the capabilities of those controllers and then include that into into a proper pipeline and extract even more value out of it.19:03So if you think again about the architecture of today in general, you know, vendors tend to build things in silos, right? If we think about the data center domain, if we think about the land one domains security collaboration, and so on.19:24So and so forth, right?19:42With infrastructure as code and with network as code, what we are looking at is to build on top of all those capabilities that I mentioned in the previous slide and create an abstraction layer on top of it. An abstraction layer that will translate.19:45The intent into what is needed to actually be able to provision across across this infrastructure, ok? So basically what we're doing here, we're taking proven tools that are being used in the pro program in by programmers, right? By developers.20:05And we are adopting them into into how we manage and provision a network. How do we build and manage the life cycle of our networks? So.20:25What, what we are doing is basically we are creating a representation of the configurations and taking those outside of the of the infrastructure itself. When we do the, when we do that we need a a as a place, a single.20:39Place that we can trust and a place where we can manage all that information and also track it. So that is what we call a source of truth. In general, we use tools like GitHub or GitLab for those and once we have the representation of our network, then the way we do the translation is by leveraging.20:59What I mentioned like the Terraform providers and the ansible modules, and that is what we called as the automation agent. So they will provide the abstraction layer that will translate into what is needed to be sent down to the device so that it can it can actually provision.21:19So here we talk about, again, Terraform and Ansible. In general Terraform will be the one that you will bump into the most, but there are a situation where you know ansible, is more is more interesting, but also a combination of the two is is something to to consider. It depends on the use case.21:39Basically depends on which parts of the infrastructure you are owning.21:59Next to it, we have the automation, let's say we have the single source of truth, we are consolidating the configurations, we need a way to be able to track, and gain visibility. And this is not just about.22:04Visibility of how is my device performing or how is my application performing. But this is visibility before I decide on a change, and decide to implement a change and then after I implemented a change. And also we can do, we can take it even.22:23Higher and think about, hey, I did this change. How is my application actually behaving? Am I seeing any improvements and I'm am I seeing the degradation of, of service? I'm having here Splunk but of course it can be other tools that you know are part of your toolbox in.22:43Our case, you know, Splunk would definitely go across all all those layers.23:03Once we have, let's say, now that we talked about like the the infrastructure and how do we build that abstraction layer on top of the infrastructure, moving further up, we're talking about services. And this is where the question is not about hey what device do I need to provision, but the.23:10Question is, hey, how do I deliver this across multiple domains or across multiple devices? Right. So how do I take this specific service and then I have it delivered across, implemented across multiple devices across domains? So we in this we have the.23:29As orchestrator in our case, we have the NSO and into services orchestrator, but also our CX customer experience delivery team, you know, they have built APIs. So this stands for network as called APIs, which is a layer of abstraction that would sit in between any.23:49Any workflow that you might be using.24:09Workflow tool that you might be using and, you know, everything that we deliver with network. So what it will do, it will be capable of translating it to whatever is needed right for the infrastructure to to follow the provisioning. E.g., if you have an application that you want provision and you need a.24:12Specific infrastructure in different places, you know, this will help easily translate directly from those orchestrators.24:32And at the end we go back to basically the 1st slide where we are talking about the KPIs and what is driving this, right? So it can be the optimization of an ITSM process or it can be actually a self service, right? This is quite interesting.24:43For more and more customers. I think Ed is gonna touch on this in his part of the the demonstration and presentation. And this is basically where we provide a catalog for people that might not know networking so in other departments but.25:01They need to have the infrastructure provisioned in the network as they deploy a test application or anything that they they they might need. So this will be a self service where they will be able to go and ask for things to be provisioned.25:21For them. And then the last piece is the AI ops, right? I don't specifically have it on the side, but the last piece would be, would be AI ops. So basically how do we combine all the predictability that we're building with the infrastructure as code, with network as code?25:37With AI and does that bring us value, right? So that's that's a topic that is being heavily investigating right now, heavily tested. And I see that some of you actually have have that and are using that.25:57Okay, so if we are to break it down from a perspective of network as code, we have, five major stages, but this doesn't mean that you will have to go through them one by one. It it depends if it's a greenfield, if it's brownfield. But in general, what we do is, you know, we create that single source of.26:12Sorts of truth where the interpretation of our of our infrastructure gets consolidated and then before we we do an implementation, we want to be able to do validation like semantics, linking and so on. We want to be able to have someone in the loop.26:32And maybe do a technical review and then we do the deployment and later on to make sure that everything went well. So we will do like post post change testing and validation, so we can trust, you know, the, the outcome. So these are like the kind of like the five stages of network as code, but again, you can go in and.26:52Any of the stages, it depends where you are and also it depends again of the project and and what are you trying to to achieve. But the main message is that this is not a product that Cisco sells, right? Network as code is not something that we sell or anyone sells, right? It's, it's actually a framework.27:12And if we look at it, it's basically, we have the network operator which creates a JSON file which represents the configuration of the device. We put that into a workflow, in the workflow we do, we make sure that everything is correct, the way it's defined in the.27:31The file and then we leverage either the controller or we leverage the different capabilities that we have built into the infrastructure to do the the deployment followed by doing testing and the deployment checks that we need to make sure that we trust what was what was deployed and then make sure that.27:50We have a way for people to be aware that, hey, this has been implemented, these are the tests that were done, test that were done, these are the results we trust the change, the change is final and we can we can track it into production. So.28:10Imagine this, how much this would speed up, you know, different actions that you do on a repetitive basis, being able to port that into each of these stages and have it reused over and over again in a manual semi manual or automatic.28:29And then the last you have to think about it even though in here it looks it's linear. This is not something that usually it's it's linear, right? It starts at the individual level. I define as an operator the configuration, e.g., right?28:49Then I have tools that help, check the syntax, the semantics, you know, linking all those things to make sure that we avoid any, you know, dumb dumb errors. After that is happening then we trust that this is ready for the change. We try.29:08After this change, we wanna go and plan for it. We wanna go and test test it or simulate it in a way, right? So here is where we have capabilities built into terraform, e.g., where we can do planning.29:27And some analysis pre change analysis. Once we trust this change is valid, this change is is ready to be implemented, then we go and we we do the the we we trigger the workflow, we trigger the pipeline to actually do the implementation.29:41So we have the deployment, we do the testing, you know, and again, the post change validation and and so on. So it's a multi stage, it's rarely just a linear process, it's a multi stage where you have the individual aspect of it, then you get submitted, you know, the organization or team level so we can gain the trust of the team.30:01And we make sure that we remove any errors and then we moved into the implementation once once you know all everyone agrees.30:21It is not, always a simple process, right? And it is going to generate the need to do things differently, right? There will be some operational changes that will have to take into consideration, but once you manage to identify what those changes.30:32Need to be and you incorporated in your, in the way you operate then the significance and the gains are really really really noticeable.30:51So before I pass it to Ed, again, this is not something that Cisco specifically sells, right? So you can leverage the native capabilities, e.g., the native capabilities that I mentioned, right, that are built within the network, and that in.31:01Includes also the controllers and everything, right? And do this yourself. Then we saw that there are, you know, network engineers, let's say or we saw that there is that audience that does not necessarily have the wheel or they don't have necessarily the.31:20Feels and they need more abstraction. So that's why we build network as code, so to simplify and standard standardize the way we present the features and capabilities in our products to the tools that are being used by a developer usually, and that builds like the tool set for network as code.31:40And then for those customers that really need the systems, then we have services as code which is an offer that is delivered by our CX deliverable organization.32:00So with that, I'll pass it to to Ed and Ed, let me stop sharing. Thanks. Perfect. So what I'm gonna do today is basically just assume you know absolutely nothing almost and we're gonna.32:11Start from a bit of scratch. And then I'll show you what some of the experience actually is and why we're doing some of those things. We're not gonna be able to cover everything in here, so it's important also that we share some of the resources I think that you guys can start building some of this yourself. And then as mentioned is that in September we're we're gonna run some more advanced sessions where we go through.32:31You know, maybe some use cases around how we can manage secrets with the tools like vault or Openbou and Netbox integrations and stuff like that as we need to. So maybe to begin, so we talked at the very beginning about the the the necessity to have some business requirement. Are we being more productive or we being more compliant, secure or available?32:50Right, and I I think that's a really important aspect here because the question for most of us should be asking when we're looking at starting infrastructure as code is, you know, do I really need to do this? And we have a lot of capabilities that sit with inside our controllers that really simplify things. But when you start to work on scale, so you know e.g. if any of you guys have deployed an ACI.33:11Fabric from scratch or deployed branches from scratch. Entering all that stuff into GUIs or building your own, you know, automation kind of tools in order to do that is quite onerous. Like I always give the example once I deployed a full customers environment. We're really happy with myself and walked away or almost before I walked away realized I deployed the wrong.33:31Customers network onto the fabric and, you know, so we need to do this in a relatively safe way while also being you know on on top of what we're doing. So.33:51To kind of get started, so the the concept that we have is around network as code and I'm actually gonna break the PowerPoint almost straight away and, and take you to the sorry and and take you to the browser. So most of the stuff that we're talking about today is actually documented in nettiscode.cisco.com and.34:01If we just go through the get started very briefly at the beginning, you'll have an explanation of what some of these components are for the different architectures. So we have an example e.g. here for for ACI, for SD WAN, all the different technologies that we see is the the most popular ones. But we also cover quite a lot more and I'll touch on that in a second. But if you do want to kind of have a look at the.34:21That's a practical way of doing this after this session. You we have, e.g., sandboxes that are available for you to run some of these different examples in. ACI is usually the primary one, which is one that was most popular to begin with, but we we also have other environments for for and things like that. And then it steps you through all of these kind of.34:41Is here to kind of get an understanding of what's going on. And then with regards to support, so you can see e.g. here all the different products that we support, today you see network as code. Now the maturity for some of these is gonna be different depending on some of the devices, right? You know, it's gonna be based on customer requests in a location.35:01So some of them are a lot more popular than others, some of them are actively being developed, but again I'll I'll give you a a roadmap item to explain that in a second.35:21So, the, the reason or why do we need networkers code? So what we kind of realized quite early on is that we have all these different automation tools targeted towards network engineers, and it wasn't really hitting, and I think that was because we have so many different parts of our jobs that we have to do. You know, we need.35:29To be experts in our area of networking, we need to be experts in infrastructure generally, and now we also have to master all these additional tools. So a guy called Dan Schmidt started building an abstracted kind of model that would be able to describe that infrastructure in a relatively easy way to understand. And so we want to still use those.35:49Components. So we want to still use the Terraform providers and you know the time that the ansible modules in order to deploy that because we don't want to have to maintain loads of new kind of tools but we need to provide a bit of simplification that exists on top of that.36:09Now, it's a very, very brief overview, we're gonna be looking at Terraform today, but if it's absolutely brand new to you, essentially what it's gonna do here is, is two important things for us. Like one of them is that it's gonna interact with the infrastructure on our behalf. So all of the APIs that it needs to call, how it wants to kind of manage the data that we define is.36:26Managed by the Terraform provider. So that's the the really nice thing. And then what it also does on top of that is it allows us to plan to predict almost what the impact of our change should be in advance, before we do the the actual apply. And that's really, really important when we're trying to get adoption for our automation tools. Like a lot of the time I see resistance, you know.36:46To to automation or those kind of initiatives because we're not really sure what the outcome's gonna be. Like is our change gonna blow everything up? And we we want to try and make that as easy as possible to do. So we settled on terraform or open tofu, which is the open source version in most cases.37:06So, the the barrier again, as I mentioned before is having to learn new tools. So what does this kind of look like as a comparison? So here's two examples that does the same thing. So on the left, what you see is a tenant configuration for ACI where we define two vrfs, one and two. And.37:23You know, I think most of us on this call can figure out what that's gonna say in a little while, right? But if you look at the comparative netas code approach on the right, it's much, much simpler. And so then if you have people which maybe aren't, you know, don't have automation as a primary thing for them in their roles, the, the one on the right I think for nearly all of them is gonna be the the more.37:41This one. We do have some customers that say actually why I don't need that, you know, we're more oriented towards cloud ops anyway. We're happy with using the native providers and that's absolutely fine. So we're not here to say, you know, this is the way you should do something. It's more to give you an option if you want to start working with some of these tools as well.38:01So the the simplification, that's the core tenant, and then what we want to try and see also is, the same approach that is gonna now happen through all the silos that were talking about before. We want to start trying to describe our infrastructure in a similar way across all of them.38:19So eventually, those workflows that you also saw before start to look similar. So what should your expectations be from a reporting perspective before a change? You know, can I automate, e.g., the generation of the change report before I do that? And so even if you don't know a Nexus dashboard or ISO or NXOS.38:34Again the simplification theme, we should be able to figure it out. And then our tooling because it's a similar kind of structure is gonna be a lot easier to maintain as well. I I've been doing, you know, automation projects for twelve years now and some of the, I think assumptions that we make at the beginning is that we're gonna deploy this tool and every.38:53Things gonna be fine and then you move on and you end up maintaining the automation almost as much as you maintain the infrastructure. So again, the, the key, the key kind of message so far is simplification on that.39:13I'm gonna start off by just doing a very brief kind of demo. In this example, we have GitLab and we're gonna be using Terraform to provision our objects within ACI. So if I just open up cursor.39:24And I'll zoom in just a brief bit so you guys can kind of see. So actually, before I go straight into that, what I'm just gonna show you, this is a very simple lab setup to automatically build GitLab in the self service portal and few other bits like that. I'll tidy up the code and then I'll release it so you guys can also have it as, as a reference here as well. So if I just.39:41Open GitLab as an example. We automate the creation of.40:01Three different reposits or four different repositories actually in this case, ACI SD WAN and catalyst center. Today, e.g., we're just gonna be looking at ACI. So inside of this repository, and again if this is brand new to you, don't worry about it too much. Essentially what you're looking at here is a document store. It's how do we contain all of the, the code that we've got?40:05And we're gonna use some of the other features as well of GitLab, but it is core, that's what it's doing for us. It's version controlled data. So we can go and have a look e.g. in this data folder and we can see the way that we describe some of the infrastructure here. So in this case, what we're looking at is a tenant which is called tenant A for for simplicity and.40:25And as part of this, we define the configuration underneath that in this format. So it's got this VRF called default, it's got some bridge domain here, and then we create some EPGs. Now e EPGs, if you haven't, if you're not familiar with that, you can essentially think of them as an application and bridge domain for most purposes, so you can think of it as a VLAN.40:45So once we've defined that configuration as part of this, now we want to actually build this workflow. And there's there's an important file here within this repo which is.gitlab-CI.yaml. Now this could be custom for what you're doing in most cases it will be custom. But just as an example today, essentially what we're, we're doing is going through three.41:05Memory stages. How do we validate our configuration before we make a change? Can we plan what our configuration is gonna be? And then can we actually deploy that with inside of our infrastructure? In each of these stages, we're gonna execute basically CLI commands on a runner. And a runner in this context is, it's a docker.41:25Container that I have running on my laptop. But in most cases what you will have in a production instance is you would have runners distributed across your infrastructure in, in different locations. So if you're going to split, e.g., different security zones or, you know, maybe you have different availability you you could have multiple runners and you probably would do across a wide environment as well.41:45But within that runner, what we have is some tools that we're gonna use and if they're built automatically. That's not always the case. So you can sometimes see stages at the very, very beginning of this where we're installing some of the tools into our environments, but you don't really want that. You want to have all the tools available to you, so your pipelines don't take a long time. And I'll.42:05Talk through what we're doing at each of these individual stages a bit later on when once we go through them, but just for the for the sake of it, just know that we're doing different logical steps and as part of this workflow, we can visualize what they look like. So if I just pop here to the pipeline editor.42:25We get the, the, the configuration that we have for our actual workflow, but we can also visualize what it looks like. So in this example, very, very simple. Validate, plan, deploy. These can become much more customized, you might have integrations to pull information from other data sources. You might have notification pieces. So, you know, if you.42:43Going to fail this particular step, do you need to go and notify this person? So we can build all this kind of process into this as well. And then lastly before we actually go and look at some of the content, when we have our repositories, we're also storing the.43:03The terraform states, so the status of concept where essentially what we're trying to track is what is the current state of my environment? What, what is configured so far that I know about. And so there is some more advanced topics, you know, if you're interested in looking at scalability, I I'd really encourage you to have a look at the Netas code site.43:19There to kind of talk about how we might do this when your environment's very large, but in this context we have a single state, nice and nice and simple to work with.43:39So, if I just kind of talk through this one as an example, we've looked through the files that we kind of had before and we're able to make a change based on those. Now in this example, just as to show you what it looks like, we have a terraform file here where we define how we want Terraform to to act.43:47So I provide for e.g. variables here, which is the URL of our environments, usernames passwords, all this kind of stuff. But what you can see is here we're using these providers and modules in order to implement those. So these are public. You can use these without going to Cisco and paying any money, and you can build everything, you know, yourself. Yeah.44:07Worked with a customer, you know, over the last three or four years and that's what they've done. They they've fully automated deployment of their SD WAN environments, their FMC and the boxes that they've got also, and then for ACI as well. And they're now looking at NXOS, and so it's really up to you, right? So if you if you want to kind of work on some of these yourselves, we're trying to prove.44:27Provide all the resources that we can to start building some of these.44:47So I'm just gonna step through and what i've done here just because I had some stability issues in my lab, I've actually just ran these pipelines already and we'll just go through and talk through what it's doing at the different stages. So the 1st step actually here was I had some issues with connectivity, so I wanted to kind of just show an example. Now a lot of this information that you've seen is not.44:51That useful well it's useful for troubleshooting but it doesn't actually.45:11It looked very nice, I think for most people. But just to show you that we're doing more than maybe just interacting with just ACI is I needed to try and connect to an environment that we've got within our lab and make sure that everything was working in advance because one of the worst problems that we had with Ansible, and that's maybe one of the reasons why we, we prioritized Opentofy a bit more.45:16Was how do you kind of manage it when configuration is half pushed? You know, rollback scenarios become quite complex, so what we want to try and do if we absolutely can do is to get a view over what's gonna happen before we actually deploy the the configuration. Now, when we look at the plan.45:36This is essentially what we're doing at this stage. So you can kind of see, e.g., we're managing the variables and things with inside of the the container that we're running. We're loading the plugins, the modules that we need in order to be able to run this. And in this case, what it's actually told us is that there was NO changes to happen. So.45:53Okay, that's that's absolutely fine. But what does it look like when we do have changes? So I'll just open up an example here and you can see in this example what we've done this way we're trying to add an EPG into our environment and so it gives us this terraform.46:11You know, style overview over what's kind of going on at the different stage, and it'll give us these little additions, so this tells us we're adding things into our environment. If we're changing things or removing them, we'll have different symbols there to display that. But what we can do is once we have these these artifacts as part of our planners, we can use them in order to create.46:28Resources. So here's a very simple example that we worked on with a customer as an example. So this is you're looking at cursor again, and it's a canvas within cursor. But I used in this context I think it was using composer two to five in order to be able to, to create a change report automatically. So.46:49While we were previously talking around automation and the provisioning side of things, we realized that that doesn't represent all of the changes that we actually do. I did a piece of work with a bank that said actually that the actual deployment only accounted for about 8 % of the efforts that they had about 90 odd percent, you know, was all management and service requests and figuring out what the.47:08The actual request was originally, planning it, doing all that kind of stuff. So once we've now got this, plan output from our.47:28You know, from our proposed change, we're able to kind of generate some of these things really nicely. And I I think that's a nice place to start. If you are, you know, one of those people that are starting to look at where we can use artificial intelligence in this space, I think getting it to, to understand and process, you know, some of the the data that we've got is a really quite nice starting point because there's NO worry about.47:37So, you know, going off and deploying changes we don't expect, and we can build skills in order to do that in a nice efficient way.47:57But just to talk through as an example, we can see here that when we were gonna do in this case our our initial deployment, we're adding a load of config items into this. We're not updating anything, we're not removing anything, and this is how it's distributed, so we needed to make changes in the fabric, some of them were in the tenant a, and some of them were in tenant B And the the bit which.48:04Becomes interesting is when we start to try and quantify risk associate to it. So if you're making a really simple kind of change, what kind of tests do you want to run? If you're making a very high, you know, risk kind of change, maybe that's one that we, we need to be a bit more careful of and think about how we could do change planning in that example as well. So just an example of how we can kind of.48:24Say, you know, maybe you know using some of these tools doesn't mean you have to look in the, the runner output or the GitLab logs output all the time. We can take some of that information and then start to, to visualize it for people that maybe live outside of the automation space as well.48:44So let me just pull this in. Do ok so what we kind of had a look at so far was essentially the 1st step where we did a plan inside that environment. And so I'll go through and talk about the deploy a bit later on.49:01Didn't get the sorry. So ACI change report in this example was a skill that I created, and so I was able to then visualize the terraform output with inside cursor but if you did something the same with VS code or had another kind of approach, it's essentially just rendering out a diagram, so the point here should be that.49:19Yes, we can produce artifacts from our Terraform plans, but what we actually want to be able to then do when we're working with people outside of you know our teams, we want to try and visualize that in a nice way so we can understand what's going to happen as well.49:38So, yeah, so we talked about the plan aspect, so essentially at this stage what we've done is we've said, ok, this is what we predict is gonna be the change that we're going to do. An important point to, to make clear here is that if we're deploying in an automated manner in our environment, that should be the primary way that we're deploying changes. So if you.49:52You are in an environment where you have a lot of people making some manual changes and you're trying to do some automated, a Terraform might not be the right tool for you in that case. Maybe something like Ansible is a is gonna work well in that space because we don't track state in that concept. We're just trying to automate aspects of what we're doing. But the ideal should be that we're not making any manual changes in our.50:11This is an exception to really simplify how we manage that kind of change process over time.50:31So, let me just open up here. So what we've seen so far is this plan, and so we're gonna assume that our plan was successful. And so I think in, I'll show you one of the examples in a second, but just to show you what a deployment kind of looks like essentially we we take the plan that we had from previously before and we're gonna apply it into our environment.50:38So this is a very simple demo. So essentially it's just telling us we you're able to apply it, we added these two devices that you asked for.50:57Sorry, two elements that you asked for, everything's ok. When you 1st do your deployment, it could be the case that this takes a long, long time. We we had an example with a customer that had a massive environment and they ran an unbelievable number of tests and it actually took like 13 h I think for the 1st deployment to run, right? But that's not normal. It's.51:04Essentially what we want is to do this fast, so it actually makes our life easier, though, the the difference which hopefully you kind of see as well is that all the other stages before deploy you would do before your change windows, so when we're not under so much time pressure, so we can run through a much larger set of testing if we need to, we can get a visualization over what's.51:24It's gonna happen at the very beginning also, and then we can then use that to try and help out on that, you know, 90 % of work, which isn't related to the actual deployment.51:44Okay, so some of the components which are important to know sorry. Okay, so when we were doing, I guess the initial kind of work and started work with ansible. I I know myself I started off and I I wasn't using roles and I created everything in very low.51:54Large hosts and group files in order to do that. And, you know, to be honest, that's a big pain. Like it's not nice even when you look at clis, you know, reading a 3000 line running configuration. And so what we do here is we separate out the configuration now into multiple elements. So we can logically segment the description of our input.52:14Structure in blocks that make sense to us. So in the example that we were looking at before, we had.52:34And we had different tenants, so we have e.g. here tenant A So this is a configuration that we have for for this tenant, a configuration here for tenant B, actually just looking at the contracts for these elements and then the rest of the configuration that exists for these. So when you're working in operations, the idea should be if you want to make a change to node one.52:41One oh one, you have a file here which contains all the information about one oh one but nothing else. We don't want to have that absolutely huge file there. And so the way this works is that we essentially compile all of the data files that you say you what we want we want to include into a big tree and then we can then apply those in a single go towards terraform.53:01So if I just show you, this is an example also. So we've talked about ACI, but I appreciate you guys might not all be working with ACI. So just to give you some other ones for SD WAN, e.g.. So here's a site configuration you could have within SD WAN, it's got all the site related data for this, of which you know, there's a lot of variables.53:22We're defining in this case and we we separate our our policies, our templates, in this way as well. So you have these logical blocks or containers when when we're looking at the different aspects, right? And then the same thing again, just to close off the points catalyst center, if that's where you're working at, same thing here, create all the different sites.53:42That's that we have, areas, buildings, all that kind of stuff, and then we might have separate descriptions for all of this as well.54:02So, one of the things that we also need to kind of think about also is not the, the files that we're looking at. So e.g. here when we're looking at the tenant name, so tenant name is in a protected field in most cases, it's gonna be a variable that we're very happy to have stored with inside of our.54:10Withinside of our logs I guess and withinside of our git repositories in this case, but there's gonna be some, e.g., things like passwords or you know kind of things that you want to be encrypted in this case and that you don't want to store in that context. So what we have here as an example is that we're able to use this placeholder here, this.54:29Dot sorry exclamation M to basically tell us that we want to insert those later on. And so we can either use a.m file if you're running some of these locally or in most cases what you're going to use are gonna be the CICD variables with inside of your workflow engine. So for us this is GitLab or you can also.54:48Also use other tools that you have with people like hashicorp as well. So essentially what we're trying to do in this context is saying try not to have all of your variables that are gonna be defined everywhere. We want to be as secure as we possibly can do, and I can show you exactly how that looks now. So.55:08I'll pop back to this pipeline. So if we have a look at the data for tenant A, what you see is an example at the very bottom here is that I've added another EBG, and so in this example, we're using the dollar and piece with insert for the the variable that exists for this.55:27And then when we go to look in the APIC, what you can actually see is that the EPG that's defined here is blank string, and that's because with inside GitLab what we have is the idea of saving some of these variables. So settings, CICD variables.55:47And you can see here I have this example bar. So this is what you usually use to contain, as I mentioned, those encrypted kind of credentials or any sensitive kind of information here and that gets inserted into the the job. But what would be.56:02A pain would be that if we could actually see that as part of our logs, we also don't want, you know, to show that either. And so what you can see as part of the deploy here is that we have a mask element, so actually in the logs we're not showing those as well. So once you start working on some of these things in production in order to maintain some element of security, we can do that insertion of variables into the mix as well.56:19Okay, so what we've kind of shown so far, as I mentioned, was that we've done the plan and the deployment, but the reality I think is a lot of anxiety around adopting some of these tools is, How have I screwed something up? Are we gonna break something when I actually deploy it? And so what we want to do also isn't just provide the provisioning aspect of things. It's also to provi.56:41Provide the elements of testing validation. And so to summarize it where we have different types of testing, you have pre change validation, which is where essentially what we're gonna look at there is.57:00It's what I'm proposing to change is it conformant to the right structure and doesn't meet the right criteria for my design? So e.g., does it use the right, I don't know, VLAN range or something like this or does it have the right name e.g. and I'll give you an example in a second.57:12And then post change validation. This is the one that gets quite broad, but ultimately it's split into two. The 1st one here that we're looking at is configuration. So has my configuration been successfully applied in my environment? We provide some free tools in order to do that. So you can go and have a look afterwards about NAC test and and we use NAC validate for elements of the pre change also.57:30Which are essentially wrappers around robot framework and pyats if you if you want to use that. So the the the crux of it here is that you want to build a suite of tests in order to validate the different changes that you want to make, but you don't want to have to build you know have some custom tool or be locked into some vendor in order.57:50To do that, so we've proposed basically using the open source tooling to do that job as well.58:10All of these group together as config validation, and then the the area that you see on the right is the one that is by far the most costly in terms of development time because you have lots of different systems you might want to start checking health. But as an example, if you finish your ACI change, you know, just to continue using that example, maybe you want to check to see.58:16If the all service in 365 is still reachable from, you know, two locations that you had. You want to kind of prove that there is NO impact to the applications.58:35Which exists on there. So we see quite a lot of examples around a thousand eyes in that case or if you're doing integrations with Splunk, you know, if you're getting a lot of alerts after a change, we want to try and build that into more of a feedback system so it's not just I've deployed a change, everything's ok. Cause part of this is also an operational piece. I I don't know about.58:45At you but I've been on changes before where there's a person from every representative on that change, whether it's storage and computer or whichever, we don't want to have to do that in automated changes. We want to build policy that allows us to, to make those intelligent decisions and then know that we haven't screwed something up.59:05So just as a really quick overview and definitions and then I'll show you an example. So syntax validation is essentially telling us that is what I've written conformance to what I should expect. And that's this is a tricky one, right? It's, it's one that when you start, it's the one thing that we screw up quite a lot as well. I know about 70 years ago when I was working on this.59:21Getting making sure that you were right had the right variables for particular keys was the paint sometimes? You know, is it true and false or yes or NO? You know, it's a what kind of structure do you want a IPv four address or do you want like full sided notation? It can get quite complicated, and so what we actually do is we want to leverage tools to make our lives a lot easi.59:41Easier in that respect.01:00:01So I'll show you the 1st one for syntax validation initially here. Let me just move my head so I can see what I'm doing. Okay, so in this context, we're gonna go back to looking at the ACI environment that we had and we're gonna look at just this tenant configuration as well. So I'm using in this case YAML lint, and it's just a basic.01:00:02Linter that's saying is the structure of the file ok? And it's looking at this, the files inside of this and says yes, it's alright, imagine you put a typo in here and we want to run this. We can pick these up really quite easily. What we don't want is to have these kind of issues when we go to apply the change because that's what delays is and makes it really quite difficult to work with. So we can.01:00:22Get rid of that and make it look ok. But maybe what you can kind of see.01:00:42At the bottom, if I don't screw this up, is you can see e.g. here this is a VLAN that's getting assigned essentially to this EPG. It says when you provision this EPG on this particular node, I want VLAN 3998. Now, we know that that's a valid VLAN.01:00:47If we add an additional two onto the end of it, we know it's not an additional VLAN, but if we look at our YAML linter when we run this particular text sorry there's a, there's a rule that says that you should have a line at the end of your YAML files, that's what it showed me. Now in this context it's saying everything's fine.01:01:03But when we deploy that within our environment, it's gonna screw up, right? Because we know that's not gonna be accepted. So what you'll see here at the end of this file name is.NAC.yaml. Now in this element basically we then have an extension with red Hat so that if you have this file format defined, we're also gonna test against a particular schema.01:01:23That we've produced. So when we scroll down now to this element, we can see actually well this VLAN, it needs to be between values one and 4096. And if you're a say this in love looking at Jason, you can actually go click onto this and this is the full populated schema for all of those different files available there. So Again.01:01:43Wanting to use AI, I use this quite a lot as a reference. If I wanted to kind of build configurations or build additional testing, I I can provide this into the context to.01:02:03To basically do it a bit smarter. So this is just a clear example here of where this would work. Now, when we go to the next step, after we've we're looking just at syntax, what we essentially want to do here is we want to start looking at semantic based validation, and so how can we actually make sure that the contents of the, the thing.01:02:15Things that we want to work on are gonna be ok. So in this context, what we can provide here is the schema that's and this these are this is optional, right? You know, we can have a schema. If we have a custom one that we want to specify, we can have rules which I'll touch on in a second, that basically says it's what I'm saying.01:02:35Synthetically correct, we've ticked off, but does it also makes sense? And so I'll show you what this example looks here. So in this context, what you're seeing are different rules. So there's custom ones created and we we provide them a services code. That's something that Cisco would do as part of a service engagement. But if you're starting this yourself, you can build your own rules and the ones I built today.01:02:53I used an agent in order to create those as well.01:03:13So just to pop back so you can see what the example is here. So if I have, this command, so we're using UV. It's just the, you know, the virtual environment that I'm going to use to run this in. I have some rules created. I want you to have a look at the this data folder here, I want you to use this schema and I want you to tell me what's going.01:03:16And you can see here that we've now got this syntax error that occurred. So actually the VLAN 399822 is wrong, you know, you, you've made a mistake there. And so if I go back and I fix that.01:03:37Let's give it a a valid one. So let's say 2000, right? So if we look here at this VLAN, we're conformant, right? We're conformant with the schema so far with 2000. But if I run this again, we're actually gonna get multiple errors that are gonna appear. And what it's gonna tell you is, is some more information about what we're doing. So this.01:03:48Should exist in this pool within this physical domain, you've specified that it's VLAN 2000, it's not reachable. So that gives us some context as to what's actually going on there. Why is it that VLAN 2000 isn't allowed? So within ACI we have the concept of VLAN pools. And VLAN pools basically are a range. They say you.01:04:09Now you can use VLANs from this this range, and within this VLAN pool of shared, we have two ranges, 3001 to 3010 and 3939 or 399399. And so we know that we've screwed up immediately or hopefully you know that because our two VLAN 2000 doesn't fit within that range at all.01:04:28And so what a nice thing it's done is with inside cursors, we've realized, ah.01:04:48You've just defined 2000 with inside that other file, maybe we need to create it within here as well. So in this context we're assuming that we want to add another VLAN into this pool. We run against our semantic checks and now we've passed. So it's the right syntax, it's gonna be accepted by ACI in most cases here it's.01:04:53Conformant with the rules that we've created as part of this, we're good to go.01:05:13So I'm actually gonna move this back to the correct one because it should be, what was it? 3998I think that was the one that we defined, right? 398 pull 9th. And then this should give me a different error.01:05:18No, ok, perfect. Good, good. Now, so just to be really clear syntax, semantic ticked off. All of these things, what we're trying to do is give people more confidence about what they're doing. It's not something that you can just pick up, it's not a product you can install. It's something that we're gonna build and expand over time. And so what we have in this case, I mentioned that could.01:05:33Before that 13 h is a progression through our kind of maturity with our automation tools.01:05:53They noticed at the very beginning and again they were working with professional services on this. I wasn't doing any work, but I loved the story about it. The the 1st one here was they noticed they needed to look at the agent. So I I think actually they optimized the Jenkins file as well as the overall install and they saved 3 h and you're like, Yeah nice, still takes 10 h, that's not acceptable, and you'll be.01:05:59You'll notice at the next stage what we've done here is the biggest improvement that we see is that it's gonna use a database in order to store that state file within terraform. So instead of just using the native one that we have, we're gonna use a more performance system in order to do this. So we're trying to optimize our implementation of Terraform.01:06:19The next stage after that is we can separate the state into logical chunks. So if you're using aci's example, you might want to have it so that you're just looking at a particular tenant or if you're doing SD WAN, you might want to look at a particular site. And I'll show you just another example of what this looks like.01:06:36Okay ok so this is a better example. Hopefully you can see this, ok. So in this example what we actually have is more of a production kind of style ready approach. And so what we've done here is we've created different GitHub projects.01:06:56Repositories for each of the different blocks that we've got. And so for each of the different types of configuration or chunks, we're gonna run those in different pipelines. That's really, really important because as you can imagine what happens is as your configuration grows, the size of the number of the objects you're working on grows also. And so you don't want to have to track all of those at the same time. If you're making a change.01:07:13To a particular site shouldn't really matter. We shouldn't have to calculate what's happening to a completely disconnected topic, right? So we can build scalability into our environments also so that we can try and be as performant as we can and avoid those 13 h, examples. And just to show you the actual data as an example here. So what we can do.01:07:33Is that in in this example we have 800 resources, we were making a change to one of the tenants and actually we only needed to be looking at I think it was 14 elements actually in this case. So it's really, really important to think about some of those things as well. If you're scaling up in automation that we're gonna have new processes which don't.01:07:54Take us more time, you know, we don't want, you know, people's lives to get worse as well. And then multiple phases here about customization of testing and how you want to do deployment, but you went from 13 h down to about 40 min. This was a full data center deployment, right? So we we can really kind of be a lot more performant if we try. So.01:08:13We talked a little bit actually about this point already, in terms of looking at YAML Lint and that validate with inside the GUI, but what does this look like with inside our environment as well? And hopefully as you kind of see, it's exactly the same.01:08:33You know, is that we're able to kind of run the same checks that we would want to in our environments, it's gonna produce the output that we need from an artifact perspective, which is a really, really important topic. I know it's really boring, but regulations for most of these cases is critical and being able to store the.01:08:49The decision making or the reasoning for the decision making for making a change is, is great. And so what we can do as part of each of these different jobs that we can kind of run is that we can store the output of the particular tests that we're running. So if we find, e.g., one that we failed validation on.01:09:08I think this one, yeah. And then have a little look at the files. All i've done is click through there at the same location. We can download the respective files that we have and in this case it's just a dumb example of our, you know, our single rule, but you could have like much more.01:09:26Things here where we're looking at operational health or, you know, everything you might want to have before a change today anyway.01:09:46I think I'm running a bit over on time, so I'll move forward to the next stage. So bringing it all together. So what we kind of showed you so far with two main elements, it was how do we do the deployments and how do we do the basic validation that exists to begin with? And what you'll see over time is, and if this is something that you're interested in.01:09:54You'll start to add more and more of those capabilities. We've tried to cover the the majority here. But e.g., if you want to use teams instead of Webex, you might, you're gonna have slightly different notification stages to people who are using different tools. And if you're gonna be using different infrastructure, you know, you're gonna have potentially slightly different stages also there.01:10:14One of the the ethos I kind of have is that we don't want to invent things which already are there. So if you have ACI and you all have Nexus Dashboard insights, you know, we should use Nexus Dashboard Insights in that case or in most cases. If we have catalyst center, we shouldn't be building new automation tools to do switch upgrades because it's already in there and it's really good. So.01:10:34That that's ultimately is what we want to try and do is build real functional operational processes that are gonna make our life a lot easier.01:10:54So, last little bit, the complexities you have with onboarding automation is very, very different depending on where you're starting from. If you haven't deployed a network, automation is, you know, substantially easier than what it was before. Because all we need to do is essentially describe the design that we want.01:11:01And then to be able to push that into our infra. As we have.01:11:21You know, more what we consider brownfield environments that can be, you know, very, very complex in terms of the operational side of things. Like how do you manage to change windows? E.g., if you want to kind of move to a fully automated approach, it's tough. And that's actually the main use case I see for people engaging with our services that team so they can do the brownfield.01:11:26Build imports to model the configuration that they want to be able to plan and test the actual deployment there. If you're Greenfield and you're starting this today, you might not need that support, right? You know, you might be able to do the deployment yourself and, and improve on how you do the implementation over time, right? So that's something just to consider. Automation shouldn't be so.01:11:46What can we do second? If we can do it 1st, our lives are much easier for the network designers as well as the automation engineers as well.01:12:06So choosing the path, there isn't a perfect approach. It matters a lot about what your, your current state is like do you want native if you're cloud oriented? Yeah, maybe that's a good approach. Do you want simple network and having to work on yourself or greenfield network as code might be a good solution or you know, is your environment quite complex or you want to do it quickly.01:12:13The services code could be a good solution for you and as well.01:12:33So, I've got two just to kind of cover on services code as I mentioned before is essentially just there to try and accelerate your adoption of automation. So can we do the creation of the testing? Can we help build the pipelines? Can we help, you know, maybe you want to update your design.01:12:37And then to be able to describe it in an automated manner and perhaps you need support over those elements as well. So that's essentially there to try and solve that problem, you know, helping that I guess or cover the gap while we figure out those tools. What we used to do, so I used to work in services in the past and it was quite common that you'd go and do a deployment and give a docus.01:12:54Documents, you know, saying this is what we've done and then you would leave and then you kind of left with the stuff and it's like, well, what do I do now? That isn't the case here. What we're really trying to do is focus on subscription based engagements. So you have someone integrated into the team in most cases and then you help train up people to understand how to use these different tools as well.01:13:14In coverage, very broad, I'd suggest you go look at the Nettis code to get the most up to date version, but we're trying to work across most of the Cisco portfolio as customer requirements come up. We're seeing I think quite a lot of interest in direct to device use cases as well, Whereas in the past it was predominantly controller based architectures, which, you know, are still the most popular approach.01:13:34But we're getting more and more of those direct engagements as well.01:13:53All the information here is documented in netascode.cisco.com. Please go and have a look at it if you want to look any more detail about how we implement some of those things. And there's also Webex community you can join and ask questions there. It'll be free to, you know, continue to ask questions in this Webex as I transition over to section.01:13:57Thank you Ed. Okay. Yeah, it's it's very, very hard to ignore the time saving that you can gain by introducing automation. And also besides that, if we look at the control that you gain.01:14:18Across the infrastructure, is something that is very important when we think about.01:14:38AI, right? Why? Because AI is in general, you know, like I mentioned at the beginning it's, it's a probabilistic machine. It will use probabilities to define the next token.01:14:45So that does not play well when we think about production, production networks, production systems, right? So what we need is to help AI focus. What we need is to give it the tools that will.01:15:02Enable it to select from those billions of parameters, the ones that will help achieve the task.01:15:22So basically we want to introduce more, more deterministic, more deterministing into the equation. So if we think about the journey, the goal is to introduce the standardization, right? The more.01:15:30Before we standardize, the better we create that abstraction layer, the easier it's going to be to interact interact with the underlying infrastructure. But then if we want to go towards autonomy then you know other things must must happen, right? So, and different custom.01:15:50Customers are in different stages. Some are, you know, the level zero, where.01:16:10You know, they still do manual operations, everything is controlled by, by an engineer everything is deployed by an engineer, everything is maintained by an engineer, of course, with a set of tools that they use. But then we go into assisted operations, right? Which is, which is level one.01:16:15I'm sorry yeah and in here we start including some some automation, right? We start playing with some of the tools that you know.01:16:35Not in a system way but pointed to specific parts of the the workflows that that you know an operator does on a daily basis. And some of the tools that actually maybe Ed has touched has done.01:16:48Then we move to level two when we start to expand the automation and the tool set, we start to trust it more, we gain better visibility, we start having things like GitLab and we start having configuration files consolidated in in one place to a single source of.01:17:08Truth we move forward and we start to go to level three where we have an automation that will run itself, but it will have different checkpoints and conditions that will gate right the execution or the implementation.01:17:28And then we go into the last two levels, which are the four and five where trust is really something that is very hard to gain or to create. Right. And this is where we, we start to go into introducing agents to offload a part of the.01:17:48Task that we do on a daily basis put them into a pipeline and make the agent responsible for that with us being able to keep an eye on it.01:18:08Or to, you know, to track it or to stop it and so on and so forth. And this is, you know, the moment where, it is very hard actually for a lot of teams, a lot of customers, right? To get to or to accept because then at level five is where.01:18:18Where, hey, we have run this automation for a while. We have an age agent that let's say it's taken care of that automation. We've supervised it, we've corrected it. It's been doing well, you know, for the past couple of months, and now we trust to let it run by itself and just check it from time, from time to time.01:18:38And that's where we go to level five, which is the fully autonomous autonomous system. Now, you might be in any of these stages, right? You might find yourself in any of the stages, you know, it's not that we can say like everyone it's at level three or everyone is at level two.01:18:58The question is, you know, how do we think about AI in all the stages, right? Is AI helping in level zero or level one? Is it helping in level two, three, is it only dedicated for level four and five? And the message is actually that, you know, it can be at all the levels at the end.01:19:17And the goal is to introduce the tool set.01:19:37That the AI needs to be able to, do the right thing. So to to become focused, to understand the environment, to understand the state of the environment, to get the right context, to be able to reason and take decisions and then.01:19:41Call the right tools to take actions, right? And that's where we start to introduce, you know, what we call a hardness for the AI. And actually the message for the session today.01:20:00Is that actually what you've seen there Ed demonstrating, right? The network is code. That is actually what is the base of the hardness that will allow you to start introducing AI at your own pace. So to create an agent, to introduce a model, to do the reasoning, in each of those stages.01:20:14Of, you know, of the framework of the network as code framework until the point where you get where you can have an agentic system or a single agent, it's your choice, how you wanna, you wanna go about it that will actually leverage all these tools that are part of network as code and be able to.01:20:34Conversationally.01:20:55Implement test, deploy verify, you know, whatever action you want to do. So if, if we are to look at it and actually understand the difference into introducing a tool or using an LLM.01:20:57Wildly like or giving it a number of tools we put together like a couple of quick demos. Let me see, I have 10 min to go. So, we put together like two or three demos where we have a simple lab with this is on premise.01:21:17Where there is like a python agent, it's gonna use Jima four, it's actually not 12 billion, it's gonna use 26 billion.01:21:37But 12 min can be used as well. The important part is to be capable of functions of tool calling. And then we we have built like a very basic MCP server that is capable to connect to a virtual router, which is.01:21:45Is actually sitting into a Cisco modeling lab environment. So this is gonna be the 1st use case. 2nd use case is gonna be where we use the MCP server that is built for CML and has been made available I think since two eight version two eight or two nine.01:22:04And, basically we are doing the integration between the the same agent, the.01:22:25Same LLM model and then going into and leveraging the the pre built tools. There are around 50 tools that are published and available for for Cisco modeling labs. The 3rd use case is gonna be focusing on, adding terraform.01:22:32It's not the official Terraform MCP, it is using Terraform CLI, but we have defined a number of tools that leverage Terraform to actually deploy a, in CML again.01:22:52So we're gonna use both MCP servers with the same AI setup to deploy like a very small lab with two routers and a concentrator switch and then the connectivity to to the internet.01:23:08Okay, so the goal with this three is to show how much of a difference a tool makes when it is given to, to an AI. So what I'm gonna do here is I have the three agents which are started, right? So I have the 1st agent which only has the LLM.01:23:25I already run this prompt because it takes a bit to kind of process the server I have at hand, it's not extremely powerful. So basically we're using this model. What I did, I asked what is the version of my Cisco router. So what the router or sorry, what the NNM would do, what the agent would do.01:23:44Is well, it will provide like a very generic answer, right? So you use method one in specifically for a Cisco router, use enabled, you do show version and then you look for for the version. Then you can do better two method three. So this is a very generic generic answer, right? Why? Because it does not have a direct.01:24:02Access to the network, right?01:24:23So what we can do is to actually introduce that in the form of an MCP server. This is a standardized way to communicate between agents and different systems, and basically how that looks like is if we look up the MCP server in here.01:24:25Here, what we do is we de define the tools as a Python function and the tool itself is built out of an action, right? That comes from a Python library and then a prompt.01:24:45Right, we call it here a description. It's a block text, but at the most basic it's a basic level it it has these two components, right? This description in here or prompt serves the agent.01:25:01By describing what this specific tool does, ok? So now what we, what we're gonna do is gonna actually run this agent, the agent is gonna say that, hey, I've loaded these tools right now, so I've loaded the the.01:25:19The MCP server, I'm connected to the MCP server and I have access to the specific tools, right? So we can see them in here CLI config, CLI show commands.01:25:39And then ping, right? What we can do now is to basically ask the same question. What is the version? Sorry, my version of my router.01:25:49In this case it will it it is connecting only to a single router out of the, the entire out of the entire lab that I have in Cisco modeling lab, so it's a virtual router. So you can see here that instead of giving us this entire blob.01:26:05It became extremely focused. It knew that it has a tool. It knew that it reasoned that it needs to use this command and then it ran the command and came back, this is the version running on this specific router, right? So just by adding a very simple tool that helps focus the model, and it.01:26:22You can do this with other models as well, right? As long as it's a model that's capable of tool calling.01:26:42It will make the AI much more, much more useful to us, ok? And of course we can continue, you know, we can use the other tools like configure a description, or use ping, but in the interest of time, I'm gonna move to the to the 3rd scenario.01:26:48So in the 3rd scenario, actually let me let me exit here so we can also free the resources. In the 3rd scenario, this is where we have the MCP server for Cisco modeling labs and then the MCP server that we have built for.01:27:06Terraform to to leverage terraform, right? So we're gonna load this. This is gonna load multiple tools, right? So we have two servers accessible, so we have the CML, the Cisco modeling labs, and then we have the terraform CLM, and this is a list with all the tools that the model has, has access to.01:27:29And what we're gonna do is we gonna ask it to provision.01:27:49A, a lab starting from a template, right? So I have two predefined templates that you can see they are put in here. One it's capable of importing YAML based on a YAML file the configuration of a lab and deployed and the other one is capable of.01:27:55Creating from scratch, the lab itself. Now, what's the difference between this tool, the tools that we're using right now, and the tools that we've been using in the previous use case?01:28:15The difference is that in the previous use case, we used to have only the description and then the action, right? What we're introducing, so we call it like a block text. What we are doing in, in here, the tools that we are using, they also have an input schema. An input schema which.01:28:26Which helps the, the AI agent to be extremely focused so to really understand what are the exact settings that it needs to provide or gather or collect before creating creating, before.01:28:46Executing the the action. So in this case.01:29:07Let's see what happened, right? So, plan, we said we plan and then apply the new lab template to provision the lab, right? So it used this tool to do a terraform in it then it did a terraform validation and then.01:29:12It it it created a plan, right? So all of this is to make sure that the configuration that we have is valid and functional, right? So everything that Ed touched with during his presentation where we have the the predefined best practice framework that is part of network as code.01:29:30Right, we can also do do in here specifically, right?01:29:50So and combining that with the, with the AI model, we are able to properly focus it and have this executed in a conversational way, right? So he has said that I successfully planned the provision of the new lab using the defined template, right? So.01:29:57So now this is the summary of what is going to be deployed, so you have ten resources and we have the following names, the links will be created and it will start the lab once this is this is done. So we can say apply, right? And actually, you know, I have a prompt.01:30:17But let's be creative and let's actually say this. Apply. Let's see if that, that would actually work.01:30:37Yeah, I know we are time, sorry about that. I'll just continue with this demo just to get it, just to get it finished and then we're gonna close the session. I just need three, 4 min.01:30:46More. So now if we have a look in here.01:31:06The lab has been provisioned and we can see it in in here. The nodes are booting up, everything is up and running. So it's gonna take a couple of seconds for the routers to to also boot up and be available.01:31:10Okay, then at the end, what we wanna do also is to leverage another tool and basically destroy destroy the lab, right? So we want to see that in action as well. We're gonna let it.01:31:32Let's see if it's up. Okay ok so what we can do is because we have the other, MCP server, so for CML, we can ask it, give me a list of.01:31:51The active labs and the notes. So what we will do it will listen what it needs, it will discover that it needs to run this specific tool from the CML MCP toolset.01:32:06Together with the one that helps get the notes and it's gonna provide us with the information about this, these labs. Another thing that we can do is to do the same. It's not gonna work exactly the same, but we can say what version.01:32:26Are the iOS XE routers in lab are running, ok? So now it NO longer has the MCP that the the simple MCP that we built in the 1st example is gonna.01:32:46Actually use the MCP tools for Cisco modeling labs and it's gonna go and query the notes. Right now it doesn't necessarily know the which one is around because this is a virtual environment. So it's gonna also touch on the terminal servers, so.01:33:06So basically on the external connector and the management the unmanaged hub that we're using for the connection, but it's gonna come back only the version with the version from the two I/O 60 routers. Why? Because that's where he's gonna use the the Cisco CLI commands.01:33:26Okay, now we want to destroy this just to show oops, not this one, ok.01:33:46Oh, Destroy lab. Okay, and what he's gonna do is gonna just again use the same MCP tools and it's gonna stop this lab, and then it's going to basically delete it and remove the results.01:34:02Or freedom resources. So what, what we have done.01:34:22So he's asking me if I am sure because this is gonna be permanently this destroyed. Okay, so in the interest of time I'm gonna I'm gonna stop there. Basically I can confirm and it's gonna go and and free the resources.01:34:30So the message here is, if we can do, if we can get the AI agent more focused just with these simple tools, imagine if you connected or if you create, if you start building the harness for the AI.01:34:48By leveraging what Ed has demonstrated, what, what is already part of the network as called framework. The possibilities that basically would allow you to leverage an AI agent at each of these levels regardless where you are in your journey, right? You'll be able to introduce and stop.01:35:05Playing with this either if it's just at the inter interrogation level where you extract information, you know, you get some kind of reports or even maybe you want to do some changes or generate some some tests some test data. So with that I'm gonna just leave it there.01:35:25Just say thank you for joining us. Thank you for your, for your time. I hope this session was useful. We will have follow UPS as part of the network as code enablement sessions. Next one will be on SD one as code. I've seen someone in the chat asking for a.01:35:45So we're gonna consider that for, for the follow up sessions. And we already have three sessions that are scheduled for for September.01:36:06So, yeah, stay stay connected. Ed, thank you very much. Thank you very much for your help and everyone please have a good day.01:36:16