Alfonso Sandoval Rosas: Taming Your Data Networks with the Power of NetDevOps

In this talk, Alonso, a software consulting engineer at Cisco, discusses the intersection of DevOps practices and network management, specifically within the realm of Big Data networks. He introduces the concept of Net DevOps, which aims to streamline and automate network configurations, reducing human errors that often occur during manual configuration processes. Alonso presents several challenges faced by network administrators, such as reliance on spreadsheets and manual updates, and emphasizes the need for a consistent source of truth. He explores the integration of Infrastructure as Code (IaC) in network management and examines various tools and methodologies, including CI/CD pipelines and model-driven programmability, to achieve efficient network provisioning. The session concludes with a demonstration of how to apply these concepts in practice, highlighting the importance of testing and rollback mechanisms when implementing changes in production networks.

[Music] and we are back so we have a fonso AKA pure and he will talk about taming your data networks with uh the power of net develops uh so aonso the stage and teach us about this right absolutely hello everybody please allow me to uh properly share my presentation okay so my name is Alonso and I'm a software Consulting engineer uh here in the Isco leisan team

dedicated to software and Automation and today I I'm very happy to be able to share with you this very interesting topic which is some sort of a different flavor of the devops that we use uh on our daily basis this is a devops devoted to the management of Big Data networks these data networks that are the backbone of today's it infrastructure I'm talking about routers switchers Lo

balancers and so on and so on right so before uh starting well just uh uh uh to to rephrase it this this a photo that I love to share of me it's I was visiting the Cisco office in Tokyo Japan and well if you're interested in following up with me after this uh session we can have a chat on my GitHub and gitl profiles and also on

liin I will be more than happy to answer any questions that you may have so before we furly begin I want to share with you a Horror Story which fortunately I'm pretty certain that we'll ring the bell with uh some of you here in the audience especially for those who are network administrators in your company in your business whatever it is so we have this company right

it's Acme company whatever it is and they have this big Big Data Network it's really complicated to pinpoint what's going on in there but they need to update some configurations on these routers the switches here and there because they want to integrate a new site so let's say that I don't know like um uh an in-house data center was created in some region in Portugal and we

need to integrate it with the rest of the backbone with the rest of the it infrastructure so yeah we know which are the configurations that we need to push it's going to be a little bit cumbersome we need to identify which are the devices where we have to put this configs and this and that but of course we can make it happen so in a good old-fashioned

project management uh um you know situation the dates and times were aligned they were like okay we're going to have a single maintenance night and to this network engineer uh this person got an Excel file why not right this person got not one but many many many spreadsheets and these spreadsheets they have the name of the device the configurations that this person needs to push and so

on and so on and the thing is that you won't let me lie people here who are network administrators how do you push configurations normally in your devices you open up a console you connect to your devices via SS tet whatever it is and then you start copying and pasting cop copy paste copy paste copy paste all the night long you have to go through all these

different spreadsheets copying and pasting these configurations committing saving and at some point it just becomes a repetitive task right you can do it in a zombie mode so that night with this uh this company this network uh engineer that's what he did just copying and pasting all this configuration ations and everybody thought that things were okay right they wrapped it up we're good let's go home but

little did they know little did they know the storm that was coming after them the morning after tickets tickets pouring Like Rain tickets coming out of everywhere things that were working they were not working anymore there were dirty configurations there were things that should be there there were links that were being shut down and there were parts of the network which were actually not working after doing

or after this maintainance window right so of course they called a war room they were like okay we need to fix this because our Network this is the backbone of our it infrastructure it cannot simply be down we're losing money we're losing uh connectivity this just cannot be and well this networking engineer and uh their team they were like okay well guess this will be another night

of troubles shooting at Rodeo so they gathered up and they did a postmortem of what happened that night and they found out a couple of interesting things when they started analyzing this you know with a cold head first of all this configurations they knew that they were working because they had used them before but they really even bother to test they were like oh yeah this worked

