Cisco CCIE Security 350-701 – SDN Models – Architecture Part 3

5. Overlay Networks

Next thing we’ll try to understand about the overlay networks. Now the overlay networks are definition wise we can say it’s a virtual network which is being built on the top of your underlying networks. Now what this exactly means is like in general in the previous we have discussed something called underlay network. Like in the underlying network we are going to provide the connectivity, that something we do and then we’ll be conferring all the links with an L, three links and then we will be conferring some kind of routing protocol to provide end to end visibility that is your underlay network. Now, once we set up the underlying network, now when the traffic is being forwarded from one point to another point, it is going to use one specific path.

So like let’s say this is something is a path which is being used. So logically this path will be represented as your overlay network. So the overlay network is something can be described as a dynamic path which is going to be programmed by the controller. Again which path it is going to use. That is again something decided by the controller. So we do have a controller and this controller is going to instruct the devices or share its requirements or give some instructions to the devices depending upon which model you implement.

So based on that instructions or based on that requirements it is going to use a specific path and that particular dynamic path which is being programmed by the controller. We call this as a virtual network or the overlay network. So in the overlay network, as I said, the Sdn controller is going to control which is going to decide what will be the forwarding path to be used based on the requirements or based on the dynamic policies.

So for this overlay network to work, of course the back end you must have an underlying network which is being built means underlay means remember IP end to end reachability overlay means the actual path which is being used by the used between the two endpoints in your network. You can take a simple example to understand more better like you have a server one or maybe a PCA is trying to communicate with the PCB. Now the actual path which is being used is decided by the controller.

Now we do have a controller here. Now this controller is going to have some kind of policy and that policy says the traffic which is going between this particular devices, these two devices when they are trying to communicate between these two should use this path depending upon the policy requirements. Like you can say the policy, you can say there is a quality of service policy where the communication between these two devices must have minimum of let’s say 150 KB of bandwidth. Let’s say that might be the requirement or the delay, the delay between the two devices must be minimum this one. So there are some application requirements. Depending upon that, the controller is going to decide what will be the forwarding path used between any two devices. So again, we need to understand that the underlying network has to be built in order to provide the overlay network communication. Like the virtual path or the virtual network must have an underlying network or the underlying network should be present.

Now, some of the examples we can use practically like the concept of VRFs, if you take in the case of VRFs, VRFs is a concept of having a virtual routing table for each and every customer. So physically this is the network which is being built by the service portal. But still each and every VRF or each and every customer will have a separate routing table. So there will be a separate path or it looks like as if there is a separate logical connection between the customer A to customer A sites, as well as customer B to customer B as well as customer C to customer C. So the MPLS, VPNs or the VRF, they can be logically considered as an overlay networks. One more example. We can assume there is something called VX Land. VX land stands for virtual extensible land. Now this is the same like your land connections. Like we do have something called VLAN. Now we know the concept of VLANs in general. Now VLAN is like you have a VLAN Eleven user here and we want the VLAN Eleven users should be able to communicate with the VLAN Eleven users here.

So generally what we’ll do is let’s say this is on switch one and this is on switch two. We connect some L two link, let’s say L two link and then we configure something called trunk link which is going to so this is typically an L two link normal switching I’m talking about. And using the trunking concept, we can allow the users of one VLAN or the same VLAN to talk to the same VLAN over the trunk link. You know, the concept of trunking again. But whereas the VX land we are trying to do the same thing exactly. We are allowing the users of one VLAN, let’s say VLAN Eleven here trying to communicate with the users of the VLAN Eleven on the other side of your network.

So this can be an IP network over something called L three links. So we are allowing the land encapsulation. This land encapsulation is being done over the L three network. Which means we are extending the same concept of the VLAN over L three network.

6. SDN Fabric

Thing we’ll try to understand something called Asian fabric. Now this Asian fabric refers to the actual physical infrastructure which is being used to build the underlying network. In the previous sections we have discussed about the underlying network. So in underlying network is nothing, but we are going to provide an end to end IP reachability between the two endpoints. Any two endpoints you have reachable. Now in order to provide this reachability you need to have some kind of connectivity. Of course you need to have some kind of devices as well. So the physical infrastructure is technically referred as Sdn fabric. Now the Sdn fabric, we can say the normal switches, routers cables or the links or the parts probably this all comes under the SGN fabric. In general there’s a technical term again used. But now the question is like okay, how they are different from the actual network which are being used earlier. And the network device is what we use here.

Now the major difference is the resident fabric. The fabric is going to refer only to the devices which are used inside your underlying network. Again, these devices can be programmed or controlled by the Sdn controller. So which means we will be having some kind of controller running in your network and this controller is going to give the instructions to the devices. Now these devices are referred as a fabric and these devices are going to forward as per the requirements or as per the instructions given by the controller. Now the previous networks, like in the traditional networks, we don’t have controller and these devices are technically forwarding the traffic on their own and policies, everything on their own.

But the difference is we refer with a fabric term for the networking devices which do support your architecture, the Sdn architecture or the Sdn controller architecture here. So whatever the protocols we are going to use, whatever the languages which are going to use on the controller and these languages, these devices also will understand the protocols they do understand so that they can talk to each other. Okay, so they should support the same language or the protocols which are being used, which means like whatever the protocols I’m using here, the controller protocols or the controller language, these devices also do use the same protocol or talk the same language.

But again, another question is like what if my devices do not support so basically if your devices if they don’t support the language, probably to talk to the controller, basically there is no communication again. So there are two ways. Either you need to have all the devices in your running in your network should support the protocols or should support the engine architecture. Means they should be able to listen the messages or they should be able to read the instructions or they should be able to talk to the controller or alternatively in some designs you can still have the edge devices probably, let’s say we got some edge devices. Now this edge edge devices can be a capable of Sdn controller. Capable means they do understand and talk.
So whatever the intermediate devices you have, you can still use the existing old devices which may not support or may not be able to talk to the controller. So typically that is one kind of design you can follow. But again, technically when you are planning any new infrastructure in your network or in your company, you always go with the routers or the switches which to communicate with your controller. So that is something you need to understand. And finally there is one more thing. We need to know that the links connecting between the devices will always be multiple path and they do support the equal path between the destinations. Like take an example, I do have a device here and maybe here. Now, to reach any two devices you have multiple paths between them, like you can see here, as per this topology, I got one path from here.

So again, as I said, between any two devices you need to have some kind of multiple paths like here to reach between these devices. We do have a path from this side as well as you can go from this side or maybe you have multiple paths in between. So this way you can provide some kind of redundancy at the same time if both the links are working, you can also do some kind of load balancing. Now most of the time it is not always possible to have multiple paths between the devices, but the fabric is going to assume that we do have multiple paths.

So when you have multiple paths, there is a possibility that you can still do load balancing. Now with that we can improve the performance between the devices for communication and most likely the fabric is going to assume that all the connection between the devices, they do support the language or the protocol so that they can communicate back to the controller and they do have a multiple paths to reach the destination.

• Category: Uncategorized