Cisco CCIE Security 350-701 – Application Programming Interface – API Part 2

3. API – With SDN Networks

Okay, now probably in this section we’ll try to understand the role of the API in Sdn world of networking. Like in the previous sections, we have already discussed about the APIs and the types of APIs and how they are going to allow to talk between the different applications with some examples. Now, with respect to Sdn, there are two primary uses of the API in our Sdn networks. Now, the first thing is the applications. Probably the applications need to communicate with the controller. That is where the API will be used. And also we need to make sure that the controller should be able to instruct the networking devices. So again, there is an API used. So technically we call the APIs. On the top is northbound API. I’ll talk about more detail probably in a separate video. Probably here the northbound API, the application to controller communication and the controller need to talk to the networking devices as well. So what exactly they communicate.

Now, let’s say there is an application requirement, or maybe the application refers to some kind of management software which you are running. Or maybe some kind of management software running in a Gui which is going to instruct or tell the controller what is the requirement or what is the bandwidth availability. This kind of requirements will be shaped by the controller. Now, this application wants to talk to the controller. Like here, the application is typically talking to the controller saying that I want the information about the network, let’s say. So how exactly the topology looks. I want the information about the network, how many devices are connected and what are the different types of devices, how they are connected, probably that kind of information. Or maybe the application wants some kind of configurations need to be pushed to the end devices.

Okay, so now this application need to talk to the controller and say that okay, I want the controller. Probably I want you to push these configurations on a specific device. Maybe you are adding a new device here and this new device will be added with the specific configurations automatically. So in this scenario you need an API again. So API is required so that the application can talk to the controller about what exactly it wants. Now, once after that, the second one is the controller should be able to talk to the networking devices, should be able to communicate with the networking devices. Again, there is another APIs and the type of APIs are used. Technically we call them as southbound APIs. Now, these APIs are just like simple examples. We can say like what will be the CPU of individual devices? So I want to get the statistics of the CPU utilization of individual devices or maybe some kind of interface status, what is the status of the interfaces or what configurations you are going to apply.

Or maybe you want to apply some kind of security policy and you want to tell to the devices that okay, hello devices. This is what our new policy is and you need to restrict this specific traffic. And this is what you need to apply the ACL, probably the security policy you need to apply for that particular selected traffic. Or one more example we can say, okay, so if any traffic is going from this PC to this PC or this Milan, to this Milan, probably you should be using this path. This is the path you’re supposed to use. Or maybe this is something the bandwidth what I want.

So based on that, again, you can have some kind of dynamic quality of service policy. So the main job of the API here is simple. The API, the application which is used for management, maybe the concentration management should talk to the controller. There is an API required and the controller need to talk to the networking devices. There is an API required over there. So we hear also the same thing happening. The two different applications are going to interact with each other with the help of API here. Now, the next thing we’ll see now in order to communicate one thing you need to remember the dependency or at the back end, you must have some kind of IP network build and you must have some kind of reachability because technically the application may not be running on the local controller, maybe may not be.

Now this application need to interact with the controller and that is only possible when you have an IP network or when you have a network build and you do have a reachability between them. And the controller can only talk to the networking devices when you have a reachability between them. And the most common method used for that is Http request. So most of these APIs works over Http request. We’ll talk about more later on. Like rest APIs, we’ll be discussing in the next section in detail what are the different types of requests they use in the back end. And one more thing is like the communication process between the client and server. Or we can say the communication process between the application and your controller. So there will be communication process.

This communication process is more like the server client model. So server client is just like you go to the browser and then you type in some kind of URL, some XYZ. com, and then it is going to connect to the server and then return back to the web page. Now this is more like a client. The device or the browser which is requesting will be referred as a client requesting for the website. And the one who is offering you the particular website probably that is considered as a server. So you can compare this similar to this one, almost similar to this one. Like here. Also the device which is going to request, like in this example, the application is going to send out a request or share its requirement, what exactly you need to do with the controller. So in this scenario, this will be like the client which is going to send out its request. Like, I want the information about the network, or I want this configuration should be sent to the network.

Or it can be like, show me the topology information, how exactly the topology looks, something like that. Now this is going to be your server. Likewise, when the controller is talking to the networking devices, now this is going to be the client and the networking devices will be like the server again. This is the second one. So maybe the controller is asking, hello, networking devices. I want you to display your CPU information, I want you to display your interface status. If there changes, you need to please update me. I want you to apply this security policy. Or maybe I want you to apply this quality of service policy. So the communication process between the two here, in the case of SGN it will be a little bit different. So the application to the controller and the controller to the networking devices will be completely based on Http request.

