Automate APIs & Protocols

6. Data Models

Data models Sometimes it is referred to as a next-generation API. So now we have different types of APIs, for example, XML APIs and rest APIs. But still, we are looking towards the data model. Now, before understanding the data model, you can see the structure of the data model. So at the bottom we have the data model. On top, for transport, we have SSH and TLS. Encoding is done via the XML JSON protocols. That is going to be used is net con and we know that net conf is used inside S, T, and other Cisco solutions as well. We have gRPC and then the development plan and the app. Now this is the stack for the data model, and again, in the upcoming session you are going to learn more about the data model. So the main question here is why we need a data model. Although the CLI is doing well, we have used CLI for a long time. So the answer to this is that because CLI doesn't have any data model or structure inCLI, what we are doing is doing some requests, running some shore and command briefs, etc., etc. But we are not specific that the output that we will get will follow some sort of pattern. And since we don't know the pattern, after that we can't take those inputs, whatever output we have, we can take those outputs as input and then we can play around with those outputs. That's now not the case when you are dealing with the data models. So what will happen in this case, say, for example, Vlanit? So now let's discuss this data model and a few of the things related to data models. So, for example, when we are checking the VLAN,what are the attributes we have with the VLAN? Here you can see what the range of the valid VLAN is. So we have certain questions related to VLAN. So what will be the range of the VLAN? Can a VLAN name have spaces in it? Should the values be enumerated only to support up and down? Should the value be a string or an integer? So now we have different questions related to VLAN and now we can think, OK, how we can utilise VLAN inside the data model. Okay, so now in the future, suppose you go and configure the VLAN via the Ancient Playbook or maybe via Pythonprogramming, you will see that we have to put certain structures or certain input for the VLAN or any type of configuration that we are doing via data models. One common misconception is that the net conf or the rest conf are sending encoded messages or values. So as you can see, it's very important to understand that netconfgrpc is working as aprotocol still for encoding. Still for data encoding, we are using JSON format. That's very important. So maybe you can embed this JSON or XML inside your Python programme or maybe some other program. And then you can write a certain code that you will get the result. Okay? And we have seen these types of examples before as well. All right, so now what's our focus? Our focus is to check what the next generation API is. as well as next-generation API. We are talking about the robust model that is young. So let's stop you're.And in that section, we'll go over the Young data model object. Or we can see the programme as well.

7. Yet Another Next Generation YANG

The next generation is represented by young language. This is the foundation of the model-driven programming language, which was introduced in 2010. So now it has become quite mature and we'll see that various flavours are there. young model and then we can think of a non-young model. So Young is not only the model which is model-driven, but we have other models as well. So here you can see, if you want to learn more, you can go and check RF six to 20. It was originally built using the NETCONF protocol, but it is now also supported by REST conf. It is a model-driven So here you can see that you have multiple objects. They are connected and obviously, once you are calling one object, they will go and pull other objects from the hierarchy like that. That's one reason that will be used inside the programming as well. So young here, you can see that it's a formal contractlanguage with rich syntax and semantics. Obviously, it has quite a long list of semantics and it is supported by a number of functions or models. Again, in the lab section, I actually did the lab with respect to iOS XE. And in the lab section, you'll see that we have so many features that are supported when you go and check the Young model. I even have my CSR device as well. So let me quickly log into the CSR device. I'll go ahead and enable the NETCONF, and then you can see the capabilities that we have. So let me quickly log into the lab. So I have my lab. Here you can see over GNS, and here you can see the CSI device. On the external network I have my IOS six devices that are connected. Here I have my network automation tool. So I can go here. Let me exit. I'm connected to the controller. Let me go and exit. Now I'm inside the network automation tool. What you have done on this CSR device is that I should go and enable the SSS first. So for that, you should go and enable the crypto key. So let me show you that crypto generates RSA modules 10 and two. I have done that first. Once you have this, you should go ahead and enable the netconfous and netcon for Young in iOS XE. So once we go and enable netconfyoung, then what can I do? Let me quickly see the IP address and I will go and log in via the young so we can go and check the capabilities. So now I can go to my automation tool and do the SSH. The username and password is Cisco. Cisco On this device I have configured, this is the IP and then the port, which we know that is eight for netconfuser, and then I can go and use net. Confirm is also Cisco. Now you can see the capabilities. So here you can see the full list of capabilities that we have with iOS XE. So it supports IP, local pool,multicast IPsec policies, even the SNMP MIPS,so many things that are supported. Okay, so let's quickly go back to the slides. Alright, so now we have seen that yes, we have the youngnet conf support in the iOS XE and let you see it in the XR as well, because this is the industry standard. So I ETF it and Open config. These are the open standard body.That means that most of the network vendors will support this. There is some common ground in between. Cisco means Cisco devices can support their own young network model. Or maybe they will follow the industry standard as well. Or maybe Cisco has their own custom model-driven programming as well. That we'll discuss in the upcoming session and in the upcoming recording. So here you can see that we have this industry and standard. It defines the open config group. Then we have Cisco common and nice examples that the OTV feature is common in the iniOS Xi and Nexus operating systems. And then finally, we have the standalone as well as the platform specific as well. And that is nothing but any type of feature that is supported only by Cisco. Again, remember two things. The first thing is that the young is not only one model-driven program. There may be other model-driven programmes supported in other locations. And the second thing is that we always have customization. So one vendor may have their own model, or he may have a common model in between them. So customization is there and other model-driven programmes are also available.

