Alfonso Sandoval Rosas: Code is the new CLI - Data Networks Programmability and beyond

This talk covers network programmability and the transition towards a software-first approach in networking. The speaker, Alonso Sel from Cisco, shares his experiences in adapting to networking challenges during the COVID-19 pandemic, highlighting the importance of utilizing APIs and scripting to automate network configurations. He discusses the prevalent issue of manual configuration errors and emphasizes the need for model-driven programmability through the use of data models like YANG. The session delves into various techniques for managing CLI interactions, the significance of infrastructure as code, and the integration of DevOps practices into networking, known as NetDevOps. Finally, the speaker provides career advice for networking professionals looking to enhance their software engineering skills.

[Music] hi guys this is the next episode in our our today's session and I made to introduce Salas from Cisco as he said and he he joined totis in in 2016 and since passionate about adding value customers and power coding today Al also will um show us his presentation and tell us about the network programming and um has engaged in the university and master classes delivered server

coding training at Cisco Community promoting and adopting the devet practices Advanced of coding mindset uh and of course you can find him with a with a GitHub web page and Alonso please welcome you and show us what you do absolutely thank you thank you for that introduction and uh hello everybody broadcasting live from Port Portugal to Lithuania and all around the world um I'm very happy to

be here with you sharing this session about Network programmability and Beyond and before I fmly begin let me int introduce myself a little bit more so um my name is Alonso SEL and uh I'm a software Consulting engineer here at the software and automation team in a Cisco Systems Portugal this is a photo of me that I like to share uh it's when I visited the the

offices in Tokyo Japan and you can find me here on my GitHub my gitl which go by the same Alas and also Len if you're interested uh on following up with the session I will be more than happy to to connect or to have a chat uh after the session right so you know before we Fally begin I want to share with you a Horror Story which

I'm pretty certain that it's going to resonate with all of you here who are uh data network administrator ERS Data Network managers and people who work on their day-to-day basis with all about networking which is Data Centers security infrastructure and so on and so on this is a personal story of uh back in the days when the pandemic hit when covid-19 uh totally changed our lives in

everybody was trying to S out what was going to happen how could we deliver continuity to our services to uh you know our workplaces in general and this was a struggle that out all our customers had and back in the days I was still in Mexico City and I remember that I was working from uh for one of these big big Banks they were our main customer

and if you don't know the thing about Banks is that they need to be able to deliver operation when it comes to training so they had this bank has a lot of teams dedicated devoted to trading right and if you don't allow traders to do their job even for a couple of hours their customers they lose a lot of money right like this is an operation that

needs to to keep up keep up keep up despite everything around it right so out of the blue when we when it became certain that covid-19 was going to have what's going to have us uh locked in our houses in our places uh they reached out to us and they were like okay we need to enable all these people all these traders to be able to work

from home we need to enable them to work from home in record time because we're losing a lot of money and uh so back then I was working with voice and video so I was in charge of allowing people to use their computers to use the um to use them as if they were phones right like voice over IP phones and video and all this stuff right

so of course we uh put a plan together we're like okay we know who are the people that we need to migrate and bear with me this was a worldwide thing like all their teams in the Americas in Asia in Europe in the Middle East in Africa we needed to migrate them to working from home in no time so we have information we pulled it manually from

all our databases directories and so on but it was all spreadsheets basically lots and lots and lots of spreadsheets we knew the commands in order to to do this network configurations we had to do some some commands they were easy they were straightforward but it was a lot of copy and pasting so we we would have we would have our notepads here and just like copy paste

copy paste opening up a console with this device via SSH via tnet and copying and pasting copying and pasting and of course you can imagine that a week worth of work most of it was troubleshooting because it was so repetitive it was so monotonous and so prone to human errors that we invested more time on troubleshooting just checking hey something's not working something strange than actually doing

the configurations right than actually pushing those configs into our Network so it was pretty hectic and all of a sudden were like okay there must be a better way for doing this and we found out that that our systems our networking boxes our switches our routers all this and that they had an API layer back in those days it was very very primitive we really didn't have

