You may be familiar with the words “SDN,” “SD-WAN,” or “SD-Access.” SD stands for Software-Defined. So, what’s up with all these Software Defined technologies? What do they do? What pieces and parts make up a Cisco 500-470 ENSDENG SD solution? Let’s see.
Table of Content
SDN
Let’s imagine some traditional networking devices like routers and switches, beginning with the Software Defined Networking or 500-470 ENSDENG SDN. They have three different planes of operation. They have the data plane concerned with getting a frame or a packet in one interface and out of the egress interface as quickly as possible. The control plane is where our algorithms run. For example, a router is going to run OSPF on this plane. The switch might run a spanning tree protocol of this plane. These are the planes that populate the tables that will be used to forward data by the data plane. When administrators go to configure a router or switch, we interface with the management plane. We could secure the shell into a switch to do some configuration. We’re coming in on the management plane.
Now, let’s look at Software-Defined networking and see how this can radically shift our daily perspective of managing our devices. The model that we just known as a distributed control plane. It means that the control planes of these devices are distributed in the machines. In other words, each device has its own control plane. However, with an SDN controller or a software-defined networking controller, we can take those control planes from those devices and run them inside the SDN controller so that the appliance in charge and any updated information are pushed down from the SDN controller to those devices. That communication is using something called an API or Application Programming Interface. We typically say that the API going from the controller to the device is a southbound interface. Consider a compass. South is usually down, and when we draw out an SDN network.
Now that we’ve centralized our control planes in the SDN controller, we’ve migrated from a distributed control plane to a centralized control plane. Now, when I say, “We have an API running between the controller and the device,” what’s an example? Well, there’s an industry standard called OpenFlow. Cisco 500-470 ENSDENG has its own proprietary version called OpFlex. Those are some examples of southbound interfaces.
As administrators, the advantage of this is that we can do intent-based networking. Express our intent, such as I want to treat video traffic this way, treat voice traffic that way, give this application this level of security, etc. We express our intent by not going to each device and entering the correct commands on each device. We express our meaning through an application. This application talks to the controller using an NBI or Northbound Interface because the applications we draw are above the SDN controller or north of the controller. These are going to be called NBIs- northbound interfaces.
Here, we’re not talking about OpFlex or OpenFlow. We’re using something called REST APIs. REST stands for Representational State Transfer. What does that mean exactly? It means that we’re using HTTP verbs like you would use when interacting with a web page to send information to the controller to retrieve data so you can see the status of a router. The information being sent using these HTTP verbs needs to be formatted in a certain way. One of the popular formats is JSON. JSON stands for Javascript Object Notation.
WAN
Now, let’s look at SD-WAN, which stands for Software-Defined Wide Area Network. To understand the benefits of SD-WAN, let’s first consider a traditional WAN. Our headquarters location has a connection to our remote sites via a conventional wide area network. There is typically a data center on the primary side. We could use a variety of 500-470 ENSDENG WAN technologies to do that. Here are some examples– We have MPLs or Metro Ethernet, and because we were going over a single circuit from one site to another, we had a very predictable performance. We could configure security on those endpoint routers. A disadvantage is that if we wanted to go out to the internet, we might be forced to go through that headquarters location, or perhaps we had to do backhauling. Maybe we had to go to the data center for a security check, return to our remote site.
With Software-Defined Wide Area Networking, many applications are migrating to the cloud. We’ve got Amazon’s cloud, AWS- Amazon Web Services, Microsoft Azure, Google Cloud, and Dropbox. Cloud-based applications can give us security, quality service, and a predictable performance experience. We don’t need to do any backhauling back to the headquarters. If a remote site wants to go out to the internet, it can go straight out. You should understand here that we might have various technologies interconnecting our sites. I’ve got three places in the above picture, but things could get much more complicated in larger enterprises.
For example, consider the above topology with a few locations, and you will see how these devices are physically interconnected. We call this the underlay network, or we might refer to this as the physical infrastructure. But with SD-WAN, we can define our topology. In other words, we can express our vast area network connections. I want a link from the upper left office to the lower right office and a fellowship from the lower left office to the upper right data center. And I’m still determining what the performance will be because I’m still choosing which path I will take. What we can do with SD-WAN is put a virtual topology on top of that physical topology. This is called our SD-WAN overlay network. This is our virtual infrastructure where, from the perspective of these routers.
In reality, they may be going through multiple other routers in between. But it doesn’t look like that to them. Because what’s happening here is we have virtual secured tunnels that are set up through the WAN. We’re not going from router to router and configuring things individually. That’s one of the advantages of those control plane functions. They no longer have to reside in the routers. We can perform these tasks within our SD-WAN controller. We can have various physical wan connections– cellular to Metro Ethernet, cable modem, MPLs, etc. As long as we educate our SD-WAN controller about those technologies, it will take care of it. It will send out appropriate configuration commands to our routers. It knows what’s available on those routers, so it will give us that security quality of service and predictable performance we had with those traditional point-to-point connections.
SD-Access
Next up, let’s consider SD-Access. At this point, we can consider SD-Access as an advancement or a replacement for traditional access control lists. Let’s take a look at some of its features. Cisco tells us that SD-Access is the next generation in policy enforcement. Instead of having individual access control lists that say this IP address can go to this other IP address using this TCP port number, here we will use security group acls. So, rather than identifying someone based on the IP address they’re using at the moment, it’s based on their identity. Their identity will be known on the Cisco 500-470 ENSDENG ISE, the Identity Services Engine. Like our other Software-Defined technologies, we will be virtualizing the physical network. We can have multiple virtual networks, all using the same physical network, and we can give different virtual networks different policies.
Let’s consider a basic example of using a traditional ACL where we are manually configuring access control. First, We have an access control list that says we want to permit PC1 with an IP address of 192.168.1.100. Then We want to let that IP address go to the server, which has an IP address 192.0.2.3. We want it to go to that server using a TCP port 443- the secure HTTP port. Router R1’s ACL will allow that traffic without any issues. But what if that user takes their PC, or it’s a laptop they take somewhere else in the building or the enterprise? What if they suddenly connect to a different subnet with a different IP address? Here, the IP address is 203.0.113.125.
Can you see with today’s more mobile workforce, it will be harder and harder to limit or grant access to resources based on ACLs? Instead, enter SD-Access. With software-defined access, we’re going to have security groups. Above, we have a security group called IT, with some members– Kevin and Charles. The Cisco 500-470 ENSDENG ISE, the identification Services Engine, is for define each member’s identification.. Instead of having a regular ACL that permits this IP address to go to the HTTPS port on the server, here we have a security group ACL that helps the IT security group to go to that port. Here, I’ve logged into PC1 with my identity of Kevin, a member of the IT group, and permitted to get to the server.
Now, let’s look at some of the pieces and parts of a Cisco SD-Access solution. Again, we’ll break this into different layers, beginning at the bottom of the physical layer. Our actual infrastructure equipment comprises the physical layer. Here, we might have routers, switches, and wireless line controllers. Up at the network layer, we have both the physical underlay network and the virtualized network that lies on top of the underlay network. The SD access overlay network. We refer to this as our virtual fabric at times. If we move up to the controller layer, we see the Cisco DNA center, which will send instructions using those southbound APIs out to our devices. That’s going to live at the controller layer.
Cisco ISE, which grants permission for different identities, is also in this layer. The GUI of the Cisco DNA center will serve as our interface for managing everything. That’s up at the management layer. And all these make up the Cisco 500-470 ENSDENG SD-Access solution. I hope you’ve gained detailed knowledge of SDN, SD-WAN, and SD-Access, their functionalities, and their build. That’s it for this one. Thanks for onboarding.