the last migration this worked in the last deployment there is this uh person here um our Guru of the networking and he said that it's gonna be just fine right but the thing is that there were no there was no testing they were relying on somebody else's word and then they had which was their source of Truth for these configurations it was a spreadsheets it was different

files sced all around with no correlation between them so and but the chry on top here was that the person who applied these configurations did nothing but copying and pasting right human errors they can have a massive impact in the status of our Network so the team gathered up and they were like okay we need to uh fix this but we need to prevent this from happening

again what can we do about it and that's where they began exploring this quote unquote um yeah this this this revolutionary way of addressing our networks which is net devops and that's what what what we'll be talking about in the session we're going to have a look at today's Network provisioning Panorama then we will explore in depth which are the what I like to call the net

devops mantras like this different flavor of devops what is it about we'll have a dash of model driven programmability it's important for us to know how to manage our uh modern era Network networks with the power of programmability then we'll have a look at some interesting tooling for accomplishing this which is infrastructure as code or IAC then we'll go on with a really nice demo best practices

and references so this session will be about the one-on-one the Bops all in all uh the tooling best practice and whatnot along with some use cases code and demos what we will not go in depth though it's a networking in general or networking protocols in depth that is uh something out of our scope for now but if you're curious about it please feel to reach out to

me at the end of the session so now without further Ado today's Network provisioning Panorama we're still uh we're still bound to these common errors that have been there for generations and generations on end like data networks has been here for quite a while for quite a good amount of decades right and we're still falling through the same slips we're still falling in the same gaps what

tends to go wrong here when we are provisioning uh a part a couple of devices or lots of devices of our Network we're prone to massive configurations errors human errors copying and pasting putting things where they shouldn't be because these devices may be similar they may have similar names and whatnot but the human errors here it's something that really uh causes a lot of delay and a

lot of trouble when troubleshooting also we don't have a good understanding on the monitoring and consistency across the different parts of our Network when networks are so so big it's really hard to keep track on what's in there there and what needs to be there and last but not least integrating our networks with the business integrating them with other tools that are not networking as such right

integrating them with our Point of Sales integrating them with I don't know our databases our Customer Loyalty whatever it is things that have impact on our networks when for example we are provisioning a service it's very hard to do that with the classic methods in our networks and just to get put some numbers in here these are the current challenges that we Face uh when we are

provisioning our networks still nowadays 95% of the changes are being done manually in our data networks and 70% of the issues that we find on a day-to-day basis they're C because at some point at night somebody uh copied and pasted the configuration in the wrong device for example it's human errors right Honest mistakes and 75% of the operational expenses are actually invested on troubleshooting and visibility of

these networks so this numbers don't lie there's something that really needs to change and that's why many companies are aligning themselves to this state of mind to this culture of net devops so to give you a little bit of context of this different flavor of this specific flavor of the devops culture the weop state of mind I want to talk to you why networks are a different

kind of creature there are different kind of Pokemon have to say right let's Dynamic apps the apps that we all use the apps that are like a consumer front faced these apps they are dynamic in the sense of we can hold them anywhere we want right and nowadays it's more and more uh easier to have all sorts of deployments maybe I want to have a portion of

my app or so components of my app inhouse or I want to have some on my cloud I want to opt for a hybrid deployment um my app is a virtual machine based it is a container based and I can orchestrate all the components by following these Trends right it gets easier and easier all the time that's where all the the evolution is going right it's very

very fast B bed however on the other side the networks which again I I can't insist enough are the infrastructure they are not that um they're not that fast right like their pace is not that fast because of the nature of a network a n uh Network by Nature it's tightly coupled one component to the next and to the next and to the next right and because

of that the maintenance is often done manually and the access methods that we have for interacting with this machines like how do I talk to this router to this switch to this box whatever it is it was made uh it was intended from its Inception to be human friendly to be excusive for humans like for those here in the audience who have logged in into a device