a lot of knowledge about it but it was there and couple of us in the team we are uh software Engineers um by profession right like we we sted software engineering we started computer science and so on so we're like okay it's time to maybe take off our networking hats for a little bit and put our software engineering hats and analyze the situation from a different perspective

and so we did we found out that we could pull this information using very basic scripts who are these people these Traders where are they located what's their phone line which are their Privileges and we could put all this information we could condense it into templates and we could start pushing them automatically right using scripts very basic Python scripts so that's how we were able to shrink

this you know we were uh expecting weeks and weeks of effort we were able to crush this down into a week and a half more likely we were operating this script 24/7 24/7 and we made it we saved the day and it was all due to abandoning living aside for a little bit this classic approach to networking and really putting our programmer hats on and um uh

checking this from this perspective and the thing is that we're not alone on this in this struggle uh nowadays there is many situations that lead to errors when we're configuring our networks it's human errors Hest mistakes of course also there it's very difficult to provide monitoring and consistency across a very very big data Network and it's also very hard to integrate it with our business requirements and

if we put numbers on this you will see that still to today a big big amount of the effort invested On Doing Network Administration is done manually we're talking about 95% of the changes done on a big Network they're still being done manually 70% of the things that go wrong are because somebody copied and pasted things in the wrong way it was these were human errors let

but not least 75% of the operational expenses they invested in because of all the situations right these are consequences of following a decade's old approach when it comes to configuring our networks and this is more like a cultural shift right when it comes to talking about networks which are the backbone of our it infrastructure um we uh tend to think that doing things manually is bulletproof it's

the safest approach to these configurations for a couple of reason reasons these are tightly coupled and networks they're a different kind of creature if we compare them against classical applications I don't know mobile app whatever it is there's many ways for deploying and managing these uh applications the software based products they can be deployed on virtual machine they can be deployed on containers they can be they

can coexist in um a local environment entirely cloud-based or even a hybrid one but the net Works they are different kind of creature they're getting there but the evolution is not that fast therefore there's been recently this effort to bring a software first approach into the real into the universe of the data networks that's why CO as of now is the new CLI so we're going to

have a look at a series of topics very very briefly will have a look at different techniques for managing the CLI using Code using some uh different tooling we'll see what is model driven programmability which is a foundation pillar of today's uh coding efforts towards data networks then we'll have a very quick look to infrastructure scope concept and net devops and finally if you're interested in following

up with this I'll give you some career tips and tricks right so first of all the CLI for all of you who do networking on a day-to-day basis who work with routers switches load balancers servers and so on You Won't Let Me Lie it's out of muscular memory that you open up a console it's SSH it's tet whatever it is and you start typing commands commands commands

commands commands this is the CLI right it's a commin line interface the thing about it is that it was actually designed for hums right it was designed for us to um to to clearly understand what are we doing but to actually type type type type everything that we want all the configurations all what we need we have to type it ourselves the thing about this is that

it actually doesn't M very well when we want to talk uh through a machine right if we want to have I don't know a cicd pipeline if you want to have a serverless application if you want to have some third party who is not human to talk to our networks it really doesn't matter very well if a CLI is not an API it's not an API endpoint

right it doesn't work that way so there were some initial efforts which are still pretty popular today and actually quite useful for some specific use cases uh so that we could enable this communication in between an automated third party and our data networks to enable some sort of middleman right so that's uh how this CLI mimicking uh tools came up to be these are series of libraries

that we can use in our code uh so that we can Leverage The CLI communication and actually automate some cool stuff right if I want to deploy a thousand configurations on a thousand networking devices I can put together a python script this python script will take these configurations maybe do some templating to change them a little bit to adjust them to our Target devices and it will

be able to convert these configurations into actual CLI commands that I can push little by little into my devices right the most popular of this it's called Paro I'm pretty certain that most of you have heard about it this is like the de facto tool if you're entering into this CLI mimicking world and it's pretty simple so what paramiko does is that uh behind the curtains it

opens up an s or tonet session and it actually starts spitting the commands one by one to our networking devices of course for from the perspective of our Network device it really doesn't make a difference our device doesn't know that there's a a script talking to to it right it really doesn't care for what it's worth the device thinks that it's a human being there typing typing

