Cisco Network as Code: Intelligent Decision Making

Oh, Hello, so today we have another series in part of our expert insight series. It's 2nd.00:00And, iteration of sessions focused on network as code. We already had three sessions in the summer. Feel free to, you know, go back if there are some things that maybe are not extremely work clear for you or you feel like you would like to to go deeper.00:20Now we've treated some concepts in the other sessions, very nice demos, and they are available on the community on the community pages. So today we are starting a series of three every Tuesday this hour for the name.00:39Next to this week and the next two weeks, we're gonna have three topics. The 1st topic is focused on the link between the infrastructure and the business services. 2nd session is gonna focus on how do you make.00:59Use cases reusable and easy to access, easy to implement. So that's what we call a self service portal. And then the 3rd one, it's gonna focus on AI and network infrastructure AI for network infrastructure. What is the role of the tools and.01:19Everything that we have as part of network as code framework, how does that fit into an AI implementation? How does that help? How does that maybe enhance or collaborate with the AI tools? So without delaying it more, let's kick it off for the session today.01:40My name is. I'm a customer success specialist. I'm part of the adoption team at Cisco. Together with me, I have Edmore and David who are both part of, we are all part of the same team, and.02:01And we are focusing on different parts of of the portfolio and our role is to work with, you know, our customers, with our partners, and help them adopt the products that they have invested in, the solutions that they have invested in with, with Cisco. So we run sessions.02:21Like this more personalized, this is a more generic session, but we also run sessions more personalized for different customers focusing on specific specific use cases with the goal to introduce new features, new capabilities, existing features, you know, understanding.02:41If the use cases that they have considered the beginning of the investment are being addressed or if there is something that is needed.03:01So for today's session, yeah, yeah, thank you. I think I'll kindly ask my colleagues if possible to share the link. So, ok, so the focus for today again is about the, the link between.03:11In, you know, it's the network when a challenge arises and then the fact that the network is ok, but the service is down, ok? So, sometimes.03:30The tools that we use, tell us the story that the infrastructure is ok. And this is not just for the network, right? It's in general. But still with that, you know, the services that the customers of your businesses, you know, our businesses.03:46The the tools that our customers consume, they are not performing as they should or maybe they are not even even available. And in order for that to be able to merge into a full picture correlation is very important or a lot of tools to work together.04:06Seamlessly, is a criteria. So, in, in that regard today we're gonna recap some of the, you know, network as code concepts that, are relevant, you know, for the rest of the session and then 2nd part we're gonna look into a.04:27A simple scenario, but that can be very relevant for quite a few, quite a few customers, and it can come in different forms, but, and it can in just a simple command and and the focus is on the fact that just.04:46Just with a simple command, even if let's say the infrastructure still.05:06Continues to function within parameters the the surface still can get can get impacted. And the lack of visibility does not raise red flags, right? For, for the IT department, e.g., to be aware of. So when I think about network.05:12This code.05:32Excuse me. When I think about network as code, I think a bit of, of languages. So e.g. in this call, you know me and my colleagues, we each sit at different countries as well as yourself, you sit in different countries you have.05:35Your cultures, you have, you know, local languages, and in, in this specific session, you know, we have a standard that we use to be able to to understand each other and be able to communicate and, you know, draw conclusions and and that standard is actually the English language, right? So for.05:55This specific call, the English language is the is the standard. That is in big lines what network is called and infrastructure as called, you know, the bigger umbrella as an industrial term is aiming to achieve a, a way to be able to take the state of.06:15The infrastructure and put it into a format that can be easily moved, that is standardized, that is reliable, and that can be easily tracked and, you know, used for deployments, ok? So.06:35That for me makes it a bit more easier to kind of think about why would I want to even start on a journey when it comes to network as code. So if we look at the foundational capabilities, that means that.06:50You know, what we are interested in is, you know, to be able to collaborate like in this meeting, right? To be able to be more productive and have a a simple way of communication, to introduce compliance and reduce, you know, our.07:05A misunderstandings, e.g., right? Because we do use a standardized way of communication, you know, the words are put in different, in a in a specific way the phrases are built in a specific way, right? So we introduce a standardization and this creates predictability and this lowers the chances of having.07:22You know, issues or errors during the implementation or changes, right? If you think about the change management. Also, it provides us a way because we take.07:42In the case of, you know, network as code infrastructure as code, we take a static state of the networks or configuration of a device and we port it into a file, right? Which makes, which allows us to use tools that create flexibility, right? And this allows us to.07:52To when we implement fixes to get a better view of the network and the impact of those fixes, right? So you think, think about upgrade, think about fixes for different security different security fixes that we have to react extremely fast too, right? Especially now.08:12Now in this in this moment and in this world where AI is just generating code you know, extremely fast and extremely cheap.08:32And then at the end it's about the availability, right? So the foundational capabilities, they are kind of the same when we think about anything that, that we do. The question is how the flexibility that network as a code brings and how the standardization actually contributes for us to be able to easier to to make to achieve the.08:41In an easier in an easier manner and more trackable, in a more trackable trackable manner.09:01If we think about the architecture, let me build this entire slide, the way it looks like today, from the perspective of network as code is it starts with, with the infrastructure, right? And Cisco has been investing time and resources for the.09:09Last several years to create and implement programmability features and capabilities across all our operating systems, you know, depending on the domains, you know, the data center, the campus, the, the one infrastructure, the industrial environment.09:27You name it and we haven't implemented and introduced all these capabilities that are the foundation that enables other tools to introduce abstraction, right? So, right here if we are to go and to communicate with each of these.09:44Of these domains, the infrastructure in each of these domains, we mainly use CLI or we use some other tools that leverage templates and and in order to configure it, to modify it right to follow that change management cycle.10:04Now, what we are doing with network as code, we're introducing a number of tools that is being used in in the cloud world that is being used in, in the developers environments, tools that create and generate a level of of abstraction.10:20Production, right? They leverage, they build on top of, let's say APIs, e.g., that are available in on the on the inside the the infrastructure.10:40And they enable us to create the same configuration that we have on the specific devices or on the infrastructure into a file. And that file is something that we can store. It's something that we can version and then it's something that we can implement. And.10:51This is what we do with, tools like GitLab and GitHub when it comes to versioning and having a single source of truth for the state of the infrastructure.11:11And then leveraging engines like Ansible Terraform or opentoffer or others to basically configure the infrastructure, provision the infrastructure, drive change, you know, react to, different challenges, even.11:22Track the state state of the network.11:43On the right, we talk about the observability. So we talk about the ability to be able to track everything that is going into end and to integrate with the infrastructure itself, but also with the newer tools and have a collaboration that allows us to draw a conclusion can.11:46My customers actually check out, you know, whatever they want to buy and pay for it, right? So this is where we gain that understanding, we gain the cap the capability to consolidate all the data and telemetry that the infrastructure generates, but also, you know.12:06The Automation tools.12:26Automation tools generate. If we continue then we have another layer which is the layer of orchestration here we were going further up thinking from a business perspective and thinking, you know, how do we want to, to have the entire change.12:29Or how do you want to have like the entire provisioning provisioning cycle of a specific service, thinking about multi domains when it comes to the IT infrastructure and and not only. And this is enabled by the ability to leverage again the standardization, right? The standard for.12:49Part of the the way we store the infrastructure state and configuration. You think about the YAML Json and so on. And then also the means to access it, which are the the APIs. NAC API stands for network as code, APIs. This has been.13:09Developed by our services organization, about Cisco services, Cisco CX organization.13:29And it's basically another abstraction layer, that simplifies even further the way you have to create the confi the configuration of your of your infrastructure. And there are a dedicated sessions for this one. I highly encourage you to to go to those sessions being them.13:35You know, webinars like this or if you, if you are at Cisco Live to go and attend them. They are a significant time saver.13:55And it's something that you can talk and implement by collaborating with with our services organization. And then at the top we have the catalog, right? So here's where we think about.14:04How do, the other organizations in the in the company consume this new automations that we have put put in place? So think about your app store, right? But that's what we think about when we say self service and this is going to be the focus for next session next week.14:21How do we, how do we think about AI, right? How do we think about, what's the value that network as code is bringing to the AI tools and the way we are starting to incorporate AI into, you know, our workflows, our day to day activity and work?14:41And our day to day, you know, activities that we do to to maintain the, the network and the infrastructure.15:00So this is like a recap for network as code. Again, very important standardization means of communication, you know, think about languages, think about the way we interact and how beneficial is that for us? How much it's improving our productivity, how much is helping us, you know, have a good time.15:07What we what we do that. If we have to talk about, you know, the abstraction layers, right? Just to give you like a an example.15:28This is, so if we are to think about using, e.g., Terraform as the automation engine, right, to, deploy or to modify configuration on specific parts of the infrastructure. This on the left, this is what would, this is how it would look.15:37You know, for a configuration, these are all the options, you know, think about the features that you configure, e.g. over CLI if you are part of, you know, if you are a network engineer and the way you activate them, you know all these features you have them in your head or you find them in the documentation, it's the same. They're all ported in here and key value pairs and you can act.15:58Activate them or deactivate them. But this for those that are new to this domain feels like a very high barrier of entry, right? It becomes more complicated, you know, there is more to learn to be able to use the raw way of configuring or creating.16:17Configuration file for Terraform to be able to use it and, you know, do the automation behind the lines. So with network as code, what Cisco has done has invested into creating, you know, the providers for Terraform or playbooks for ansible. These are public, you can find them on their respective repository.16:37And what it does is it takes, you know, the need to create something like this and it ports it into something much more clean and much more, much more simple.16:58And easier to read, this is you know a configuration for a core switch where we put the VLANs, you know, we put the IP addresses with somebody and so on by the default gateway. So you can see like instead of having to type all of this and trying to understand, you know, the format and everything, then.17:10But this can be configured very easily through a much more simplified way by leveraging you know network network as code.17:30We have the same for each of the domains, right? So we have providers for each of the domains, and here we have, we see Nexus, we see the identity services engine, NXOS when it comes to infrastructure in the data center.17:37Now one important thing is, you can see in here in the network infrastructure, right? We have, you know, the devices themselves represented by their operating system, but we also have something like catalyst center, we have SD one, we have, you know, ACI, and the idea is.17:52He is.18:12Configuration of the network can be done in these tools as well, right? There is simplification that is added in there. Templating, you know, workflows built in workflows that help you configure infrastructure or parts of the infrastructure, redeployment, upgrades, all those.18:14Those capabilities are already in those tools, right? So.18:33The way we looked at this from a network scope perspective was that to say like, ok, you NO longer need those tools or you've invested time in the past two years to put those, you know, tools and create your workflows and standardized the way you operate. Now you need to move everything in here. No, you, if you have.18:38Already something that you're happy with and it works well and it's proven, right? And it's, you know, battle proven, then you can use the same.18:58The same capabilities that you would use to go directly to the device to configure and interact through those controllers, right? In the case of Catalyst Center, e.g., right? So you can leverage the APIs that Catalyst Center has or you know any of the other controllers.19:09The newer capabilities even if we think about modern context protocol like MCPs and so on, ok? So this is not about, you know, replacing all your management on the tools that you have. This is about giving you the flexibility to choose or to take the path or to use both at the same, at the same time.19:29Okay, so if we think about, you know, how would this be used? So the idea is because now we have, you know, you know, we have the state of the network into configuration files or into files standardized files, we need to have like a place where we.19:47For them, right? And this in this case and in this example, you know, we have GitLab that would, that's the the 1st that would be the 1st.20:07Step let's say into a pipeline. So this is a pipeline. This is how you would execute, e.g., a change, a change process, right? So the way you would start is, you know, you have your source of truth repository which knows the way the network it should be and that.20:17It's in GitLab, any change that is being done is NO longer done on the device directly, any change that is being done will be done in here, right? And in there it will get versioning, meaning that you can use capabilities like Git to create versions of the same file and then if needed you can go.20:37Back to the previous version or previous two versions in case there was something that went terribly wrong or you just want to like revert because of change, you've re introduced an older device back into, into the network. You want to have like the the previous configuration.20:57State, ok? So that's what we mean about single source of truth. So this is where you interact. This is going to be like the main place where you would manage the configuration. Then, then we think about, ok, we want to drive the change. So in order to drive the change.21:16If you go on CLI, e.g., and you implement something.21:36You rely on the knowledge and experience of that one person, yeah? If there is a mistake, then there is a mistake and it needs to be fixed either remotely or you have to go physically and, and fix it. If there is NO mistake, then it's ok.21:40Then, you know, you continue on the change on the change cycle. Now when it the advantage when we have the state outside is that we can do prechecks, right? So what we can do is, you know, based on the learnings, based on the experience, based on the different scenarios that we know might have.22:00Based on the documentation, e.g., when it comes to.22:22The structure of a command, the structure of a block of commands, the structure of a specific feature activation, we can, we can implement an automatic pre, pre change validation, right? So, in that way we avoid, e.g..22:29You're not following the structure that Terraform asks for or the structure that YAML desires, right? When, when you execute something source from a YAML file or the command that you are sending it's incomplete or is just missing one character or there is an exe.22:49Extra space or is it lacking a space, right? So this type of errors that could just.23:09You know, prevent you to properly use the change window that you have, right? That you have available. So all those can be implemented. We have a tool which is called NAC validate. This is a CLI tool. It was built.23:16By Cisco and for the Cisco devices, it will do all those prechecks for you, right? And from the perspective of network as code. So it will help you surface all those and avoid the problems. Then we move forward and then we think about, ok, we have the change.23:34I want to understand the state of my network right now. I want to know, you know, where I'm starting from and this is where observability comes into place. You know, we, you think about tools like Splank, think about tools like AppDynamics, think about tools like thousand eyes that allow you to gain visibility into, you know, the infrastructure, but also.23:54So hey, the service was up, it was running, these are the parameters, you know, or generate a test leveraging thousand eyes to understand the parameters in which the specific link, is performing at that point in time. Once all these three or two stages, right, the, the pre change value.24:14And then the understanding of the state of the network we move to the implementation. And we think about, ok, these are the changes that we want to do. This is the engine that we're gonna use in this case it's terraform. And we're gonna do the implementation on one device multiple devices.24:34Is, you know, across domains. Yeah. This is all being defined in you know the file that is going to be used, right? The desired state. Once the implementation has been done.24:54Then we want to understand, hey, is the network running in the same parameters? This is what, where we come back to the observability tools, this is gonna tell us, hey, the impact of the change, you know, is, are the services developed right is the network still functioning? Are the, is the.25:07It infrastructure that was part of the change still functioning within within parameters. And this is where usually there is a disconnect, right? Because mainly the tools depending on the different parts of the IT organization, each has its own tools and whenever there is a change, you know, they can very easily.25:27Understand and accurately understand, you know, the impact on that portion of the IT infrastructure, right? So the network is functioning within parameters, but the visibility towards, you know, the.25:47The the services that run on top of the network, e.g., it's not always, as easy to understand or keep an eye, keep an eye on, and that's where observability tools can, can really help, and we will see in the demo.26:03At the end, we can implement the testing module, a testing module that runs a number of tests that you would do anyway, whenever you would do a change. You know, before you do a change, you think about all the scenarios that would go wrong and you try to then perform all the checks or, you know, check.26:22For the boxes and make sure that everything that's important is still running, that can be go, that can go inside you know a testing module that will perform that for you automatically, you know, leveraging the problem programmability capabilities that are built within the, within the infrastructure.26:41There is a dedicated module as well, you know, the test, that you have details on network as code if you want to understand this is something that Cisco has invested in and you can.27:02You can leverage it as, you know, a base or you can evolve it in a way where you can you can have your own tests divided. Then at the end, you know, the idea is how do you interact? How do you stay up to date? And of course in the pipeline, in any stage of this pipeline, you can insert an integration.27:17With your collaboration tools, think about, you know, teams. Think about Webex.27:37Where you can get notifications on the fly depending on each stage of of this pipeline. So this is in a way in big pick in big lines, this is a way of thinking about, you know, how the pipeline should look like, how the change life cycle or how the change.27:44Which, process should be divided and which how what are the different gates, right? That we want the process to go through so we can minimize the challenges or the issues and make sure that we have a successful change implemented.28:04Or, you know, upgrade or whatever you are planning to do at that point in time.28:24So what I'm gonna focus on is the pre change validation a bit. So the demo it's going to not focus on the entire pipeline in here, the demo is gonna focus on.28:31Versioning, so more specifically building up not building using a pipeline, the pipeline is already built in GitLab then we gonna leverage, you know, inside that pipeline next validate it's gonna be used to make sure that the command that we're sending right.28:48The change that we're sending is within parameters it's it's correct 1st of all, but then also to make sure that it does not have other impact that we know or we know of. Then we're gonna have a look in Splunk enterprise. By the way.29:08Doing this all set up for this stuff, for this demo is on premise. So we're gonna have a look at Splank enterprise, where we, where I built where we have like a dashboard that just monitors you know the the three main services hypothetical services of this you know virtual company.29:28And the entire pipeline is going to use terraform, you know, to implement or to fix, some of some of the changes and then we're gonna go back into Splunk and we're gonna see that, you know, the services came up. What is not in this is I am not using NAT tests. That is gonna go for.29:48You know another session because, you know, it deserves a bit more attention.30:08But, and then at the end, you know, we also have I have the integration with Webex where we gonna get a notification in case, you know, there is something that is going wrong. So one of the scenarios is gonna be about going wrong. Okay? So just to be lines to map it to you know the the.30:16Pipeline that we've discussed right now and just to give you kind of a heads up on what the demo is going to be focusing on.30:34When we think about the pre change validation, just to spend a couple of minutes on this, we think about, again, like I already mentioned about the format, about the syntax, like the formatting that is needed you know you need to have two spaces, you need to use accolades, you need to use brackets, you need to close them, you know, all things like that.30:43About the the syntax, you know, the way we structure the code, the blocks inside the code, the blocks inside the YAML file for Terraform and for the other tools. We think about the semantic, you know, is there like, are there any.31:03Impacts other impacts, you know, that this change could generate and then about compliance and compliance here, think about, you know, do I have any critical.31:22Side effects that might happen if someone is using, you know, this command or if someone is is doing this specific procedure, ok? And that can be captured into a test that can be leveraged as part of NAC validate.31:37As a check mark or a checkpoint, and also a block stage in case, you know, the, the user is not using properly, you know, that specific command or that specific block of commands right change they wanna do. So if it's the again.31:57It's a CLI tool. It's built by Cisco, it's public. And you just to show in here, you know, we have different options. What I'm gonna, what I am, what we have today inside the demo, we have a schema file and then a rules file. So this is what it's, it's going to be used.32:17To prevent a very basic problem, right? But that can have critical impact on on the business business services. Yeah, this is the syntax validation, right? So basically, you know, we're gonna go the the module goes.32:37Through that and make sure that make sure that you know you've closed the parenthesis, make sure that you don't have extra words in the main commands or the main keys and so on.32:57Okay, so just to wrap it up on this section, three things, right? With network as code, we think about standards, we think about flexibility.33:11What we do is we write into files the state of the network that we want to get to. And then we use a tool, an automation tool to to implement it.33:28Or to revert from it and we check before and after, right? So these are like the three main concepts that network as code helps us to consistently introduce for each of the, of the change cycles. Now let's go with the, the demo.33:46So what I have in here is in Git, so this is gonna be very simple. Actually let me go into where is it? Here we go. So.34:07Let me make this bigger, ok. So just to show you this is the lab, it's a very simple lab, what we have, we have a router in here which is the gateway, we have a distribution switch and access switch so we are in the realm of iOS.34:23So campus, and then we have three services in here, check out you know the employees the employees network and then the IoT network which you know can be age back systems if it's a building or it can be, you know.34:43Processes and machinery inside a factory. Each of this has their own VLAN. The change that that a junior engineer, let's say, is asked to do is very simple, and that is to add a VLAN, a v.35:02Now there are two ways, right? I mean it it can be very misleading if you don't have the experience or if you don't know, you know exactly how to configure VLANs on iOS XE devices. Just missing one word can get to a.35:24Point where all the VLANs are being deleted, which means a critical issue because all the services will go down or a big part of those services will will go down. And that change is just because.35:42Let me go let me take this away, and that changes just because just because one single word, so the word add, ok? So if we run the command like this, basically it will replace all the VLANs.35:59If we run the command like this, basically it will extend the list of VLANs, right? It will add an extra VLAN. What we are doing in here is in Git, in our repository, in our source source of truth, we have the defined state of the network as it is right now, right? So the network right now.36:19Has these VLANs already configured, our services are working, our customers are happy, they can buy stuff from us. Someone comes in and they have to add a VLAN, right? It can be VLAN 30, it can be VLAN 40, it doesn't matter. I'm using VLAN 30 because I want to keep one of the services up.36:39You know, from a visibility, from observability perspective, ok? Once they go and they test this sorry they send this command, right? Then, the result will be that on that specific link, we are basically deleting these two.36:58Meaning that we're impacting two services, right? Okay, so let's do that. Where am I go. So this is my distribution switch. I already have my CLI, ok.37:17We're gonna go on the interface one oh one which is the uplink ok let's see, do I still have it? No, not trunk.37:38Yeah, come on.38:03So you can see how many, you know, mistakes I can make or, you know, the time that it takes. So now I can save VLAN 30 directly, ok? Sorry, and when I press this.38:12Basically it's gonna remove the other one as you can see already we have some changes, ok? So do show in a brief just to have a quick look, right? Yeah, we still have it active, but they will they will drop.38:29Okay, let's go to, as you can see the network says you know still everything it's in green in our and this is by the way, this is Cisco modeling labs, right? So this is a virtual virtual lab.38:53Now let's go refresh this there we go, so we can see now this has dropped, ok? These two services have dropped because our VLAN has disappeared.39:08And the 3rd service which runs on 30 is still active is still functioning. Of course, in Splunk you can go and, you know, further further investigate, you know, by doing different queries and searches, and this can be a much more evolved dashboard, but for the purpose of today's demo.39:27We just want to see, hey, can my customers still buy stuff? Can my employees still operate and do their day to day job? For the moment, fortunately, you know, the, the factory is still still functioning. So.39:47Now, the the idea is from a network perspective, everything works, right? So we do a change, this is very basic, like extremely basic, I'm even embarrassed how basic it is, but it can, it can have a really big impact, right? If you think about it. So right now from a network perspective, from the network.40:04For tools perspective things still work, right? We might have different other tools that help us understand from an insurance perspective, you know, if those services are down, but, it is not extremely easy to make the correlation or it is not the 1st thing that maybe we think about. However, because.40:24If we have the integration and we have the visibility into the observability tool, we can immediately see that, you know, this has happened. However.40:44Getting notified about it, you know, it depends on how this system is this is is configured, right? So it will take some time, maybe some customers will start to complain, you know, that would have an impact on, you know, the experience, the customer experience. At the end, you know, the cycle might be longer.40:54For shorter, to feed for the feedback to come back and just go back into the CLI and, you know, and add those those VLANs back the right place, right? Now, what we can do.41:14If we we have this already the state of the network in, inside the in inside GitLab in our case, right? Now what we can do is to leverage a pipeline that can immediately correct something like this, right? And.41:30In this case I have in here a pipeline which is built, and we're gonna run it so it has five stages in it.41:50I'm just gonna run it ok now call it a new pipeline. I'm just gonna start. What this pipeline does is basically taking the network.42:00And going back to a predefined state, right? So this is the state of that specific switch, right? So this switch has, these VLANs which are.42:17Configured on it, ok? So what we're doing now, we're doing kind of a rollback. So let's go back to the pipeline. I see we went through the 1st stage.42:33The validation stage, 2nd stage, what I'm I have been implemented in here is, a way for this pipeline to be used to maybe introduce new VLANs into the network, right? And make sure that it is done properly with the right.42:48Man inside the 1st stage we are I'm using NAC validate to make sure that we limit.43:09To the add command when we want to add a VLAN to a specific trunk and it has a rule which says that if, someone needs to if it's using the command without add, so basically it wants to remove a VLAN, then that.43:20That needs a confirmation it needs to go to someone to validate it, right? So in this case this is what I'm doing. So I'm gonna say apply.43:40Because this is the correct one. So the the the the pipeline is built with two scopes, right? One is to recover for something like this real quick and the other one is if we want to introduce something new, e.g., we have junior or interns that, you know, we want to give them this task, then they can easily go and and leverage.43:49A flow like this to to add what is what is needed. Right now I see that the verifying stage failed, ok? Doesn't matter, let's see just refresh.44:09Let's give you the time we can see now the service is back up, so the VLANs have been added, ok? So we we we have a functioning functioning state, ok? The other thing that we can see is, you know.44:27This was applied, so we have pipeline 18. Let's see, is it this one? Yes, we have pipeline 18. Pipeline 18 was run. It was applied, right? So the stage that I mentioned it was successful, and the user that did this in this case is.44:45User. And what it was done, it was, you know, this specific VLANs were configured on the device itself. Now, if we go back to the device itself, we can already see.45:05You know, some output on the CLI is that it was we had configuration over netconf. And then we can see the command. Okay.45:19This was detected, netconf. Let's see, do we have the VLANs? Show VLAN brief ok show.45:36Okay come on. There you go. And we can see we have the three VLANs, ok? So what it did.45:53Did GitLab so terraform, what it did, it actually used the same command, but it included all the VLANs, ok? It can be configured to use, you know, add as well as a command. You know, the command that includes add as well but in this case we needed to go back to the state.46:13The exact state, so everything that was in there needed to be overwritten, right? Maybe there was a VLAN that should not be allowed on that specific trunk so we don't want to have, we want to go back to a known trusted state.46:33Okay. Good. So we did a error on on on CLI. We leveraged the pipelines we we've seen immediately the impact on the service, right? The fact that the service went down, we.46:47Went back and remediated real quick by leveraging a predefined state, right? Everything was automatic. I didn't need to go on site. I didn't have the need to go on site. We had a situation where, you know, the vtis were.47:07Saturated so we couldn't connect remotely However is always available, right? And so we can go through through that and make our configuration and make sure we bring the service up until we know, have a, a way to go on site and maybe clear the virtual the terminals so we can connect remotely. So.47:27So I mean simple.47:47Problem or simple simple issue but in the end, we had a very fast fix. Now let's do the same, but let's do it through the pipeline, right? So how we would do that change, ok? Send the same command.47:48On the same switch or on the same trunk, asking it to do to implement exactly the same command which will prevent sorry, which will delete the other two VLANs and again bring our services down, ok? So let's do a pipeline. So basically what we did now.48:08Now we've learned from this challenge and we captured it and put it back into a pipeline. So we go into the scenario B.48:28And it's gonna start running it. And what will happen in here is because on NAC validate, right, I have, so if I go back into the code.48:41Okay, it's already has valid he has run through not validate, but let me just I'm not gonna show you the code, sorry. So if I go back to the repository, ok, we have rules in here. So in here we have a rule.48:53Where we can define our rules. So you have predefined rules that you can leverage but that you can find and leverage, but you can also build your rules if if you need. So capture specific rules that are pertinent to scenarios that you went through. So knowledge that you already have.49:13And make sure that you can prevent it, ok? So now if we go back to, to, to the pipeline, let me just go back like this. We can see that this was prevented.49:33Right now and it has sent the communication over Webex. Let me bring that. I'm not sure if Webex sometimes we can't share Webex directly to Webex window. I'm not sure if it's visible. Can you guys let me know if it's visible Ed or David?49:47Yeah. We can see your Webex now, your Webex conversation, if that's what you excellent. Thank you love it. Okay, so now the pipeline stopped. The command was not sent through Terraform to the device itself.50:06And I get a message, you know, as maybe a senior engineer inside the IT team, you know, you know, someone more experienced, with what was proposed and then this was intended with NO at and then that would you know.50:24Have an impact that these two will be dropped and then we will have two services, right? So you can have a messaging like this, which immediately 1st of all presents, but also creates awareness.50:44That way we can go and do, you know, education, and, you know, make sure that the person understands that this is not the way that you should be using, you know, this capability or this feature from the infrastructure. If we go back to, you know, our monitoring.50:55We can easily see that, you know, the service has continued and it's still functioning up and running. So we prevented a situation where the company could lose revenue just because you know of a simple understanding.51:15Sometimes you know it's based on experience, ok? So this is in big lines the the demo. It's very simple, but I hope it helps bring bring a point and it helps show, you know, how.51:35Our advantages is if we start moving simple operations into a pipeline and we start leveraging network as code, you know, to drive changes in the network because we have all those gateways that we can rely on to.51:52Avoid missing time or avoid having critical services brought down just because of a change that in general would not create any, you know, alarms or problems on a specific part of of the infrastructure.52:12Okay, so this is what we've looked. We have like 70 something, you know, two thirds of of the services were down. This was the scenario A, right? So, ok, this was the scenario B where we tried to do it the same thing but.52:31Through a pipeline to leveraging network as code. These are the tools that I've used for this one. So, we have the state of the network and stored in GitLab version through git. Then we have NAC validate for you know the 1st stage where we validate or we go through a series of.52:50For the command that is being sent, we have a rule that is saying that if a VLAN wants to be, if a VLAN is going to be deleted as a result, then the command should be blocked. Then we are using Terraform to do the back and forth, you know, implementation.53:10And communication also from GitLab, so we have the GitLab where we run define the pipeline version everything, run the pipeline, you know, follow the pipeline. Gitlab can also of course be a source of telemetry that can go back into.53:30Splunk enterprise, and a lot more things can be done. Out there right now I just used the communication through the the HTTP event connector in Splunk Enterprise to get information directly from the states of the pipeline and that is what is reflected in the graphs that I I've shared with you.53:50Then we have Splunk enterprise, which is the data platform, right? Where we ingest the telemetry and then we make sense of it, organize it, you know, normalize it and then we start making sense of it and you know our communication mean that depending on what you have in your company for us, for, for this one right now it was a.54:10It was Webex, right? At this point it was only awareness only, right? It could also be that you do an integration where you approve a command. That's, you know, something which needs to be decided based on your comfort level.54:30Okay, and there are variations of how this can be do, can this can be done today, like, you know, you can think about AI capabilities, AI agents as well that can be leveraged inside Webex or you know other other interfaces.54:49The pipeline was, bit like this, so we had a validate, we had a plan for terraform, and then we had the application through Terraform, a verification stage which goes to, to Splunk and verifies that the services are still up.55:06Right? And if not, then it will raise an error and we just mentioning that we will not stop the pipeline. And then at least in this case, right? And then, you know, recording like making sure that we have the visibility over.55:25If I go back the visibility of who generated the change and what was done, you know, which pipeline did it and what's the status of that. What I haven't I just realized I haven't included in here the the time when was that so that's a definite column that can be added.55:44But, this is active, right? So if you click here, it will basically take you into the information inside splunk, right? And in here you have the timestamp. And then you also have the number of the pipeline and you can go back and just search it inside the inside.56:03Okay so this was for today. What I hope you take away is that simple things that we change in the infrastructure might look working.56:25But they might have an impact that we are not not aware of of it. And in the demo I hope you could see like, you know, there is a blast radios, right? But we need to be aware of. And if we have the right tools, then we can immediately be aware of and go and and fix the changes. There are similar scenarios if we think about MPLS, you know, where you can.56:39Easily delete something on one device and can, you know, propagate through the entire network, things that, you know, you do track they are tracked you know from a network perspective, but they can be caught through pipelines like this. The, the.57:00Advantage is that we introduce standardization, right? Through standardization, we become more reliable, so availability and then you have something which is secure, which is centrally managed versioned and easily easy to.57:20Track when you have a change window. And then.57:40Every time there will be exceptions and errors, but at least this provides a way where you can take a learning from a specific scenario and then bring it back and make it part of your validation stage or you know or your testing stage if we think about, you know, the standardized.57:43Pipeline so either bring it back here or you bring it back back in there.58:04So this is the end of the session. Thank you everyone for, for joining. I have in here some links to documentation. There is a very good site that we have. Let's see.58:10There you go, network as code, right? And here you can find all the information related to different domains but also the basics, the common concepts. It's a very good starting point for you.58:29And then for the next session, so we gonna have the self service network operations, which is gonna be this time, you know, the same time as today next week Tuesday and Ed is gonna walk you through.58:43So service portals, how to take little use cases like this.59:02Or entire provisioning of specific services and make them easily accessible to different parts of the organizations. So think about the way you do today, e.g., create a virtual machine maybe inside your company, and you have like a self service portal.59:07Same thing but from a automation perspective, you know, for the relevant parties that needed.59:27Thank you very much. I'll stop sharing right now guys anything you would like to add or do we have any questions? Yes, there was one it was with regards to the deployment I think for scenario B so the it showed that the deployment was.59:34Was completed, but it should have been stopped by the validate. Would you be able to maybe just show us the CI for, for that stage as well so we can understand why it was applied?59:52Or if it wasn't. Okay, so for scenario two, yeah I think so yeah remediation the remediate ok so this scenario like the because this is the one that prevents.01:00:03The command going to go so none of the other stages will go on and then probably.01:00:23The question is for this scenario and there was this stage, right? Yes. Yeah. Yeah. So this stage usually goes to what it does, it goes back to Splunk, and it checks if the service is up or down.01:00:31Okay, in this case I think either there was a communication problem with Splunk or there is a delay depending on the the resolution of the data that gets captured, right? So there is a delay that I have to introduce into into the pipe.01:00:50The, this, the step, the stage itself.01:01:10Makes sense, so it was basically an error maybe in the demo rather than what we should have seen, right? Yes, so perfect. Thank you. I think that was everything so far.01:01:16Yes, that's all ok good good ok then thank you everyone for joining. Really appreciate your time. I hope it was useful, we encourage you to join the the next sessions in a week and two weeks. Those will be very interesting.01:01:36Sessions as well and very valuable if you managed to get to that stage, right, of implementation, especially with the self service portal.01:01:55