via CLI um you know an NSS or a tet cons or whatever it is when you type commands these commands are intended for humans they're not intended to be consumed for example uh through the point of an API right or at least that's how things were done uh traditionally so now taking that and trying to align it with the the devops State of Mind the ultimate purpose

here or these like three steps which I like to call the netops Manas it's first of of all I want to be able to achieve the desired state of a network with minimum manual intervention I don't want to need to copy and paste to be able to achieve this desired state in my network but I want to make sure that the current state aligns with the desired

State how it's going to happen well we'll figure that out later but I want it to be aligned at all points right I want to be aligned always that's very important and last but not least I don't want to have scattered uh sources of truth I want to have a single consistent source of Truth for this desired state that I want in my right and aligned to

this we have this topic with this new topic which is has been gaining Traction in the industry recently which is infrastructure as code how do I materialize my net devops Maness well I can use infrastructure as code for that which basically means that I treat that I consider this desired state of my network as nothing but code code and code only no spreadsheets no loose Post-its no

whatever it is I want to treat it as go and so that we can follow this devops approach this devops state of mind and here there's some alignments like some the foundation pillars of infrastructure is code which is my configurations are not text to copy and paste this is code which is versioned and maintained on a BCS or a version control system which it's a g whatever

flavor it is but it's a git at the end of the day and I want to treat it uh under a software development uh mindset right if I want to add new configurations to this desired state of my network I shall treat it as go following a branching approach whatever it is but as go always right and last but not least something very important about infrastructure code

if there is some commit if there are some configuration configurations which were applied in my network that were faulty my tooling should be clever enough to be able to roll back right away so these are also some sort of infrastructure SC uh mantras the foundation pillars and it's very important for for what we're going to to see next so let's take this this concept of net the

Bops and infrastructure scod and put it together in something familiar for all of us which would be a pipeline right a cicd pipeline this is how it would classically look right this is how it would normally look from cult Coral we have our business requirements requirements which is um this desired state myet Network maybe I need to add uh some more features I need to turn on

some some interfaces I need to create some Access Control lists to block some IP addresses whatever it is that is discussed planned and written in stone then this goes to our network engineer the person who knows about the network the nukes and crannies of this configuration our Guru so to say then this person will create the definitions of this desired state in human friend ly formats which

would be yaml file or a Json file something that it's easy to follow that makes sense for everybody and that it's easily versionable and maintain and maintained in our uh git or whatever it is and once the changes are done in our desired State they go through our G and that's where we trigger our pipeline what will happen in this pipeline well our infrastructure uh asod tooling

maintained by our net devops engine here we'll take these configurations we'll translate them into actual configs that will later be pushed into our network devices by using network controllers which network controllers well it depends on the kind of network the kind of devices that we're talking about okay and now just to put it into like more like Pipeline and Stage uh visualization this is a very generic

approach but but it's a very good starting point when it comes to net devops so we have on this corner our ticketing our Sprint planning our it governance whatever it is right and from here we have our user stories like I don't know in our desired state of the network I want to add a couple more Access Control lists we want to be able to block some

remote IP addresses in my data center whatever it is so that is planned then we have we create a staging Branch for the development of these features our configuration inventory is updated with this features it is limed of course we want to have only bid uh configurations and then we create we spin up a staging environment right when we talk about normal apps like a mobile app

or whatever it is this concept makes a lot of sense because we can spin a container with with our host OS a specific OS specific libraries python Java whatever it is like all the requirements it's very easy to spin that up right it's Emeral it's our test container we test there all tests pass with flying colors that's it we go home however in the data Network universe

that's a little bit more complicated because it is not the same to create a sing environment for an app than for an entire network it's way more combersome networks as I mentioned before they are like this strange creatures and they have these strange considerations there are some tools out there which help us to do this though there are some tools that help us to create a digital

twin or as similar as possible to what we have in uh the production Network we can spin it up in a container fashion and we can have all this different network virtual devices connected in between like following creating a whole network and we can use that for proper testing it is testing as accurate as possible mimicking what we have in production so we can make that happen