typing all these different commands but it's in reality this middle right taking these commands from somewhere else I don't know from Ginger template something of that sorts parsing them into valid configurations and actually spitting them one by one into our devices all right and although this sounds pretty pretty cool it actually comes with a couple of interesting issues for example we cannot really control if uh our

configurations are not valid right if I put some configuration I don't know like an access control list right and it doesn't have all the all the mandatory parameters the device will reject it but Piko may or may know that it's been rejected it uh it really doesn't care it's just a middleman right in between my script and my devices my network and also uh for um it

might sound familiar to you that most device vendors they change their software version right and sometimes when that happens when we go from version a to version B some commands change especially when we talk between architectures some commands are really likely to change and what's going to happen is that my configurations are not valid anymore and I can have this beautiful script which is helping our company

save lots of time and effort but all of a sudden we migrated these devices and this script is worthless because these commands are not valid anymore and in order to adjust these uh these script to reflect these changes it will take a lot of time that's lots of code refactoring so cases in which this approach is valid if you're into doing BBE steps into Network programmability this

might be your jam in order to understand how this works from a programming perspective and also some very specific Corner cases like some quick fixes some configurations that I want to have on the go this is a really nice approach right but you may be wondering if this is not the case the python Mir CL python Library well what can I use right that's where model driven

programmability comes into play and I love to share this this photo this is a t-shirt uh from one of my business units at Cisco I saw it in the desk of one of my colleagues and I just find it amazing it's the definition of programability which is as you can read here capability to accept the new set of instructions to alter Behavior ensure Hardware software connects to

everything including The Matrix pretty important of course right so it was uh couple years ago that the leading um the leading uh uh companies in the networking Universe they gathered up and they were like okay we need to come up with a new standard so that we can enable simless Communication in between our different devices you know letting Huawei talk to Cisco talk to Arista talk to

Pala and all these different vendors we need to allow them to seamlessly interact with each other but also to interact with other third party tools right with my cicd pipelines with u any other integration that we may need so that we can have a seamless closed loop with our business logic in between our business logic and our Network right so the solution for this was models and

this is an effort uh regulated by the ietf the internet engineering task force to standardize and regulate how to describe what my device can do what does it have inside and what can it do right so that's how we came up with the Yang data models Yang per se it's just a modeling language it is very very similar to Jason and it helps us to Define to

describe in words in code how those might Dev how does this router how does this switch look like in the insides and we have different types of models right we have device data models which is how does my component look like I don't know how does an access control List look like how does an interface look like which are its components its parametes and so on we

also have the service data models which are more for services right a brf OSF protocol e eigrp protocol and so on and so on and we have different kinds in terms of who is actually writing these models we can have industry standards which are open and they're accessible for all the vendors or we can also have vendors specific models right that they will only work for Cisco

for Juniper for foret and so on right let me show you how does this look let me switch uh switch screens here these models they are often public right let me uh bring my cursor here great okay these models are often public I have here the the public model it's in a GitHub repo of how to create access control lists for a Cisco iOS XR device this

is Yang code this is the Yang modeling language you can see here we have some uh keywords like modules prefixes and it is here where we start uh describing how does an ACL look like right here we have a prefix list this prefix list has an nexcess list manager which has prefixes and here we have sequences here we have accesses and so on and so on right

you can see here that this is nothing but a description I am using the Yang language to model how does an ACL look like inside of a Cisco iOS experity B right this is a bendor specific model this only works for Cisco XR however there are other kinds of models which ideally work for all bors who adopt them this is the open config initiative and it's a

project really worth looking this is one of these open source projects which has been gaining traction recently and it's all about Industries embracing open open source models for their devices so you see here the equivalent of this this is an ACL for cxr it's private it's vendor specific but here we have it equivalent in open config right and you can see that it's a public release in

a repo anybody can log in and have a look right and we have similar description well here we have some revisions some identities that are like in variations a couple of things right so what what is happening now the trend is that more and more bors are adopting this open source models right like this open config initiative and as of now you can opt for any of