8. Model Driven Programming Protocols

From this section onward, we are going to learn and understand model-driven programming. Now, model-driven programming and what protocols we have now, we'll see in the upcoming slide. But the concept here is that everything will start with the main program. This model-driven programming and the concept of programming will be the same when we are talking about the hierarchy. So here you can see that you have the parent or the main program. So maybe the main function that we have in the language is like C plus plus, etc. In between those, you have the routine. So I have the chassis, I have the chassis ID, and then again you can see that you have the card number, and finally, inside the card you have the ports, correct? Similarly, you can think of model-driven programming as having a skeleton in which you have the main or parent node and then everything falls down at the bottom as a sub-program. We have discussed this point earlier that there is not only the model-driven programme, but we have the other model-driven programmes as well. One of the best examples is ACI, which uses a new type of model-driven programming but is still quite robust and useful. correct? So the point here is that we don't have only young model-driven programming, but there are others as well. At the beginning, Yang was usingNETCONF and the encoding was actually XML. Now young people can use protocols like netconf and encoding can be used as A, JSON, and XML, correct? So model-driven programming is the truth and there may be different model-driven programs, but the main concept here is that when we are talking about models, at that time we may have encoding methods like XML or JSON. And the protocols here, you can see that we have netcon rest on rest and gRPC. As a result, protocol may differ. And in the upcoming session, we are going to learn these protocols. Alright? So here you can see that we have protocol,Restcon, netcongrbc, and let's stop here. Next session onwards,let's learn these protocols one by one.

9. Netconf