there's these tools like netson verl CML a couple more once we spin that up we test our the changes in our configuration inventory in this digital twin and we run the series of tests right like if they pass with flying colors all of them we can create an artifact with the reports of this tests and then we move on from the staging Branch to the production Branch

through a PR for example we can merge these changes in our uh inventory configuration inventory where we have the desired state of the network and once that PR is approved and our changes go into the main branch develop Branch however you want to I name it we are in conditions to applying these changes in our production Network the real deal right it's very important to be able

to First do a dry run because uh our simulation environment may may not be as accurate as it needed so we it's always good to be able to do some last minute checks and if everything looks fine we should be able to finally commit and test the changes once again in production once it's good we create an artifact we our reports of the tests and then we

just wipe out all the resources that we created for making this possible like containers our stage environment whatever it is right so this is like more like a generic approach but it's for us to know like on on on on real life what which are the most common stages of a net devops environment and now I want to go to this specific part of this all this

structure and talk about how do we communicate with our devices because as I mentioned before just copying and pasting commands on an SSH on a tet interface that's not good that that that won't work on a mass scale environment that will definitely not be compatible with the net devops environment because this this this tools the CLI SSH tet that's intended for humans right machines cannot talk in

between them using CLI commands that just doesn't work so that's why um it this is a trend that has been ongoing with the main uh Network vendors which is model JP and programmability what I do here is that I Define uh all the different elements within my network box within my switch within my router I Define them with code I describe this structure using a very specific

modeling language which is called Yang and this Yang is standardized and uh so that all companies all vendors their network devices can talk in between each other right and there's many different kinds of models Yang models there is models for uh the data that we can have in our devices there's models for the services that we can have like for some here who know about NW workking

protocols there's models for how my OSF should like for how my EI GP should look like and this and that and there's also standards there's industry standards which are um uh properly regulated by the ietf by the internet engineering task force and there are also some vendor specific standards that are exclusive for Huawei noia Cisco whatever it is and just to show you how does this look

let me uh share with you a hint of these models for example I have here um one of the models publicly available out there which is for defining an access control list on an iOS XR device right so you can see here this uh Yang modeling language it looks a little bit like Json so to say but here the important part is that we're able to describe

how my components look like so here I have this container which is an ACL and prefix list right and here I have access list manager prefixes sequences name access you can see here that this is nothing but the description of how does an access control List look like right and this is going to be very important uh for what we are about to see okay let me

go back to our slides there we go and there are some standard protocols that we can use that are entirely based on this modeling language and we can use them for allowing our devices to communicate in between each other but also for other parties such as for example our pipeline our CSV pipeline to communicate with our devices the first one is NETCOM NETCOM is based on SSH

like there's an SSH ssh session underneath but what we use with this one is rpcs or remote procedure calls to be able to communicate in between devices or in between my Pipeline and my device and there's a very specific set of commands of operations that we can use for this here I have a couple of these uh for example edit configuration hey I want to change this

I want to delete this configuration I want to get this specific data from your configs but the thing here is that they are entirely based on a Yang model if for example I want to create a new Access Control list I need to first know how does an access control list model looks like and that's the file that we just saw in the git in my browser

once I understand how it looks I can create this payload using this instructions and you uh it's XML format then I can send them V SSH to my devices so this is takeaways here SSH based and entirely based on Yang models okay and now we have rest com if the rest part rings the bell yes that's because it's based on rest API uh fashion we use the

exact same verbs that we have for rest you know get post put patch delete whatever it is in order to communicate with our devices the this is entirely HTTP based which means that I can talk with my devices as if they were an API point right as if they were rest API and point it's a simple as that yet again the payload that I send on these

requests is entirely based on this Yang data model so I also need to know how does this Access Control List look before I create my payload and send it to my device it can be via the payload can take the shape of Json of XML and then the replies that I get back exact same thing as our rest end points right I can get a 404 I