this right like inside of the device you will have in Vendor specific data models but you will also have open config data models as well the difference mostly the difference that you will find is that the vendor specific ones they may support some devices specific configurations right like there may be some small Keys here and there that are specific to Cisco specific to fortunet that you will

not find here in the open config equivalent right so that's just very important to know it requires uh some effort but well it's good for you to know that we have both uh options okay and this is gain more and more traction so let's go back into our slides and just for you to have a a glimpse of the Yang modeling language in terms of uh Data

Network modeling the most Atomic the simplest data type is called a leaf and the leaf it has a type as if it was programming variables right it can be a string it can be integer it can be a numeration whatever it is but it holds one and one value only of whatever data type we have in there right so for example here we have a host name

it's a string only one host name only one string right then we have a LIF list LIF list it's a com it's a a grouping of different leavs but it will have they will only have one data type right for example this one it's a domain search and it's made up of different leaves but these leaves one too many they can only be strings right then we

evolve you know a little bit uh uh an upper level we have containers and the containers it's like this little box they allow us to group within different kinds of elements right I can have leaves I can have Leaf lists I can have whatever I want but they're like these are like this logic grouping uh within and this comes very handy for um creating these logical uh

units right that represent things as you saw for example in the access control list uh data model we have like the accesses and this was like a grouping of different things of leavs Lea lists and so on and so on right you can have one or many different child nodes of different types and then here we have a list this the lists work a little bit like

python dictionaries if I may say it's a sort of key value situation I can have I I need to have a key and the apart from a key I can have different values within right it it doesn't have to be a one onone it can be one to many for example this one my interface my interface it has a name but this name must be unique so

that's why the key is the name right and apart from that we can have other elements of different kinds different data types and on so now we've seen what Yang is and how we're using it to Define our data models in our devices so we have the models and now it's time for us to learn how to actually use these models to talk to my devices and

that's where these different protocols these new protocols come into play so the first one here is NETCOM and NETCOM is actually based on SSH there is an SSH session there in the uh behind the curtain but we're actually using rpcs or remote procedure calls to talk to our devices and we have a very specific set of instructions uh in XML format so that we can create dat

we can create configurations we can change configurations we can delete things we can get things and so on and so on right it's based on SSH TLS and so on how does this actually work well first of all all our devices which are enabled with NETCOM they have three databases running candidate and startup running is the database that has all the configurations that are running now all

the things that are in my control plane all the things that are right now forwarding data back and forth back and forth these are the configurations in the blue Database The Running one then we have the candidate candidate configurations are the ones that are ineffective right now but I can commit them to the running one so that they become effective so that they come into play why

do I need this well we use it mostly for dry runs like we can have here configurations that may or may not be ready I'm evaluating which is going to be the impact but I can have them here ready right just just in case and then finally we have the green one which is startup and these are configurations that will commit into the running database into the

blue one after my device is rebooted and I need this for example for Disaster Recovery let's say that my data center was shut down for some reason there was a power loss whatever it is and when my devices come back um they they they come back into power we can have our startup configurations there so that we can have the minimum requirements for connectivity in between my

devices right you get my point so this is how this three databases were cleverly uh put into play and this is something exclusive for Network netc product now there's this dance in between my agent and my networking device when it comes to NETCOM first of all if I want to talk NETCOM with my device I need to create an SSH session once it's created it I will

send a Hello message that's the name of my message it's hello and so that I I'm asking my device hey can you tell me what can you do this is very important because my device inside of it it has different data models we s is two types the Bor is specific and the open config ones so the vi is going to reply to me with this list

with this collection of models so that I know what can I do with this device so then I can take any of these models and uh create the payload that I want to send to my device it's in between the brackets of an RPC call and for example this one that we have on the screen it has three different sections first of all it's my message it's

got a message ID it's some sort of pattern then we have what I want to do in this casat in green it's I want to edit a configuration in the running database but it could be anything I want to read a configuration I want to delete a configuration whatever it is right it's a part in green and then finally the payload right this all this XML it