Now, the next important topic we have is the net conference. So let's understand net conf and net con for network configuration protocol. At least one of the use cases for this, at least at this present time, is that if you check the Cisco SDWAN fabric, you'll find that the V manager inside the management plane is using netconfol to configure all the devices inside the data plane, or maybe topush the configuration to the control plane, other controllers as well, like via Smart. So that is one of the use cases. The other use case that I will show you here is that I'll go and log in to the CSR router. There you will see that we have so many capabilities related to network configuration. net conf is important because this is something called a transaction-based protocol. That means that if they do not do all the transactions, they will abort all the data. So until transferred, unless they will not say in between, if you have any interruption,they will not send the rest of the data. The second important point to note here is that the network restricts itself to having a candidate running and a startup configuration. So not only do we have the running and the startup configuration, but we also have something called candidate configuration as well. And suppose you want to put this configuration into this candidate configuration, so there is one command called commit. You can go and do the commit, although we have no commit verification or validate check, et cetera. So you can do commit check. Those things are also there, which means you're checking the commands that you want to put in. So somewhere in between you have some transactional data that is still not confirmed to be pushed to the device that will be working as a candidate running.We know that it is serving the Ramand startup and that it is in the NV Ram, correct? So that's the thing we have now discussed earlier, that net corp is a protocol. This is not your transport method. So the underlying transport is secure transport. We have the SSH. Why do we need net confidence? NetConfig is a new model for network management, and this is a transaction-based network management protocol that has much more capability than what we can do with SNMP. And SNMP has flaws and vulnerabilities that you cannot write about. The SNMP MIPS libraries are preloaded inside the operating system. There are so many things. The biggest problem we have with SNMP in terms of the problem or the restriction is that it's very tight and it's very much vendor specific. On the other hand, net comp is widely used because it under the data model, so it can be changed, it can be altered, and it is going to give you a number of capabilities that are not possible with SNMP, right? So, even if you compare the feature sets of SNMP and netcon, you'll notice that NETCONF has a significant advantage over SNMP. Now it can be integrated. The network can be integrated via an API. And in this lab we have seen that we are using the rest of the confessed API integration with Python. And you have seen how fast it takes the input from the centralised management plan. Correct. So NETCONF is the protocol that most of the companies are looking at, as well as a few that are actively using. Now, what are the other features we have in the net comp? They are transactional based. They use the client-server model. And what does it mean? I will show you in the diagram a follow-up diagram to understand this client-based communication or client-server based communication. Now again, I told you earlier that net conf is a protocol. So the encoding method is maybe XML, maybe JSON, correct? The transport and communication methods may be SSH. So you can see that SSH is the transport protocol for the client-server model. So these things will be there. The good thing we have with NETCONF is the flexibility and features and wide usability. Correct. So here you can see the protocol isstacked with the NETCONF and clearly we can see the protocol, the message, the RPC and RPC reply, the layers and the example. Already we have discussed that we have a gift. We have four methods. So in general, say Get, Put, Post, and Delete. So these are the methods we have, and apart from that, there are other methods as well. But these are the widely used methods within the risk API or risk full protocol. Now you can see, one by one, that we have an explanation about the protocol. So what protocol is it using? The list of the protocol is associated with version two of SoapTLS. What messages we have, although we have a list of messages, few of the messages are listed here, like RPC,RPC replied to the operations, what operations and how they are going to do the operations. We'll see that. As a result, this client and several communications will take place via SSH. Let me quickly show you that. Let me quickly log into the device and show you what it looked like. So here you can see that I logged into my lab and this is my automation tool and this is the CSR device. I actually generated the crypto key, and we know how to do so. You need to give the host name and the domain name. And then I have given SSH version two here and I have enabled two features, say NETCONF and netconfying. That's it. After that, you will get the syslog message that your NETCONF is ready to run. You can go and connect like this again. I have set the username and password as Cisco,but you can give any strong password. Now I am trying to communicate with the CSR device with SSH. Obviously, the underlying protocol is SSH, and now if I click into, you can see the capabilities that we have all the capabilities related to the netconfigured inside CSR We have the long list of features, so we have the data collection. We have the three OEM GRP enhancement poolentity. You can see the long list of features that are there inside the net confiscated. You can go and communicate again. We'll discuss more about this communication in upcoming slides. So, how exactly does it communicate? Config. Edit: Delete. Copy. Lock and unlock. Close session. Okay, let's call it a day. As the name suggests, killing means killing the session. "Close" means "close the session." "Lock and lock It's a widely used thing that you can go and lock the operation, or you can lock the configuration for some period of time, et cetera, then delete. Edit: Copy and paste. These are the normal operations that we are doing. Again, you can see the transaction method we have running a startup and candidate candidate means until you can go and do the commit confirm it will not be pushed to the device, it will be stored as an intermediate configuration correctly. Now, you can see how the communication is happening here: the client server model client will tryso my network automation is my client. He tried to send port number eighty-three with the SSHtransport protocol to do the communication with the server. What is going on behind the scenes? Here you can see the steps that I want to take to communicate. I just wanted to connect to the server. I will send my request and then the server will respond. Here you can see the SSH how I have done the SSH to the device. Once I send my request, I'll get the response with the capabilities correctand we have a long list of capabilities. Once you log in, you can see these are the capabilities. Some of them are listed here, but we have a long list of capabilities. Now the client responds to the supported capabilities, which means I want to run some capabilities, maybe EIGRP,maybe USPS, so now you can see the transactionis happening between the client and server model. The client is sending the query and the server is responding. So first of all, the server responds that these are my capabilities. The client is sending you what you're looking for. Okay,I'm looking for EIGRP or OSPF, and for that I can send my operational code, whatever code I have like get, put, post, delete, et cetera. But in netconf we have different things like get, edit, log, unlock, etcetera. And then finally, you can go and do the configuration. Suppose you want to do the configuration for any of the interfaces shut, no shutor any IP operations or IP related commands. You can go into it. So now you're sending the request for the configuration for the operation to the server and then the server finally sends the response to the client. Okay, And this will be the summary slide we have. So think of this as steps 1234 and 5 and how the client server module's underlying protocol, SSH, exchanges capability with the server. They have to do the configuration as per your operational request. You mean the client and then it will do the response. Okay, Alright. So this way, we can go ahead and do the configuration for the network. Let's stop here.