can get a 200 a 2011 whatever it is it works in a very similar fashion and that's good because for people who are used to working with rest API endpoints well this is piece of cake right and just the for uh giving you an example this is how a request would look it's pretty much my URL which represents my device because there inside we have the rest

compaign point it's something straightforward and now uh I want to jump into the tooling right because this is these are the ways in which we can talk to our network devices but now how can we enable that communication how can we enable our pipeline to be able to manage through this all this life cycle of our desired state in the network so for that we have infrastructure

SC tooling and there are two two two different kinds declarative and imperative declarative here is we have the definition of what what do I want to do and the tool is clever enough to determine which are the steps right we don't really need to worry about what's happening in the the background because it will uh sort it out all together for us right for example if I

say that I want to create an ACL my tooling which is declarative will know that an ACL requires first to create this then to create this let create this in this order and I don't have to worry about it so the pr on this it certainly it's way easier I don't have to worry about the details I don't have to worry about the nukes and cronies of

this however the coing that we have is very specific like I can create an access control list and an access control list only right there is no flexibility if I want to TW something here something like that a little bit more specific I don't have that flexibility right and a prime example of this sort of tooling it's a terraform although terraform is mostly used for uh infrastructure

in the cloud you know to spinning up and um managing the life cycle of AWS asir whatsoever ever um instances it it is also widely used for network devices and it all comes to this in terraform we have two different files it's our provider which is uh devices or the endpoints the resources sorry that we're going to be connecting to and then we have what we want

to do with them in this case for example I want to create an access list and here I have the definition of uh which is my target device which are the parameters of this access list it's all in these files then we have our provider and this provider it will take these files it will run the calculations of which are the configurations that it needs to push

then it will finally commit them into our destination device and the am the the band doors that we can cover the things that we can do it really depends on the plugins that are available there are specific plugins for for example a Cisco iOS XR device and a specific plugin for creating Access Control lists on this specific device it all depends on the on what's in there

published by the bandor but once it's done we can use it pretty easily and that's why chirm is one of the preferred tools out there uh in the networking world and then we have the imperative ones in imperative uh uh with imperative tooling we need to Define how like if I want to create an an access control list I need to First do this then do this

and then do that right like this commands they have to be executed in a specific order and also the uh error handling roll back we need to cater for that ourselves like we need to put something up front in order to control all this nuances right and the the drawbox of this certainly is that it's way more work and it's you need to be more aware of

what's happen happening there behind your curtains however you are more enabled to do different things you have more flexibility in case you want to cover some Corner cases for example or you want to do something very specific with this tooling you can do it and here I have these two examples which is anible and NSO uh half and half I was mentioning because they're a little bit

declarative they're a little bit imperative they're somewhere in the sweet spot right for anible it's in a Noto we need to have our inventory file which is uh our Target endpoints and then we have our modules which is basically like the plugins Interra form how are we going to be talking to our devices how many things we can do we put them all together on a Playbook

and this Playbook is the set of instructions of this configurations of this desired state that I want to have in my network device and then we'll anible will uh determine all this configurations and we'll push them in the device for you bear in mind that when we work with anible we need to have an anible agent installed inside of our devices most of the vendors uh support

it it's uh uh commonly used uh as a as a sort of standard in the industry but it's just we have it's be in mind that we have a small living agent of anible there inside my router my switch whatever it is right and just to make a comparison here if we have an imperative uh approach approach um with anible it's basically I don't know I can

send my configurations I can send my CLI against having a proper module on a the clared fashion in which I have this specific module used for specific ACLS on my iosr devices for example and I can send this configurations it depends on what we want to do and also the modules that are available out there by the Endor right and then finally I want to mention uh

so one other option which is a crosswork network services orchestrator or NSO this is more like a framework right uh in on the top we have an integration with business logic we can create using yet again Yang using data models we can create services that we expose to our third parties to our pipeline whatever it is and then we can have python or Java code to take

this inputs work with them and then push configurations southbound which is to our devices here we have something that is called a network element driver or a net these are some sort of plugins that we can get from different vendor so we can talk with these different machines with the different router switches whatnot using different protocols for example I can talk with a foret via CLI I