4. NorthBound API

The next thing we’ll try to understand about the types of API like northbound or southbound API. Now, with reference to Sdn networks, the APIs can be either northbound or southbound. Now, this is completely depending upon the relation of the position of your controller in your topology. Now, the northbound APIs, as we have already discussed, up the communication, the APIs used for communicating or talking between the applications and the controller, we refer them as not Bond APIs. So let’s try to see more about the northbound APIs. So as I said, the northbound APIs or the Link or the one which allows you to communicate between the applications and the SGN controllers. So we already discussed, the SGN controller is responsible for having a separate control plane. So we do have a separation of the control plane inside the SGN controller.

And this controller is going to send out instructions or send out instructions to the devices. Of course there is softboard API and the applications are going to send out the requirements. So probably the requirement is going to be shared with the controller. Now, the application can actually tell the network, tell the controller what exactly they want. You can think about some of the examples like the application is going to request saying that I want all the devices information on the network. So that can be one example. Or maybe the application requires the information about the capabilities of each and every device, or the interface status of each and every device. Or it can be the current state of each and every port, whether they are up or down. So what is the actual state of each and every port on that particular device. Or it can be like topology information, which device connected over which interface to other devices, how the topology exactly looks like.

Or it can be like other device information, like what is the IP address configured on those specific devices, what are the different VLANs configured in your network? Probably these all information, these are all these things the application can actually tell the controller that I require this specific information. So these are some of the examples where the application is requesting the controller that I want to get this information. Now again, the application may be residing within the controller itself. So application means it can be residing on maybe on a server remote server or maybe running on a VM. Or maybe there is also something like application may be running inside the controller itself. So I’ll talk about more on that. Probably we’ll see how the control in the application actually separates later on. Now here I got some of the examples of a couple of examples of the northbound API. There is something called simple object access protocol and the Rest representation state transfer, which is the commonly used API.

Especially in the Sdn networks. Normally if you take an example here, the applications which are commonly used in any network like if you are going with some kind of website designing or website implementation. What we’ll be doing is we’ll be using different programming languages like let’s say you are using some kind of Java or probably. net or PHP. So probably these are some of the applications which are commonly used in programming programming languages, in different programming languages we use not only in website, in different other ways. Now, the problem with this application is they’re actually a bit complex because they’ll be using some kind of coding and that is a little bit more complex like to interact between the applications. So what we are doing is probably we are not going to use the same complexity because we don’t want to have the same complexity here as well.

So we’ll be using some kind of simple programmable applications. So some of the examples here the Rest API which is commonly used. So this one. Soap. Soap and rest. API. Now, this soap API is majorly based on XML Protocol. So most of the request from the application to the controller goes based on the Http request. As I said, we call them as Web Service APIs and the code or the format of your data will be sent in XML format. XML is again kind of language, XML language which is kind of medium to exchange the data between the application and the controller. Okay? So it uses some kind of simple XML language for exchanging the data and the coding between the application and the controller. Or we can say between the applications, applications inside the controller and this application probably between them. Now, another example, we have something called Rest API. Now this Rest API is the most commonly used API with respect to Sdn networks. It again uses web service API similar way like your web request, it uses some kind of Http request between the applications and the controller. Probably these are like northbound APIs, mostly used on the northbound side for interaction of applications with a controller.

As I said, with respect to Sdn, these are some of the most common web service APIs used here. So most of the time in the Sdn networks will be focusing more on Rest API. Now again, what they use the same use Http and API framework for communication between the application and the controller. And the main advantage of the Rest API why it is majorly used because it utilizes very less bandwidth. Now that is one of the advantage when compared with this one and it makes you more suitable for efficient internet uses, especially if you’re running two different applications on the Internet. Probably this is going to be a very good option because it uses a little bit lesser bandwidth while it is requesting the information over any network. Now, majority of your controllers, majority of the controllers of the vendors operating the controllers and the network automation tools, probably they use this Rest API so that the applications talk to each other and exchange information.

So as I said, it is better than this one, the previous one. So Apso which uses lesser bandwidth and it is more efficient or more suitable for applications over the internet. Now, some of the vendors examples we can consider as we have something like Intent API which is from Cisco. Now this API generally there is an example called Cisco DNA Platform which is completely based on the Rest API. And from Juniper there is something called Contrast which is again uses the Rest API. And it gets the information by using some kind of by interconnecting or interpreting with the open Cloud systems. And that is something what is used by Juniper contrail software. Now, probably with respect to Sdn networks, we will be majorly focusing on the Rest API. So I have a separate section dedicated, a little bit more detail on the Rest API and the functionality with more detail. But these two APIs are the common examples of northbound API.