10. Restconf

Rest conv is the next protocol. Now, let's suppose if we understand NETCONF and if we know HTTP, then Rest Conf is a mix of both. Now again, just to revise the things, if you go and check what the protocol to call is NETCONF, what's the data model we are going to use as young? Now what's the transport? So transport may be different. In this case, we have HTTPS, but we may also have TLS, SSHP, two HTTPS, etc. For what's the encoding method? We have XML and JSON. If you go and draw the stack, So here at the bottom you have a saved data model and then you have transport. Now this transport may be SSH, maybe HTTP, maybe TLS, then you have the encoding method. So the encoding is nothing but your XML, your JSON. And then we have the protocol. The protocol we are talking about at this point of time is RESTCONF and it is a mixture of HTTP and net conf. So, in the diagram, conf plus Https becomes Rest.Conference. We have a study that is true at this point of time. Now, if you go and compare the risk and net count,then we'll see the same thing that we are doing with the net count. The same thing we are doing with the rest of the name is different. Some syntax will be different. Obviously, what methods do we have? So here you can see the list of methods. We have methods that mean that there will be much that we are doing with web browsing. So we have to post, put, patch, delete. "Get" means the same as the "runningshow" command in Cisco devices. "Post" means we are creating a new object. Put means you are updating the object. Patch means you are margin. In object oriented programming, delete obviously means delete the object. And then we are doing various operations. Now, let me quickly show you the difference. So, I have the difference between the operations of NETCONF and the west conf.Clearly, you can see that get is getconfig, post is edit, the operation is create, which means create, replace, merge, and delete. Line to line, they are very similar. We can understand that both are in parallel. It depends upon which particular platform is using what type of protocol. So, for example, if I go and take the example of St Wan, I can go and take the vanage, that is my management plan. And then I can open my API dock. Here you can see in the example that Getmethods related to CSR restaurant API configuration are native. So what this API will do is like that. I'll show you the quick example related to the Wemanagement API and the Wemanage API, how you can retrieve the data, how you can read that data, how you can run it, and how you can get the output correct. So what is the method that we can go and build with our restaurants? And so we have a Python tool, we have Postman. We have Firefox rest client. These are the tools we have but we see that most of the management plans have inbuilt integration with some of the API tools and from there you can also go and run with the help of your web browser. So let me quickly go to my view manager web browser. I'll show you how we can execute certain APIs alright. So here you can see I have my view managed and I can go back. I can go and do API docs. So I can reach the API inside this API doc. I am very much interested in building and running an API related to monitoring related to interface monitoring, so I can go ahead and search for real-time monitoring and enterface. Now you can see that you have the monitoring and if I can scroll down you can see the model is schema and you should put the devicename or device ID and then here you have the methods. 200 ms x 400 macros 403 forbidden 500 These are the few quotations. Now here I have the query API, so I can use this query data service API and I can paste it here in the web browser. Although here you can see the response is 200, that is successful, and then you can see the headers and you can see the data well. Let me quickly run here in the web browser and once I run here you can see the output. The nice thing about this is that I can go to the header and then I am looking for a certain interface and the status of that, so I can go and filter it. If you can see clearly that the interface is gig one with respect to this device is up, zero is up. Two is up like that. You can go and filter if you go and check the name, so you have various things like this is DC one and this is the interface. This is the device IP but apart from that you have so much good information. If you're looking for RX and TX packet, you can go and check the TX, you can check the RX and likewise, OK, so you can see how easy it is to run and get the output. We are doing the API call, so this is very much machine to machine interaction. We are executing the API and then we are getting the result.

ExamSnap's Cisco 300-435 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Cisco 300-435 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.