can talk with an ixr via NETCOM I can talk with a Huawei via rescom right it depends on what we we need to do we can get these different small plugins right now uh speaking of which the demo that I want to share with you it's based on the latter uh crosswork Network Services orchestrator and it is a net devops pipeline for provisioning ACLS Access Control lists

on my devices how it looks well this is the layout it's entirely based on gitlab gitlab is our uh BCS and also our uh cicd engine we have our service code we created a service for putting these configurations from our inventory into our devices we have this inventory disc configuration files and we have some tests made with Robot Framework and we're going to have an staging environment

and in this staging environment we spin up an NSO container we spin up a Domine network based on this tooling which is called nsing and we install this plugins for talking with the devices right like required Nets we apply the changes here we convert our inventory in yaml we convert it to Json and we push it in our devices into our devices using rest com right you

remember rest com and if it All Passes with flying colors we create an artifact with the reports of our tests and then we bring that into our production environment if we do a PR against our main branch that's how it works let me switch out that okay this if you I will share with you the link later this is a repo open for everybody if you want

to have a look this is uh my uh demo be based with on NSO I want you to have a look at this inventory and here we have my access list router RFS you can see that here we have this is um here we have yamu format and we're talking about a device which has two access lists testl one test ACL 2 and here we have some

different parameters right this is yl this is an inventory this is the desired state of my network I want my network to have this configuration at all times all times okay and with this pipeline we're able to accomplish this so here you see that I have two runs of my pipeline this is my Day Z configuration which means that the has the complete configurations right let me

show you here the pipeline this is what's happening in an nuto I am taking this file here I am doing some linting I want to I want to have a healthy yaml file before working with it so I lint it well first of all I install my libraries my python libraries whatnot that I will require later and then I lint my inventory if it's properly linted if

it passes with flying colors then I spin up my staging environment which is my NSO container my packages and my test bed this is where I spin up my dummy Network so I can test my inventory then I run my tests these are very basic Robot Framework tests and if it all goes well we are in the main branch which means that I connect to my Remote

device to my sorry to my remote server and I apply this configuration ations to my production Network right those configurations are there already production and for example if I uh want to add something to this inventory I have here this spr with this other Branch you can see here that my changes where that I added two more entries to my inventory these are two more um uh

Access Control lists I also updated my tests of course and you can see here that the pipeline looks a little bit different it is not the main branch which means that I am just going to test them right I am just going to test these configurations once this BR is approved I will push them with this extra stage which is deploy into my production Network and the

thing about this is that a last Le we have our artifacts and you can see here that I can download the results of my test test I already downloaded one here and I have this very handy HTML report and here I can see that all my tests passed that I pushed my configurations uh you can see it here I used the patch and uh using rest comp

right and what did I get 204 which means we're good okay so in a nutshell this is how this net Dev Ops in a very very simple approach of course but this is intention that I want to convert my desired state of the network into actual configurations that I pushed by my cicd pipeline okay let me go back just to wrap it up here very quickly uh

just Comm common practices here uh for all the people out there who are um interested on embracing these practices as part of the day-to-day in network Administration I know that it sounds a little bit intimidating right because we have this conception that if you want something to be done properly you should do it yourself or like there should be like somebody like a human being behind the

keyboard doing these things when we talk about the the network the networking Universe right which is so delicate and uh so tightly coupled so my advice here and that's what I always tell to my customers is to start small it is very very possible and very easy to just automate a little bit of my there's some slightly you know some small repetitive task some day-to-day provisioning it's

very easy to do it's very simple to do all the tools are out there all the information is out there most of it is open source so it's just this invitation to embrace this net develops State of Mind little by little and just to take it from there right it's an open invitation and also don't forget about your network Engineers they always come handy because you cannot

automate something that you don't fully understand that's truth right yes we have this devops approach yes we have this software life cycle approach but at the end of the day we're automating data networks the backbone of our it infrastructure so it's always important to have on boarded our networking gurus so that they can sort out all the corner cases all the things that look sketchy and have

