Cisco Network Services Orchestrator Demo

and this is the topology we'll be working with in the sandbox this totally free and reservable on devnet as well for anybody else we have a couple ios devices we have internet router one uh distribution router one and two edge switch one are all ios devices we all have two xr devices with core router one and two and then one asa device there are nexus devices in this topology but because of a cml bug we're working with right now we're not going to be touching the nexus today and we're not going to be doing anything too fancy on the networking side so no need to memorize all the subnets and ospf here and all that kind of thing so we are on a linux terminal right here for a jump host that has nso installed on it and so to enter the nso cli i'd use ncs cli because that's the old name of the product before they're required and log in and you'll see hopefully a familiar more or less familiar prompt with the hashtag or pound sign first older folk and i've already added the devices in here to save some time i've added in device groups but basically the way nso works for that it just has a series of commands you enter in the ip address port number device type and then you can actually store the credentials in an aes encrypted string in the cdb and it's decrypted at runtime behind the scenes um so that's that's another thing for network automation i know people getting started it's like how are we going to store credentials securely we're going to use vault or something else well nso does that for you so you once you typed in and saved it you don't have to worry about that from a security perspective so you can do different show commands so if i do a show devices list that will show us the list of devices we have connected here we have like i said two xlr devices one asa device and a handful of ios devices gives us our ip addresses as well if i i can see the devices we have in our device group remember so we have a device group with all our devices that i've added in we have a device group for our one asa device our ios devices and our xr device and these all practices indicating these are the things i have in that particular group and if i want to connect to my devices nso doesn't maintain a persistent connection with all its devices it's not like the eye of sauron always seeing everything that goes on all the time it only talks the devices when we're asking it to do something with with nso and so if i say devices connect it's going to can scroll up go through all the devices in this case we're connecting over telnet port 23 and telling us result true in the sense that we have established connectivity to the devices but at this point i haven't actually had nso learn the configuration yet and i can actually verify that by doing a show running config in this case i'm saying show run config against the cdb the nso so even though we're used to seeing show run config on a per device basis we're using that same naming convention within nso to talk about how we're interacting with the nso application so i'm going to say show run config from all my devices i want to look at one device and we're going to look at internet router one and look at that what does nso understand that device's config to be at this point it just has some placeholder basically telling me i i don't know the configuration yet and jason this is tony um is it's getting the configuration from the device or this is what nso has stored locally that says this is what i think the device's configuration is this this is uh pretty much what you see for any device that has no configuration nso so even though you see lines here this is basically telling me that it doesn't know any configuration yet um so it it just places all the configurations for any new device oh is it retrieving from the device tony says and i was wondering network um we'll retrieve from the device the next step so if i go um devices sync from and with that one command we're doing a lot of things behind the scenes so we're logging into all the devices in our device list we're doing a show running config show version then parsing that all into the local cdb so now we'll have our updated copy reflecting what is actually on the device for all the devices does that answer your question okay i i think so so uh with that sync command that you just ran yeah it's then retrieving the configuration from the devices okay i understand thanks yes not yet it seems not there and and i'll cancel out that command but we can now we can say i can push up arrow show run config same exact command and if i have entered now we have it gives us the version so with that information but if i space bar down we can see we have some static route you know crypto asserts interface gig one through four some bty lines so so it has that across all the devices so it's one of the configuration and i can i can actually go into the log file i have this pulled up this is a trace file isn't not typically what a normal user would look through but since we're showing kind of behind the scenes what is going on we can say username we can see in our log file that nso in the whatever two seconds that we saw sync from this is what was going on behind the scenes it connected to our device it got to the telnet prompt of username it plugged in the username of cisco and then had the password prompt in telnet and this the log file doesn't show us the password but it was able to get into the device and then do a term length zero term with zero show version and then and then go on some other way to i think also show running config show boot much by the commands so so all this was going on behind the scenes when we said sync from and did that for every single device if i can just chime in with one piece of context too with the questions that were coming from tony and the rest a key piece to recognize here that that is different about nso from some other the other automation tools is once nso has done that sing from and learned the configuration for the devices it now has like in its cdb its database what it what the device configuration is supposed to be and so that allows nso to do a lot of what-if analysis limited config changes as you move forward and it also allows at any point in time to make sure that the network configuration is what it's supposed to be if we assume nso is what it's supposed to be and so i like to say it's a great way to prevent kind of cowboy engineering somebody going out of band from like the proper framework and tools to go through because at any point in time nso can kind of do that check to make sure is the network what it's supposed to be and just to that point while you're talking i multitask and exited out of the nso application back to the linux terminal issued a telnet command to internet router one and so we're doing out-of-band change outside of nso's knowledge so i'm the cowboy engineer i log in let's say i add in an into loopback of 100 and we'll add a description of how to name change for cisco defined takes it out of that go back in nso so so i had outside of nso's knowledge and so online talks the devices when we're trying to do something with the device so outside of nso's knowledge i went to linux telnet into the device added some configuration change and now if i do a devices check sync it will do a hash basically against what the local copy and what the actual device is it shows all my devices are in sync except for that internet router one it shows i was expecting this particular hash i got a different one so there's something different between those two what what my last known good copy and what's actually on the device and so there are different ways you can handle that you can do instead of doing a sync from and updating my my nso copy i could also do a sync 2 and wipe out what is the change of someone else that shouldn't have been done possibly or i could do a sync from and update my local copy if i think that change was a good one so if i want to see what that change was from an so percep perspective i can say devices sync from try run and the drive run is telling me i'm not actually going to update my copy yet i just want to know what the change would be and so it tells us and this is the kind of behind the scenes nso likes to use what we call the j style cli for those of you understand what jstelle ccli would be and even though we're working with ios config we have it rendered here on j style cli so we have this internet router one since we last talked to it somebody added a loop back a hundred with this description and it's telling me if i'm actually going to run the sync from it's going to update that myself copy to add that out-of-band change so it automatically detects what the exact changes were and it's going to update the local copy or i could say devices sync 2. and it would remove that change so it just depends on when you see the change what do you want to happen uh do you want that out of the change was that a valid change wipe it out i mean keep it or if it's in invalid change wipe it out so it allows you to treat in such who has that single source of truth and it's able to update dynamically based on what is going on uh i i'm just wondering is there any sort of uh uh correlation between sort of um what the current network design is and the change uh that was made what i mean is what if the the cowboy engineer introduced a loopback and a bgp neighbor that was sourced from that loopback then you went back into nso and you did the resync and it noticed hey you know there's a there's a loopback here and a bgp neighbor and you say oh well we can't have these extra loopbacks we should be removing that in turn that's also going to take down the bgp pier you know is it going to sort of know about that waterfall effect that if i remove one thing it's going to affect another yeah so i'd say that's where the model driven part is a lot more important than just being text files like when you're talking about yaml and jinja is that it understands the relationships between the config so if you have an acl applied to an interface or in your example bgp it's going to see that it's going to be removing multiple pieces at once and notify you of that or so so you you have when you have those dependencies in place it's going to show you here's all it's not going to tell you operationally how it's going to change the network but at least from a configuration standpoint if you have configuration that is tied to another piece of configuration it will let you know that that's going to be a problem nice nice question by the way but uh for the bgp even the new loopback wouldn't bring the hearing down because you need to manually set the old pairings anyway uh even in the dynamic peer templates yeah and like i said same thing for acls if if you're trying to remove something that's linked to another piece of configuration and so will tell you this this is you know connected to another piece of configuration are you sure you want to do that so was that out-of-band change even applied or was a change only applied within nso when you specified to sync it or leave it as is i in in this case it it's still out of sync because i haven't i just did two drive runs i had the sync from dry run and the sync to dry run so i haven't actually changed the nso's copy to be in sync um so in this case i'll just say devices sync 2 and wipe out the change okay so the out-of-band change was actually applied yeah that that event changed it noticed it was changed it said oh there's a difference between what i know config to be and what's actually on the device what do you want to do do you want to wipe it out or do you want to keep it in this case i decided to wipe it out okay okay now show you for your configuration because we're dealing with more than just a text file snapshot we can actually look at all of our configuration in json and xml i know for network engineers this might not be the most exciting thing to see but for the people who have started going down their automation journey seeing configuration for legacy ios devices or any device across the board having that configuration rendered in a programmatic format is super interesting it allows you to then programmatically interact with whatever piece of configuration you want to work with so what we're working with here is just a legacy ios device it's not running that conf rest comp anything above above the board those nets those device abstractions are parsing all the configuration force so we can treat any device basically as a programmable device and manipulate the configuration on a granular level so i was looking at here i said sure run config show me my snapshot of this devices interface configuration show it in the json format and because behind the scenes it's parsed all the configuration for me it says okay here's all the interfaces in json so we have gigabit ethernet 1 gigabyte ethernet 2 and i mean this is not something that humans want to be typing or reading but it just kind of shows you behind the scenes it's not just a text file it's literally it can transform it between json and xml or the native cli so we have the same interface configuration for this ios device and it's being rendered in xml format and and i found that be especially useful because sometimes there are devices on your network that are never going to be upgraded or you know they're going to be there for so long you're never getting an api to that sucker and like what this allows you to do is to have that level of complexity and programmability done on the server side and so from the devices perspective all it sees is commands being sent to it from nso but nso on the on on the back side has all the devices in this xml json format so then you can do all kinds of fancy programmatic things because nso's be able to swap between xml json and cli back and forth between the three okay so question so i played with um with postman for aci sure um like if i was trying to sell someone on the advantages of nso over playing with something like postman besides the ability to sync what are the other advantages uh i i'd say also rollback and also services so what i'm showing here more of the basic features when we get to hank we'll show some of the kind of more pizzazzy stuff uh so i i'd say overall like the key differentiators for me when i was a network engineer were i get to start in a cisco cli i get to have all my devices be programmable no matter where they are i have a snapshot and a configuration to play with like hank was talking about you can do a commit drive run see what the commands would be you can then roll back any change that you're working with and so so when you're making your change if you if you at the end of it see operationally it's making the problem your network as long as you stop connectivity in a so can then calculate whatever changes you made it calculate the reversion of that and then in terms of more advanced features being able to have nso programmatically connect to other applications and then also have services where you can bundle up your configuration into more i'd say bite-sized chunks uh which i think will show in a little bit but i'd say that's usually more out of scope from what i expect network engineers to get started let's say for getting started having a local copy to play with and then having those roll backs would be the main things okay thank you i think i think also the way changes are made uh there are some nuances and subtleties that um nsot you know treats the network as a database so all the transactions are fully acid compliant that works on a two-phase commit type of process so if you're having complex changes either the whole thing is applied or not yeah which protects you from you know you know you know partial failures um and if it you know as jason said if it's a rollback it's a full rollback yeah the other thing i think that's that's kind of cool is we um we have technology called fast map which because nso has a complete config and you push a change through it figures out the least amount of work it needs to do to get the you know to get the device to to the desired state so um if you look at some like acls right if i change an acl block it doesn't wipe out the entire acl you know stanza then then rebuild it in which creates you know which creates a security hole you know in that transition it'll just figure out okay this is a specific line or these are the specific characters and it applies patches and roll back very atomically um which uh you know provides you know minimize the amount of churn that's happening on the device as we implement changes and then roll things up or roll things back yeah you said something interesting in there about phased commit how is that being accomplished on you know devices that don't have face commit natively right so ios ios xero not traditionally phase commit yeah type type structures i'll i'll show you for an ios device right here so let's say we have a device going back to internet router one config we can add in let's say interface we and if i do a question mark it actually since it knows the configuration it will show me the descriptions show me the available interfaces and i'm not actually making any changes on the devices yet i'm just changing the nso's local cdb copy so that's the first phase of the commit where i'm making a pending change onto the nso's copy of the configuration and if i add save description let's see new loopback or new change and update the ip address if i do a question mark it'll show me actually what the ip address was based on what it learned from the device we'll say 162.61.0.1 and it has the same thing for the subnet mask where it's wearing that from the device and so right now i've i've made these changes to this ios device and it actually hasn't talked to the device at all the device might be down for all nso nodes and i've had that problem before too where you wait for the device to come back up and have those types of things but when we've made this pending change we can say commit dry run and that will show us i'm going to be removing this old description i'm going to be adding this new description and i'm going to be removing this ip address and be adding this ip address this is the j style cli i can also say format native to say show me what the commands would be from an ios perspective i'm going to be sending a new description and i'm using this following ip address so i at this point i've done the commit driver and i haven't actually committed it but if my issue the commit change then it will log into the device and issue the commands so from a device's perspective the device doesn't know that it's a two-page commit all it knows is that commands are coming in but from the nso perspective you're able to to do those manipulations and then when you're finally ready to commit then it sends the commands okay that's cool um so i guess then my next question is you know how do we make sure because i mean a lot of the purpose of the phase commit is the idea that you know order of operations matters um when you talk about an on phase commit device i go and change an ip address i lose connectivity maybe i need to change the acl first right is that all planned out in in how nso approaches individual line configs i mean you guys have some context around what order operation should be to make sure you don't lose connectivity what does rollback look like i mean how does that get handled yeah so i'd say if we kill connectivity to the device by you know changing the management ip or something that that's kind of on you as the engineer so nso needs to be able to have connectivity but i would say if you're doing other things that have sequence of events like you need to have this interface be present before you have the acl applied to it and things like that and nso has those those nets those network element drivers for each the device types i'd say tens of thousands of lines of code behind the scenes that are doing more than just doing sure run that they're executing they basically programmed in those sequence of events for all the commands that are supported for those devices um so yeah i'd say for for anything else apart from killing your own management interface it has all those sequences ordered from you and then also the reverse sequences ordered for you when you want to roll back just as you re reloading five before every change yeah is it just me yeah yeah don't use it man it's still out there yeah so if i if i actually commit here and i can pull up my dandylog file so it took about two seconds we can look for my chang on this build let's see interface we'll talk to the ip address so we can see behind the scenes in this fancy dancy log file it has this is the configuration changing this send and basically that's what it's sending behind the scenes uh i think can come uh and i can show you the rollback from this change so if i go to i'm still in config mode if i say show configuration changes so if i want to roll back to my previous commit it says i would need to go back to this previous interface description from my new chain and then go back to the old ip address so i i just issued one command said what's the last configuration change i made and then it says if you want to roll that back these are the commands we would do to get back to that state and if you want to see all of the commits you can go into rollback configuration do a question mark just like any ios device and these are all the commits i've done from the innosoka application here and also before we started so if i wanted to roll back to previous state i could select one of those states and then roll back to that state so so in this case i have this basically whenever i make a change not just across one devices but across many devices like omar was saying if you run into any issue and let's say command doesn't take if something fails it automatically issues the role back across all the devices okay oh do you want one more demo before we hang out to hank actually two more demos one showing templates and then one showing nso interacting on the show command side so the way nso works with templates is that it treats it kind of like a golden config where we can tell nso we want to have this configuration be present on our devices and if it's not present add it to it if it is present don't do anything there are other ways you can merge replace do more fancy manipulations but for the sake of our purposes we're just going to be merging in new config if it's not there so i'm going to copy and paste in some configuration here just for the sake of not having to watch me type so what we have here is i'm still in nso configuration i'm configuring the application itself so i'm not talking to any devices yet i'm adding a new template i'm calling set dns server for three different device types i have an ios template an asa template in an xr template and the nice thing about working in the cli is that you could just enter the commands issue question marks you know to see what the next commands are do command completion just like a network engineer would but you're actually creating a template in the process and so we have a dns server of dot 222.220 for ios asa and xr so we have three different device types represented in this template so as we apply this template to our device list nso will automatically basically filter out it knows this is an ios device so i'm going to i'm going to plot ios to put i know this is next our device i'm going to apply the xr part of this template so you're not going to have to worry about having to apply it to the specific ones you just apply to your devices generally and i want to commit basically i want to save those templates into my nso application and now we can go back to we have those device groups so i have my all group so i can apply this template to all my devices i can do a question mark and it will show you my popular possible completions based on what it knows my templates to be within my initial application in this case we just have one one we just created called set dns server and so in this now we've applied this template to all of our devices in the cdb we haven't actually sent any commands and devices we're just interacting between what we have in what we want the config to be and what we know the config to be versus nso snapshot so we have core router one and two distribution writer one two our firewall internet router router one we've applied the template and we can see what commands it would send if we do a commit driver on format native telling us what native commands we want to send so that template is now applied to all of our devices we have our dns servers 2220 across ios devices our asa device and our xr devices [Music] and if we want that to actually be sent to the device instead of just saying commit drive run we would then say commit and it would send to our devices any questions about what's going on there so far okay if we want to roll back the configuration we could say rollback configuration and we'll calculate what does it need to remove from the last change we made we can see what that change would be saying show configuration so say for each device i'll just issue a node domain name server for that configuration on that rollback configuration command what's interesting is that it assumes you mean the last configuration but every configuration change that's ever been made is stored so you could roll back a change from the previous day or four changes ago and that's that value of the cdb is nso will look at it and say if you want to roll back this change first is it possible based on all of the other things that may have happened since then and if so this is what it would take to roll just that change back depending on what's happened since then you may get into a case where you couldn't roll back one transaction without other transactions okay so it's not rolling back to the state for changes ago it's actually saying you're actually saying i want to roll back that specific commit correct okay which is quite that's quite different to a lot of other commit based mechanisms that's interesting and then now i'll show a few operational show command because you can do that with nso as well it's and it's a primarily configuration management tool but you can still send commands direct with the devices uh as well so it's it stores when it does the initial sync from the information of you know platform name what what's version we're working with platform model serial number so if we do show devices device internet one platform we have that information and if we want to just drill down into still number we could ask for that as well now what's more interesting is that we can say show devices device and then use wildcard star platform for all our devices and then it will show us we have all our devices all the device types what os version they're working with what model and what serial number and in this case the xr devices still number actually is n a i had to log into the device and see that happened no that's that bug um which is pretty helpful if you just want to get a snapshot of are we piece or compliant you know do we have any issues our network in terms of what os version are working with serial numbers information like that is there any way to to group these i mean this is great when you have you know five or six devices with a star but you know i can imagine when you're running hundreds of devices you'd have some sort of logical groupings you'd like to be able to pull stuff like this for yeah so it has the device group mechanism that we'd used before and then you can also for any command do pipe save and then save it to a text file and so so that's another common that mechanism is is if the terminals too much information you want to save that to an external file commanding command you're working with and we can do devices if we want to actually send any specific command to a device we can use what's called the live status command where we say exec and then whatever command one we'll say show ipm brief so previously what we're working with up here was from the sh when it did the sync from it captured that information for us and saved into the cdb but now we can actually talk to the device with whatever command we want if we want to do a show ipm brief on this particular device we can say you know exact live status show ipad brief and give us that information we can save that to a file um you can also do that you know with let's delete this multiple devices so we can say dist router star live status music and you show it and it has the show ip route information for us and for that i was basically just using the star as the wild card for us to send the same command to both router one and router two and i'd say for for more complex sending show commands that's where i typically go to python uh because trying to do that with 50 devices or 100 devices you know is a little unwieldy um in the python api it mirrors what we're seeing here on the command line and so you could just say like for device and device list send show ipm brief save that to a file or put it through if no text fsm you can use a text fsm template to then parse that into json or xml because nso is only parsing the configuration data here that ends up from my perspective so any other questions in terms of what we have for the demo before we go on hank great feel free to reach out to me as well on twitter and linkedin so one thing i'll just want to build upon something that jason mentioned on the net so there there is a lot of logic that's built into the nets there they're not just keyword translators so like someone asked about ordered sequence so the logic to actually order sequence order commands in the proper sequence are there um one of the more useful things is actually going the other direction is normalization of error messages and and those kinds of things so if you have you know juniper routers and cisco routers and then whatever um you can get normalized error messages going back the other way so your service logic does so you don't have to build those things into your service logic your service logic can be fairly clean and straightforward and then all the device stuff by device specific stuff gets handled transparently with the ned and i'll say on top of that i i know a pain point for people who work in multi-vendor networks or even multi-platform networks is even if you do have apis in your devices they have different ways of handling credentials different paths to get to the same resource and you're having to normalize across all those different device types even if you have devices that have apis and since nso kind of normalizes that all within its own ecosystem it allows you to have kind of a simplified unified interface for devices that don't have apis and that do have apis but might have apis that are inconsistent across each other

Channel: Tech Field Day

Views: 819

Rating: 5 out of 5

Keywords:

Id: PawQKZ6wqes

Length: 33min 9sec (1989 seconds)

Published: Fri Oct 02 2020