is actually modeled after the Y data model that you saw right there in the GI have it was on this like Json is format which is Yang but here I need to put it on XML so it it Mak sense but we have the same parameters the same data types everything is here if I don't know my Y data model I don't know how to speak NETCOM

with my device it's as simple as that and then once we're once we're ready we set this RPC and then the device will give us an RPC reply and once we're done we send a close session request it replies with okay and we're good to go right so this one it's SSH based however what if I told you that on a pretty similar fashion we can also

talk with our devices uh via rest right you remember rest I'm pretty certain that everybody here knows their rest verbs what is a get what is a post what is the put patch if I ask you what does 404 mean everybody will tell me the right will give me the right answer if I ask you what's a 2011 204 we know rest we love rest right our

rest API M Points that's the best thing to have and what if I told you that we can actually map this into our network devices this is a pretty recent Trend and it comes really really handy because for us software Engineers it allows us to talk to our network devices in the same way that we talk with I don't know the Spotify API or uh any Google

API right it's exact same experience this protocol is called rest it is also based on https and it works in a similar fashion we have these URLs we have to use the same verbs get post boot patch delete and the only difference is that this URL it actually targets a device and the payload must be in either XML or Jon and which payload I send well this

payload is actually modeled after yet again myang data models the ones that you saw on git right so that's why it's super important to be aware of this data models otherwise I don't have any payload to send and here I just want to show you very briefly you have this uh this URL it's as simple as that uh to to communicate with my devices via resov as

if it was yet any other given API ecbc right now I just I want to show to show with you very briefly this concept of infrastructure scode I talked about this more detail in my other session today earlier but the thing about uh infrastructure scode is basically embracing this brand new mindset in which we don't talk about our configurations as just command line arguments that we need

to copy and paste under this state of mind we are considering our infrastructure as living code this is code that we can right that we can do versioning on using a BCS any git provided and that we can actually manipulate and Will based on what we need in this moment and which of course we can integrate with cicd pipelines and so on so this code it actually

describes my intend the intended state of my network this configurations here on this yaml file on this yon file this is what I want to accomplish what I want to have right here right now in my network right there's different tooling for this that seamlessly integrates into my uh cicd pipelines and using the protocols that we talked about before using NETCOM restom these data models and so

on and so on we're able to create this closed loop in between my business requirements the desired state of my network and the actual state of my network that's something that we can do putting all these tools all together and now just for uh um there's this other flavor about uh devop that I talked about briefly in my other presentation devops can seamlessly come into play um

when we talk about networking if we Embrace this state of mind of infrastructure as code we can start treating our networks as code certainly and we can integrate all this tooling into devops so devops when it is applied into the networking Universe it converts into net devops which is a this different flavor a little bit more spicy than than normal devops right and the benefits are pretty

seamless there's early detection of defects it's easier to integrate smaller changes the the risk of introducing errors due to metal interbation they're greatly reduced and we assure that there's more quality when we deploy new configurations in our Network and we can do it on a faster Pace faster faster Pace with more reliability and overall more quality right and these are like sort of the mantras like the

the foundation pillars of net devops which is as I mentioned before it's devops practices in the networking Universe we should uh push small but frequent changes frequent frequent frequent changes in our network devices our tooling should be able to roll back by by itself right like there shouldn't be any manual intervention whenever we know that this configurations are going to be faulty or that they come with

some dirt our immediately and let us know about this and well not last but not least but the most important part we mitigate disruption risks by human intervention or bad code right it's when all this comes into play on a holistic view having this infrastructur code that devops that devops everything combined into a Clos Loop right and here I would just like to wrap up uh with

some tips and tricks for all of you who are interested into following up with this topics maybe some uh Network Engineers here who are interested in bringing all this good news into their their day-to-day practice or software Engineers who are interested into in the network programmability or the infrastructure universes which are really really um uh my suggestions would be to reinforce all the software engineering uh uh

uh uh topics right so that we can make sure that we're always delivering high quality software it's some sort of a taboo among Network Engineers like I'm a networking engineer I'm not a software engineer I'm just going to do scripts and I'm just going to deliver them if they work it's good despite not being maintainable and whatnot well this is something that we need to fight against