a proper consistent configuration uh um file for our desired set of the network and then commit frequently but never to main always embrace the pr uh lifestyle that's my best advice and keep your tests small as small and clear as possible as atomic as possible and be merciless all tests must pass nobody wants to wake up to love lots of Daya tickets right and I will leave

here with you some references some lectures that I find very interesting if you want to get involved into the infrastructure code net devops and whatnot Universe also a little bit of network programmability if you want to have a look at my gitl demo this is the link and that would be it from my side I want to thank each and every one of you and I think

we are right on time that was awesome I I wish I had this about 10 years ago when I was working with automation on data centers on Prime centers awesome uh we have three questions yeah I'm honest on that we have three questions uh this questions was uh one was in uh of the presentation made the answer here are the questions each environment usually to testing to

have testing environments for Network how you can achieve testing um this a full copy of your infrastructure in simulator and that is a any rowback plan when applied configuration yeah exactly okay let me go one by one yeah I have the questions here so uh Branch prob tested in mup environment Tes envirment for Network yeah okay yeah uh test testing first I want to start with testing

it really depends on what you want to do because there are different there are different ways to uh test uh how the impact of the configurations that we apply on a network right on a virtual network duby network whatever it is so the F first one that Engineers normally use it's to compare configurations like I apply this and then I go back to my device and I

read the configurations and I see I know beforehand what's going to be the impact so I read all this uh configurations that I that I get from the device and I check if the the the changes are there right there's different ways of contrasting this some people do just be textto text comparing and if text a matches text B that's good we're good to go right there

are some other we can do that for example with robot that's exactly what I did I was just on my robot test there I just compared I read the device I got the configurations I compared it against what I was expecting string match we're good right there are more complex uh mechanisms uh and there's stoling for that I would recommend Pi ATS I can share with you

the the information later Pi ATS actually takes us snapshot of not only my device but also the devices around it so that I can really analyze the impact because for example if I want to create a new routing protocol right like an obf and all these other devices are now neighbors I want to know that they are neighbors right so there's other tooling that goes beyond that

it's like Network State snapshots and we can compare them and also know if tech or Frost right now for uh full copy of infrastructure in later that's desirable yes that is desirable but there's also techniques for doing that we can maybe work with a a specific segment of the network and you only have the configuration backup of that specific segment right because of course we don't want

a file that is you know like gigabit long right we want to keep it simple uh also our git platforms start doing strange things with large files so we can keep small and segmented and then finally roll back PL plan configuration yes all infrastructures go tooling they have some sort of roll back mechanism right without going further into details the three main ones which is terraform anible

and NSO they do have their own roll back so you can control under which situations you can trigger the roll back but more than often the device tells you right like if you're putting in configuration that makes zero no sense on a device on a router whatever it is the device will complain the device will be like uhuh I canot do this and then these tools are

clever enough to go like oh okay I can roll back right so it it depends on which tool you're using but they they can all do it uh have one question so so uh when the is wrong but when the configurations is quiet uh the effect of your apping can have effect negative effect so there any techniques to act like to validate to how do you you

you you you can check this if it's possible you know it's is working you you apply your form what tooling and it's is working you you made the the but what we appli can have pery or even destroy something that supposed to be destroyed how can avoid the situation yeah of course nobody wants to to to mess up to destroy anything on a production Network right um

most of uh most of these tools they have the concept of dry run the dry run it's something very very common in the networking world because again this configurations they are so delicate that we really want to understand what's going to happen if we push this without actually pushing it so yeah yeah we can issue dry runs of the configuration that we're about to push and we

can evaluate the impact right that's something that do uh but well before that also having a reliable simulated environment uh comes handy because sometimes the dryon won't tell us the whole truth right especially when these are configurations that propagate to the neighboring devices okay any more questions I think we are almost in the time so thank you for for so yeah so thank you have a good

bye thank you thank you ever thank