Cisco SD-WAN on Cisco Routers

my name is David Clemen of I'm a leader in Cisco ESD when Technical Marketing organization I came through the VTL acquisition Ramesh and I spent many wonderful years back into tella so today we're going to talk about a couple of topics we're going to be double clicking just like Ramesh and Rohan mentioned in the beginning I'm gonna be double clicking on several several items um so there are some foundational things that I wanted to make sure that we are all sort of in agreement on and if you have any questions then obviously feel free to ask me anything that comes to mind um I OS X ESD one is one of those foundational things that we want to cover today because it's a foundational element of some of the things we we're going to double click on later on in regard to a cloud in regard to security so I want to make sure that we understand sort of the premise behind our OS X test-1 what is IO SX est when and how do you migrate to iOS X CST when from what you have today right obviously it's a very loaded topic migration could take hours just just on its own so I won't be able to cover all of that but at least we'll give you a flavor of the art of possible what you can do with with iOS 6 ast 1 so that's going to be our kind of a three topics for today first we're going to talk about kind of the architectural recap because my session is kind of the first one that is generic to some degree right we're not going to be kind of heavily double-clicking into cloud and and security so I'm gonna spend maybe a couple of minutes to just setting the baseline of what a Cisco SD when architecture is and what are the elements of Cisco's do an architecture in case you know some of you need a refresher right so we'll call this is a recap then we're going to talk about those migration best practices of how to adopt say Squire 60s d1 and then I'm gonna give you a brief demonstration of some of the operational elements that we are we're improving in our Cisco V managed platform which is our single pane of glass for for the entire s2 and solution ok so as an architectural kind of recap we are an SDM system so we're we're believers in Software Defined Networking principles which identify three distinct architectural tiers of data plane control plane and management plane and that's exactly how our solution is built day one on D if you kind of follow from bottom up on the bottom you have a collection of when edge devices and this come in different shapes and forms physical virtual we're gonna have a slide after this one just to recap what are the different platform capabilities but these are the traditional V edge appliances physical or virtual that were brought into Cisco from Litella these are also the Cisco the cisco routing platforms the Isar 1000 the Isar 4000 the ASR 1000 the csr a virtual router so it's a whole slew of a platform chases that our customers have when they sort of embark on this Cisco Sdn journey right we also see this when Edge has been critically important for the features such as multi cloud and on-ramp it into the cloud that all happens from the edge the security features which is pushing the security into the perimeter of the network because the closer security it is to users the more efficient it is and the application quality of experience so we're not going to spend time today talking about application quality of experience but think about this as you build this entire architecture because you want to transport applications over it you want to make sure that the quality of experience for applications be those on Prem applications or a cloud applications is as best as it can be right so these are kind of a three key services anchored on the data plane now the data plane talks to the cloud and the cloud is a collection of controllers of different types the first one is the V smart controller which is the control plane controller it's used to really establish the fabric to distribute control plane context around in regard to routing security different attributes it runs our overlay management protocol which is an extensible control plane protocol that runs over certificate authenticated TLS or DTLS connections that get established in his zero-touch fashioned between the routers and the V smart controllers so we smart controllers live in the cloud we're gonna see what are the options where that cloud could be and then at the end you have the V manage which is the single pane of glass that's what you would expect from sort of a system where this is the place you go this is your GUI this is your API so that you can leverage for any programmatic work and scripting anyone of anyone who wants to kind of you know do things with a Python scripting and make REST API calls to automate some of the workflows inside if you manage beyond what the graphical user interface gives you and we have kind of a growing interest from the community to do kind of all of those DevOps things on top of you manager and so these are the three distinct layers of of the solution in addition to that we have the layer of analytics which takes the telemetry from the network and basically analyzes that provides this sort of a predictive analysis as to capacity planning capacity forecasting some performance base lining things like that we purposefully separated that from the V managed system because it requires a little bit more of that sort of a compute power and analysis rather than just V managers being a pure operations tool when you go provision things troubleshoot things deploy things things like that so it separated into a different system it's an optional element but we have a really good traction around the customers adopting a analytics platform so that's kind of like a refresher for you guys to keep in mind where what Cisco sd1 is and what are those elements of it now I mentioned platforms right so our customers have a wide variety of platforms they can choose from right so if I go again physical platforms a choices of either isar platforms or the traditional whipped Ella VA appliances and those are the physical platforms so many of our customers would prefer to consume this this technology in the form of an appliance a router it's more predictable more recognizable to the network teams they have operational procedures around that so they don't want to disturb that I want to continue consuming in a physical form factor and for that they have a choice of of platforms obviously because we're talking about iOS X CSD when we're going to be focusing in this session on the Cisco is our and ASR platforms which actually run the iOS XE software and now for some of our customers that want to deploy this in a completely virtualized form factor and they're free to deploy our software on top of any x86 platform or they can deploy this on top of our en CS platform which is cisco grey box solution it's an x86 platform which is also a router as the management on it runs hypervisor KVM a base hypervisor so it's kind of like a little bit friendlier than just a generic x86 server but our customers have a choice of whether the one to run this on a NCS or just a plain vanila any x86 server and we reach into the public cloud by offering virtual the instances of virtual routers in three major cloud computing environments so that's kind of the lay of the land as far as what is your kind of a menu of choices that that a customers have now obviously um many many of our customers are I saw an ace our customers just like Rohan mentioned millions of routers are out there a lot of interest is how do I take those routers and move from a traditional routing box by box paradigm into an SD one port paradigm which is a networked solution which is which is a system centrally managed with a cloud-based a control plane all of these things right and for that the iOS X CSD when is really the driver behind it question any support for the CSR 1000 yes yeah I'll go back slide this so CSR 1000v is formally being supported in our release that is going to become an end of November so we have a code release that is going to the end of November we call this 1610 and and that is where we will support a CSR running iOS XE Sdn thank your watch questions there a functional difference between the solution as our platform then on I V edge 1000 for example excellent question yes there is and that's a good segue for em to this light right so what we'll have we really done with X CSD when right so think about an X CSUN is a foundational piece of software that runs on top of the Cisco IOS XE routers ice RS 1000 4000 and ASR 1000 so what we've done is we have embedded a VIP teller brought components with Terry patella intelligence with teller services into the iOS XE st1 now did we keep in iOS 6 CST when sorry did we keep an eye or sexy in its entirety no we did not many of the services that exist in iOS XE are not fully compatible with the way that sd1 operates many of the services are not largely adopted so we took this sort of like an approach of okay let's prune think so that we don't feel are compatible because Sdn is not just a router by a router solution it's a system and as a system it must operate as a system so we can't just have quote unquote sort of rogue functionality that you some of it is control through we manage some of it you have to log into the router and configure CLI or use some some other management tool that that does not work it has to be controlled by V manager right and as as such we decided on which elements of a traditional iOS 6 II will make it into the xes t1 and which ones we decide to introduce at a later point so there is not hundred percent feature parity between iOS XE sd1 and the traditional with Tayla operating system and there is obviously some services from the traditional iOS exceed that we also took out so there are some considerations that customers go through and when they convert their existing routers into the iOS X CSD when routers and it's an evaluation process in regard to what am i gaining by getting s different features and what am i quote unquote forfeiting by removing some of the things that we decided not to include but as you can see in here we're kind of spring that we tell intelligence within the I OSX ESD when code right and some of the key things that we brought from whipped Ella are obviously in here and particularly the overly management protocol is in here our communication to the management system through confidence basically net conf communication obviously things that have to do with all the SD when policies and yet side by side we kept some of the really solid proven iOS XE features in there right as you can see there are different buckets in here so security is a bucket of feature functionalities embedded in iOS XE Estevan where things like services obviously this is not a representative of everything inside the Iowa succeeds the one but just so you understand that it's kind of like taking an i/o 60s D one sprinkling those whip teller components in them embedded so it's not running as an external foreign entity as a container or whatnot its embedded inside the Y's IO sexy image you mentioned that there's some features that from the the traditional of the patella platform that wouldn't make it in so you mentioned that right and you didn't specify I'm curious no but maybe this isn't the right time right is there anything in the what we would be familiar with in the iOS XE code that is now gone when you would upgrade to the right so you had two questions the first one is the first one is what do you lose from the tradition of the patella and so 15 months into acquisition obviously it's a very tremendous amount of work it goes into introducing the traditional patella features that we had developed four years into the iOS xes d1 a code right so it takes time so there's a certain road map of when the features that existed on the patella and we have a 75% of them already in Ex ESD when there's a certain amount of features that are still trickling in into the iOS 6 ESD 1 and you will have a complete full parity between what you had before and what you have after M so that's just a matter of a short time and the second question about what features of iOS iOS X a traditional one you lose quote-unquote by converting that your iOS 60s t1 so there's some things for example the oh the the whole slew of IP VPN technologists that that exist in traditional us succeed dmvpn for example not there anymore we have our own mechanisms okay alright so things like that right and some of the things that did not make it to the X CSD when initially are going to be introduced into the xes they want again it's a matter it's a factor of time some of the customers are using the I saw especially in the assembly market for routing you see etc is usually going to be part of the that code as well or absolutely um it is not there today and we have talked to you about when we talk about the migration M today if you were to look at the AI OS X ESD well it does not have those traditional voice features such as you know SSD functionality you know PRI termination for local voice breakouts at the branch offices and we see a tremendous move specifically for you see a we see a tremendous move into sip based communications in which case it's all basically just network right and building a better network gives you a better you know unified communication experience as long as and we have many customers who are kind of departing from the traditional way of thinking about I have to do PRI circuits FX o FX s circuits I have to make sure that I have srst because my when can go down by building a solid when many of those things just disappear on its own because now I have a fully redundant worm that never goes down right I don't need an SSD functionality in it right do I need an a PRI breakouts well know I'm moving into sea-based trunking right so many of those voice specific things are actually not needed in the world of in 2018 sort of tree you leave some customers in a pickle because there's school districts in hospitals and stuff that need a trek and this amount of analog backup so you can't just move away and say we're sure I agree with you as far as what you're saying for the superior what you're saying right and it's a fair point right so keep in mind it's a matter of time until the things that that are not there today are going to make it into iOS XE st1 for that we have a customer centric management team that works diligently on making sure that these things get back again 15 months into acquisition we've done a lot a somewhat related question in a few of the other sessions that we've had we've around surrounding SD win we've been wondering about multicast yes is that going to be included with it yes so multicast is is a long-standing feature that we had from Reptilia days and multicast again it's one of those features that is not there today on XE STL and so it again just like I mentioned about voice it's going to make its way into the into the excess demand obviously the traditional XE is a very solid implementation of multicast it's just a matter of making sure that that is brought into the SDM domain under the V managed management to be smart controllers so it's a matter of time absolutely our plans are to have multicast as part of the iOS xes d1m so good questions let me move a little bit further around migration sequences so the customers who are adopting iOS XE sd1 have to plan how to get on board XE SD well right some of those are easy and some of those require a little bit more kind of a you know considerations right so we typically see that adoption having three phases the first one is obviously establishing the controller footprint this is a 95% of our customers opted for cloud controllers we have a fully automated cloud ops operation that spins up all this control infrastructure in our public cloud back-end so that's not sauce that's not something ninety-five percent of our customers ever have to get involved with beyond placing an order place an order magic happens controllers are spun up so nobody needs to do anything about that what the customers really focus on is transitioning data centers and more importantly introducing sd1 into tritium to in existing data centers and then performing the actual migration on the branches that's primarily where the bulk of the sort of the work goes into right obviously everything is zero touch but there are some certain considerations that you keep in mind so if we look at controllers controller deployment as I said fully automated and when it's deployed inside Cisco cloud by the Cisco cloud ops team customers have a choice to deploy this in their own centers a small subset of our customers that have some compliance or regulations that require them to host their own control infrastructure that absolutely do that in their own data centers works equally the same and we have an opportunity for our partners to deploy and host and manage those controllers in their own clouds so their own data centers their own caller facilities and what not so we have a slew of partners that basically see that as an opportunity for them to provide value-added services into the customers whatever the case may be those are all virtual elements they can live in any IP cloud customer cloud Cisco cloud partner cloud now if we talk about data center um data center deployment usually revolves around topology that looks like this when in SD when intelligence and in this case we're talking about iOS X CSD one but it equally applies to the traditional Vitello operating system and traditional web tella routers as well so we're making kind of an emphasis on iOS X CSD one here but equally applies to the V edge v8 routers and the riptile operating system as well and these routers are inserted in a manner that is sort of like sandwiched in between the data center core and the front facing layer of MPLS which is the MPLS EE routers and the firewalls that front end the Internet connectivity that already exists in the data center today before even started SD wind option right so it's kind of a typical topology of the data center there's certain advantages of why that's a typical architecture we're going to double click on some of them later so I don't want to linger too much but data centers are usually very straightforward it requires obviously very comprehensive support for routing protocols which we have because unlike branches that tend to be simpler data centers them to tend to be more complicated and so obviously you have to make sure full support for routing protocols OSPF bgp before somebody asked about the edge ERP yes for adding the HRP but today it's OSPF and BGP um and obviously the interaction between the core switches the ampulla C router so it's all kind of embedded into the data their routing topology so you are talking about David OSPF and BGP is in underlay because as overlay you canister OMP right absolutely yes absolutely right em overlay cannot live without underlay connectivity I need to have a foundational IP connectivity before I can establish any tunnels any control connections absolutely right for the migration scenarios ciji before the underlay very fair point very well taken yes yeah GRP is out there a lot and so we will be adding that in the meantime there is ways to do a distribution between OSPF and EIGRP or on the core switches so there are ways around that matter of time is your P will be there M if we look at the branches right so let me run through a couple of quick scenarios about branches so a branch that looks like this it's a simple branch that has a single router no redundancy connected to in MPLS circuit has potentially may be a land switch that is doing layer 3 again OSPF PGP or is just a way or to connect to subnet really simple may be somewhere two switches sprinkled around and what we do in that case and the simplest one is to perform a software upgrade again it's a compatible platform so it's one of those platforms that a customer already has in their in their branch they just do a simple software upgrade load the software reboot the box comes back up all the control plane stack comes online which means talks OMP to the controller's toxnet conf to the v managed system for management interfaces with the southbound routing if there is any right performs potentially redistribution between OSPF bgp into o mp2 advertise that out into the rest of the overlay so this entire sort of control and management stack just comes online zero-touch right so the amount of effort that went into this is performing a software upgrade right again it's an opportunity to also diversify the connectivity so if there was an MPLS circuit keep it if you want to augment in an ambulance with internet add an Internet some of our customers add 4G LTE some of customers discontinued MPLS circuits in some sites so it's a complete sort of freedom of choice as far as which transport is chosen will you continue to keep ymp or for the overlay - oh it's very good question would we consider to have an O MP or continue with o MP absolutely Oh MP is the coolest thing we have it's a really foundational protocol within the within the sd1 fabric it's it's far superior to any other control plane mechanisms that we've seen out there what about the interruptin Interop we can talk about that interrupts the way we see that M is happening on the southbound the fabric itself the core of the fabric is has has to be compatible with with our sort of control plane right what's a good point potentially you know opens a good opportunity actually one of the first days at the patella actually asked why is there not an RFC for OMP so a good opportunity to have one um the next one is very similar and we're talking about redundancy in this case so a site that looks like this which basically has two routers right and one router is connected to MPLS network the other one is providing some backup connectivity through some sort of an IP VPN technology it could be any flavor of VPN technology dmvpn GATT VPN whatever VP and X VPN technology that customers deploy very a very popular design of active standby approach active MPLS everything goes to MPLS backup is IP VPN some sort of a first hop routing protocol in here HSR PA vrrp whatever the choice is all potential layer 3 switch with OSPF and BGP pretty straightforward the migration into XE Sdn is as simple as the case before is that both routers upgrade it obviously there is a way to do this one by one and my personal recommendation is to make it simple the simpler the better take a downtime on that site schedule a maintenance upgrade both routers let the control and management come online have that site fully migrated into SD when we're going to talk in a few minutes what happens to backwards connectivity to non-st when site but leave that for a second the actual site itself software algorithm both boxes and again first hop routing protocol vrrp today and OSPF bgp nothing really changes right it's a same same philosophy that you had before just now under the control and management plane of Sdn so we'll be very transparent with you with this question upgrading code on production routers especially you know big chassis switches and that sort of thing scares me sure not because it's not necessary but because it doesn't work all the time and you know it's two o'clock in the morning in a datacenter I hate doing it I do it I hate doing are you seeing a lot of just great success with upgrading the code to the iOS xes dewayne code and don't know significant issue um what so I share your concerns I was a network engineer and many years ago but production today is it a simple oh ok so the upgrade the before well that's a good question is it yeah so the the upgrade process itself is not dissimilar from a traditional router upgrade because this is the before is no ESD when present yet so I have to use my existing tools however I braid my routers does that you know bring in USB stick and plugging it to the usb port copying the file into boot flash changing boot parameters and rebooting maybe I want to do TFTP and upload this to the boot flash reboot so however I do this today the before is however people do this today once it's upgraded then the control and management stack kicks in and then I have we managed to do any subsequent upgrades within the st1 now I agree to your point the only thing I can say is that there's an operation on discipline um you know filed a change control doesn't work rollback right so there's there's very little to be said about that it's a software upgrade with all these sort of you know things that come with it it's if it's successful and I very I'm very confident that it will be cessful but if something goes wrong you're all back that's where you have the maintenance windows for right so very there are design scenarios which unfortunately we don't have time to talk about that are more complicated and actually run the sd1 and non Sdn intelligence at the same time so you can be sort of like both you know both worlds and you can say is it it was that successful was that not successful I still have connectivity if it's not successful and so maybe shortens the maintenance window a less interruption and we have those designs and we'd love to engage with individuals that want to learn about those designs obviously they're a little bit more complicated require more skills around routing and interoperability between overlay and underlay so it tends to be more complicated doable but tends to be more complicated trying planing release migration guides were clients using i1 with JP in the end VPN wants to move to that because that's gonna be good question yes there's a slew of Cisco validated designs we're working on and it's a work in progress um specifically for a software upgrade we already have a lot of resources there's a there's a document that describes how the migration occurs not as migration from a system like I went into a system like Cisco Sdn but more like how do you perform an upgrade there's video recordings about this so for that specific piece of a software upgrade and we have that out there in our documentation and YouTube channel um but as a system migration from this to this I'm gonna touch on that in slide or - yeah but CVD is a work in progress - exactly accommodate all of those scenarios migration tool yes this is a good thing for a mess yes so for configuration migration we have a tool that basically um you input your existing configuration from the copy paste your existing configuration from the router and it's then you can link it into your V managed instance it basically analyzes the configuration says which which lines of config are not compatible with Sdn flag those and it's going to ask you to remove those and then after everything checks out from the config it will actually reach out through API calls into the V manage and create all the configs inside v manager so there's a config tool that helps with that transition you said that we have to copy/paste yes there is no way for the tool to connect directly to the router and not today and check the configuration yeah today it's a it's a very fair point working on it um but today there's no day of automation and right so the the thing is with traditional router you have you either have to SSH to it and then you know suck the config and analyze it so it's it's possible but today that config tool is taking a little bit more of that manual approach you as an administrator it's a direction that absolutely yes yeah the idea is to explore the direction of quote-unquote like sucking the config out of the existing router running through the logic analyzing spitting out we manage templates thank you sure in some of the cases we have routers that are either a managed router um which is this gray out guy actually it's this to begin with right it's a manager outer and you can't really upgrade that because it's managed by a service provider and they may not offer this questi when is a service and but you still wants his quest event is a service to keep the barrage router and you build sd1 on top of that right that's one option the second there could be some unsupported feature that would prevent you from upgrading this router that's just voice for example today um or there could be things like underlay backup which is kind of an advanced topic so what you do you basically don't touch that router you add the router it's an additional box that you add into the site to keep what you have today and you add an additional iOS X CSD one box into it and that box will build an SDN fabric on top of that it's very corner case and a couple of ifs and if those ifs exist then you have no choice and that your solution is to add an SDN intelligence side by side to existing router intelligence not my first choice but if you have to do it potentially that's the ether musician strategy though you it is yes you are you slowly start moving exactly afterward you can do that too yes but I share your facial expression that it's not the best but when you have to then you have areas where that's really what you're gonna need to do because reasons yeah yeah yeah I'm not gonna touch on that but virtual branch I touched on that in the beginning fully supported en CS or any x86 box just load the vnfs on it you can do cisco a plug-and-play to bring it up in an automated fashion and so II guess it's the NCS right Ian CS and the sd1 vnfs on it potentially you can add additional vnfs such as one optimization V in a firewall V and F whatever vnf you want to add that it's a virtual branch solution right um as far as the interoperability is concerned and we really see data centers is the most optimal way to perform that that interoperability and that basically it boils down to routing you advertised Sdn subnets into the underlay you advertise the underlay subnets into SD when you perform their distribution of the two in the hub site which is the data center in a data center is kind of built like this data center core MPLS C II routers facing the MPLS oops apologists SD when routers st-1 headings facing the SD when fabric so we tend to look at that as a transition hubs many times this transition hubs are data centers and that's where the overlay and under limit there are designs where overlay an underlay can meet at every single branch so I have sync every single branch that can do overlay and underlay to an MPLS sites not something that we advocate we've seen a fair share of issues with that starting from the routing routing loops every branch office becoming a transit site because you didn't filter the routes properly turns into an ECM view problem how do I reach that other site oh it's hundred branch offices that can take me there which is not true so how slow things that could happen so we really see those data center data centers and those hubs to be sort of the anchor point now so how are you handling this is the hub is it just routing it's just routing okay so there's no magic tools or anything is gonna make this easier for me it's it's just more like a Cisco validated design right so you set up your routing like this to solve these yes exactly like when you had the MEP MIT ijp stop future or OSPF metric route really safe yeah it's basically two worlds meeting at the data center core right now for those customers who are a little bit more geographically distributed and they're saying I like this approach I like the way that you're kind of safeguarding me from you know shooting myself in the foot but I'm very distributed and you asking me about data center can I use multiple data centers of course so we have some customers that have done this in a distributed fashion when they have geographically distributed data centers so Americas Europe Asia and again routing tricks to make sure that we attract the traffic from a specific region into the local hub symmetrically from both Sdn and the MPLS right again it's a little bit kind of a more involved design but comes down to just basically routing interaction between an overlay and underlay so that cut those capabilities around routing protocols in amateur routing protocol support field-proven support that's it's critical in this case is it like this over this pattern I think we manage arranging the hires or MP preference or user needs to know that higher numbers with OMP is the best best bet right so it's when you are in sd1 world you operate by the sd1 rules which is exactly the OMP preference and really this one says to draw the traffic that I'm trying to keep this within the region I have this hub which could be the European hub and I'm trying to stay within Europe right I'm trying to say sd1 region in Europe and SD when or an MPLS region in Europe I want them to stay within Europe and that's exactly what it's doing is that it's setting the higher preference for the subnets in the MPLS region down and it's actually my question so do I need to set the higher preference or fraction the traffic should stay that so it's a good point um today within the tool um it's down to the administrator to actually set the proper configurations and policies to make sure that it happens and there is no tool that we offer the dust is magically for you there's potentially an opportunity for somebody to write an API calls and that would that would you know execute on a logic like that it's nothing more than a logic between templates and configuration configuration templates and policies to make sure that you execute on this there is no voodoo magic in here it's very straightforward networking right so if you're a network engineer you understand how routing works you can execute on that ok so I do have it I'll skip on that one but I do have a demonstration to show you and maybe I will take one minute to show you this from the configuration standpoint question upgrade you can if you have if you have a 15 minutes not to do anything but yes we actually have a videos out there that outline the whole upgrade process it has a lot of hits Hamza is one of the one of the presenters in that in that video humans Nicolai they teamed up a on that there's a video on YouTube you can watch it 45 minutes I believe 30 minutes yes and it walks you through prerequisites configuration a tool and the actual upgrade itself not really fun the actual upgrade itself is really nothing but loading an image rebooting and waiting everything else wants the ones once it's SD when device logic kicks in it's governed by the sd1 rules everything is centrally managed through he managed and so one thing I wanted to quickly show you is okay so this is the this is the V managed right if you haven't seen one this is the management tool right so one cool thing that we're doing is many many of our customers are kind of the simple customers so they don't look for a lot of complicated way of doing things right and so we said okay how can we simplify life for the easy deployments right I just want to spin up a couple of or maybe a lot of sites but they're really simple I'm not looking for anything extra elaborate or things like that right if I want to do those like crazy things like regional hubs and things like that obviously I need to be a little bit more involved but if I'm just trying to spin up something simple so how can I do that so we have a really simple thing in here that we call a network design so when I log into this I can create basically this tool allows me to visualize my configuration of the of the network so clouds are my transport and then I can go into the manage network I can say I want to add a branch and I can say this is redundant branch and I can say this is my private router profile and I can say what type of the router there is and these are all the routers we talked about and I would say which circuits it's connected to so this is going to be connected to MPLS great I want to add another profile and I want to call it a public router profile I will choose the same the same type of the same type of router there it is and say this guy connects to the public network and obviously I messed it up okay but I would have if I would have saved that basically what I'm doing in here I'm creating this flow of templates or sort of the configuration of the templates but instead of me sort of going and defining things in more detailed way I just have this really simple flow of defining what the router is which piense are in there which interfaces that are in there and it's all kind of a wizard driven next next next next at then it saves it and you can apply this configuration onto the air onto the routers right so one of the operational enhancements that we're doing within the V manage that really streamlines this simpler deployments okay I'm getting the sign and can you do all of this programmatically absolutely excellent question everything you see on this GUI can be invoked through REST API calls anything so we have some customers that have an appetite for doing that absolutely you can automate anything that is beyond what you see in here you don't like the way we do it you want to do it your own you have your own GUI you have your own operation portal that you have for your ops team be my guest have another website with no Python scripting and API calls is your GUI and API consumer absolutely the API everything we do in the GUI is basically the same API calls that you can make to an to the managed server

Channel: Tech Field Day

Views: 33,845

Rating: 4.8834953 out of 5

Keywords: Tech Field Day, TFD, Networking Field Day, NFD, Networking Field Day 19, NFD19, Cisco, SD-WAN, Automation, Security, IOS, IOS-XE, SaaS, Office, Office365, Office 365, WAN, IWAN

Id: qB36GUhR6TE

Length: 41min 25sec (2485 seconds)

Published: Tue Nov 13 2018