5. SouthBound API

Now in this video we’ll try to understand the Southbound APIs. Like in the previous we have already discussed, the Southbound APS are responsible for communication between the controllers and your networking devices or the end devices. Whereas the Northbound APS, which we have covered in the previous section, they are responsible for communication between your applications and the controller. Now with the help of Southbound APIs, what we are going to do is we are going to program the data plane of the networking devices on how they will be forwarding. So if you remember in the SGN concepts we have seen, the actual networking devices will be doing the forwarding the data plane job. But whereas the actual control plane is going to be reside on the controller and this controller plane, this controller is going to decide the actual forwarding of the traffic via the networking devices. So that communication process is actually done with the help of Southbound APIs.

So let’s try to see some of the examples like what are the things it will instruct. There are plenty of things like the controller can say okay, use this particular route to power the traffic for specific destinations or for this application. Or the controller can actually send a request to the networking devices saying that okay, show me the interface status or the device capabilities. Or maybe the controller can actually send the instructions. Like this is the configuration you need to apply on specific devices, where it can initiate a CLI SSH connection onto the networking devices, or change the best route wire routing table, or changing the security policies or ACL quality of service. These are all the things including that. Now when we talk about applications like the Southbound APIs, there are different softwares used or different applications used to communicate between the controller and the networking devices.

Now these applications are the APIs can be either an open source or the proprietary, depending upon which controller you use and what kind of networking devices over there. So I’m going to list some of the examples commonly used APIs like the commonly used is like SSH and SNMP which are already used in network management. So some of the APIs, like from Cisco, Cisco Epic Enterprise module, this is going to majorly use the SSH and SNMP protocol to send instructions to the networking devices or to get the information from the networking devices. Apart from that, there are other options. Like there is something called open flow. This open flow will be using something called open flow protocol. So this protocol is responsible for communication between the controller and your networking devices, which means whatever the networking device is used here, they must support an Open Flow.

They must be able to understand the Open Flow protocol. They must support the Open Flow protocol in order to talk to the controller. So this open flow is something managed by ONF. ONF stands for Open Networking Foundation. It is an organization dedicated to provide some open standards and the HDM adoption. Okay, so you might be using this, again, depends upon the vendors or the devices or the controllers what you’re using. The other option is something like you have flex optics is something from Cisco. It is totally different from the open flow example which I have discussed here. So they sound similar, but they are different here. So this is majorly used in a Cisco environment. So if you’re using majorly a Cisco based network environment, you will be using this offLex API. Again, commonly used in the data center environments with ACI. So this is more than a Cisco environment. So it again relies on traditional distributed control plane mechanism in order to push the commands to the networking devices. And again here also, whatever the device is, they must be able to support this offLex protocol or they must be able to understand and support the of flex protocol on the networking devices so that they can talk to the controller. Now again, if you’re using something called software defined access from Cisco for managing the Cisco major land infrastructure or network infrastructure with Cisco SDA option, you will be using again SSH with a command line and SNMP protocol to gather the information or to push some specific commands.

Additionally, you’ll be using something called NETCONF. Netcon stands for network configuration protocol. So I’ll quickly give a brief overview on this. So Netcomp stands for, as I said, network configuration protocol. It is an IET of Standard so defined in these specific RFCs. And this Netcon protocol is responsible for communication between the networking devices. So specifically it is responsible for installing the installing the configurations. You can say or modifying the configurations or requesting some information from the networking devices or deleting the information or the configuration onto the networking devices. So probably you can summarize like maybe you want to collect the status of those devices or maybe you want to make any changes to the configurations, existing configurations.

Or you can also say like you want to take up the backup backup or maybe you want to do restore some specific configurations or maybe you want to run some kind of test your configurations before you exactly the same. In short, whatever the configurations you do remotely via command line, you can initiate them with the help of NETCONF protocol from Sdn controllers. Apart from that, we have something called Restcon. Now again, Rest on the same like Netcon and again it is used for programmability and data manipulation.

Now basically the goal of the Rest count is to provide you something called Restful API experience. Now, Restful API is nothing, but if you’re using Rest APIs, probably I’ll be talking about that in the next sections. So it is going to provide you something called Restful API Experience. So it still uses the Netcon for data abstraction as well as for data manipulations. And most likely the data format will be in either XML or JSON format. JSON is kind of JavaScript format again, so it is mainly used for defining some data storage concepts. Little bit.

• Category: Uncategorized