everybody can write high quality software everybody can follow um software uh quality standards uh design patterns and so on this is something that we all can do and we all should be doing right now and on the other hand you cannot really automate something that you don't understand fully right so network engineering part it's also very important to have at least the very minimum concepts of routing

and switching CLI management and also some expertise on other Technologies like Data Center Enterprise core Wireless whatever it is it really really comes in right we will always have here our network engineering gurus but it's it's it just feels good to to understand what you're automating right if you're automating Cloud if you're automating networking it's good to know how this is done manually so you can really

understand the impact of your automation efforts in it right right and last but not least just keeping updated the infrastructure world it's evolving so fast and being able to to understand and to TU your way through uh different deployment patterns different architectures containers GES Etc Cloud providers Cloud infrastructure hybrid infrastructure and so on that's something that will come really really handy okay so this is everything that

I have prepared for this session now I would like like to uh hear from you the microphone is all yours if you have any questions that you may have I I will be more than happy to answer that stop sharing my screen you ask question and we'll see how many people understand what you mean but that was that was quite nice with with the young right but

uh if somebody if somebody create this code create those um those configuration is any chance check if uh everything goes well or will be okay because at the last of slides you you show that the software development un need testing are necessary right but how we can how we can improve the testing before the plan deployment is it there is yeah you understand me absolutely there is

a different uh there's a series of techniques for this um in the networking World um testing in the networking world is not as straightforward as in other uh Industries for instance on the mobile app development or any given web web app whatever it is when we create a staging environment it's PR St forward what I need I need a Target OS version whatever it is uh Linux

Fedora whatnot right uh or in Mobile phones I need a specific Android version an iOS version right and I can put all of this all my libraries my python my Java the specific versions I can put all of this combined on the stage of environment and test my new code put on some unit tests right whatever tool you you you like the most robot uh P test

unit testing whatever it is the networking world is slightly different the networking world it's not an app it's not a container it's not something that I can just spin up and test with there are different platforms which allows us to create virtual networks we can simulate the existence of a Data Network as simple or as complex as we need we can simulate different routers connected all together

having this network and the intention here is to have a digital twin of this part of the production Network where I am going to deploy my code AS similar as possible right it will it rarely is 100% uh uh alike but as similar as possible in this environments I can create them and Destroy them at will I can even make them part of my cicd I can

even have them version as Cod and as part of my testing plan I spin it up I deploy it then I bring this Cod changes and I can use all these other techniques unit testing P test Robot Framework there's ways to do this right so that's where where this fine line between networking development and software development becomes really blurry at some point they both blend uh gracefully

so to say yeah but I'm curious um why you're trying to to to create the young language is I made of course the name of the languages uh because you said there is a first was on iOS and XR um then that were the problems with some deployments or some quick fix of configuration that's that's the really way or that's the really yeah way that you are

trying to uh yeah to fix the network Engineers problems so when it comes to the data models uh so so you ask about because we had first the one that I showed the iOS XR uh for Access Control lists and then I show the other one which was open config right yes yes that's right if this is an effort for uh uh standardizing everything and making these

models open source 100% open source this is an open initiative this is part of the one of the Linux Foundation uh uh projects that is ongoing and all the different bors they are collaborating together so that we can accomplish this at the end of the day the only purpose Pur is that we have an open-source repository uh that allows us to talk with the different device vendors

seamlessly right so that with the same code I can talk with the Huawei with a fortunet with a juniper with a Cisco right that's intention we're not there yet but I think that we will be there anytime soon it seems to be like a new service in the cloud yeah and for the future right now okay but it is really nice really cool that summarize the configuration

mostly language for configuration it is quite nice and easy technique okay there's there is I think no question about the but you can all the guys uh chat with um with Al Alonso wherever they want right over the LinkedIn GitHub Twitter if you had Twitter or now platform and it is not necessary uh to ask him here if you don't want but but please please you may

to drop the the question but uh 3 two one it's no questions all right all right then then thank you and really appreciate to meet you here and quite nice presentation and your Visionary really really nice thank you and thank you thank you very much and uh work you for the next uh next episode this all bye-bye and all right see you later see you Joo