Describe Software-Defined Networking

0:00Welcome to describe software defined networking, and by the way, welcome to this whole course on software defined access in DNA Center. Cisco's software defined access or SDA is a software defined networking or SDN solution, and if we don't understand what SDN is then we're going to have a hard time understanding what the goals of an architectural like software defined access really are. And so throughout the course of this series, we're going to take a look not only at defining what SDN is and the benefits, we'll also take a look at the variety of Cisco SDN offerings they have available, because SDA is not their only one.

0:31So come along with me, we'll have a lot of fun exploring SDN and what exactly that is. And with that, I will see you in the next video.

0:00I used to joke that SDN stood for still don't know, because we didn't know what SDN was supposed to be. And that was true back in the maybe mid 2010s, because early on, when SDN was developed, everybody had a different vision for what it was supposed to be and what it was supposed to accomplish. But these days, fortunately, we do know what SDN is. And so in this video, what we're going to do is explore exactly where SDN came from, what the general idea was behind it, and then where we are today with what SDN is. Let's dive in.

0:30Building networks in the late 2000s and the early 2010s usually involved a difficult conversation, and that conversation revolved around the idea of vendor lock in. The idea was this, we kind of had a choice between going all in on a company like Cisco or trying to shop around and find the best deal at the moment. For example, maybe we need some of the features that Cisco would offer and so we'd deploy our core network onto Cisco, but then maybe another vendor like HP or Dell would come in with cheaper switches, and we'd deploy those at the access layer, and then we'd connect them up and we'd have to manage this environment.

1:04Now as we know, managing a Cisco switch is completely different than managing an HP switch, and so we had the difficulty of making sure that we had techs who were comfortable with managing both types of equipment. And then we simply had the interoperability, the technical issues, with running these particular switches with each other. For example, Cisco runs per VLAN Spanning Tree, and HP ran Common Spanning Tree and getting these to interface with each other sometimes caused some problems. And so we had this concept of vendor lock in, where if you were to build part of your network on one vendor like Cisco, you should probably just build the entire rest of your network on that vendor as well.

1:37Now for those of us in the Cisco world, that was no problem, right? We'd say, OK, let's just deploy Cisco everywhere. It's what we know. It's what we're comfortable with, but that wasn't always the best solution for organizations, and the organizations in the rest of the technical world, they knew this. And so they had this idea, and the idea was to move all of the intelligence of the network to a centralized controller. And this controller would then manage the individual hardware components on the network regardless of whether they were made by Cisco or Dell or HP or any other vendor. This controller would be standards based so that any switch hardware vendor could participate in this ecosystem, and specifically, this standard came to be known as open flow.

2:16You may have heard of open flow. It doesn't get much attention these days, but it is where SDN started. And this controller would interface with commodity hardware. What that means is that the hardware that we're deploying it on, in other words Cisco and HP and Dell switches, these don't need specialized ASICs or specialized anything in order to participate and integrate with that controller. And the theory of software defined networking was that we were going to avoid this vendor lock in problem because now we could deploy Cisco into the core if that's what we wanted. We could deploy HP to the edge if that's what we wanted because we can use the same controller to manage both.

2:51That solves the problem of this manageability issue, and it solves the problem of technical interoperability because we're all standards based now, and we're building it on commodity hardware. Even Cisco would have to deploy hardware that aligns with this architecture. And as you can imagine, this wasn't great news for Cisco. In fact, many heralded SDN as being the death of Cisco, and the reason for that is because Cisco loves hardware. Cisco loved to build specialized hardware. Why Cisco is more expensive is because they build their own ASICs, for example, and the table sizes that they include, the resources on Cisco switches are usually far greater than what we find on comparable platforms.

3:30And so is Cisco's secret sauce was hardware, and we were commoditizing hardware and making everything based on a software controller, well, you can see why people predicted that this would be bad news for Cisco. Now this paradigm isn't exactly where the industry went, and part of that is certainly because Cisco was guiding the industry away from this paradigm because it really would have been bad news for Cisco if this is where SDN landed. And the other part is just the reality that most organizations weren't as concerned about vendor lock in as what the SDN architects were.

4:01It wasn't a problem that was top of mind for them. What they cared more about was the idea that their networks were growing and becoming more important. Everything now is riding on the network. School systems, for example, that teachers used to be able to get up on a whiteboard and teach a class, and now they can't do that because all of the students tools and teachers tools are all internet enabled. And so all of these organizations, what they really needed was the ability to maintain and manage a network over time. And fortunately, SDN was able to provide some of the tools that would enable us as network engineers in order to do that.

4:36So where did we end up from an SDN perspective? Well, modern day software defined networking does still involve that controller. We still have that as part of our SDN designs, but then the hardware does typically align from a vendor perspective with that controller. We don't have to. We can still rely on open flow, for example, but it's just not commonly seen in the industry. Instead, we're typically going to put a Cisco controller with a Cisco set of hardware, and as you can imagine, Cisco isn't the only vendor out there. For example, HP and Dell, we talked about, they have their own solutions.

5:07But, hey, inside the datacenter, so does VMware, the hypervisor manufacturer, which you think, OK, well, they're good at virtual servers, but guess what? They have their own virtual networking suite. Now remember, our goal with SDN is now to solve the problems that our organizations are facing with large scale networks, and one of those problems is if we need to stretch layer 2 between two locations, then we are greatly extending the broadcast and spanning tree domain of that particular subnet. However, we can solve that problem with the power of SDN. So we build out our network to be physically connected, but then we want to change the way that the network looks using software, and the way we do that is with this concept of the overlay.

5:47And overlay equates to a set of tunnels. We're going to use tunneling as a network construct in order to connect different switches to each other and form the topology we really want. For example, in this network here, let's say this is layer 3 connectivity, and if it's layer 3 connectivity, that means I can't have the same subnets directly attached to these two different switches. Well, with the concept of this overlay, we can do that. We can build a tunnel between these two switches and enable that subnet to live out both locations. And the best part is this controller is going to handle that overlay creation for us.

6:18So in the end, we basically get to decide whatever topology we want, we can deploy onto an existing underlay, where the underlay is the physical hardware. On top of that, we have this concept of programmability. You've probably heard of this using things like REST APIs or netconf to configure a networking gear, and using structured language like JSON and XML in order to accomplish that. And in most cases, we can use these programmability elements on the SDN controller itself. And the SDN controller is going to use those same programmability elements to push configuration changes down to the network hardware.

6:50And on top of that, SDN nowadays offers this concept of network assurance. Assurance leverages artificial intelligence and machine learning or AIML in order to analyze the network and figure out, hey, what's really going on here? And maybe there's a problem that's coming that hasn't even been reported yet. And so this assurance engine can alert the admin to say, hey, there's a problem. You need to get onto your computer and fix this problem before it becomes a bigger issue. And we're able to do this because of this controller, where we're aggregating all of the configuration and aggregating all of the data points from the network into one place.

7:25Now this is great and all but we could still do some of this on commoditized hardware. So where does Cisco really shine in this space? Well, one of the things that Cisco has done is they have built their SDN architectures on what we call a declarative SDN model. The declarative model says that I'm going to tell you what to do, and these hardware pieces have the intelligence in order make that happen. In other words, these switches are still performing writing adjacencies. They're still running EIGRP or OSPF, and the alternative that a lot of other vendors run is an imperative model.

7:56In an imperative model, the controller is not really pushing configuration down as much as it's playing the role of the control plane. Meaning that it makes all of the forwarding decisions and then populates routing tables and Mac address tables and such so the switches and routers can make their forwarding decisions without actually participating in the control plane. And one of the biggest problems with this model is that the controller itself is very important. If the controller goes down for any reason, the network grinds to a halt because we've just lost the control plane. But not so in a declarative model. If the declarative model loses its controller, then we can maybe not make configuration changes, but the network continues to hum along.

8:31And that's because the intelligence is still in the hardware, and that's how Cisco provides us with the value of SDN without devaluing their own hardware. So what did we learn here? Well, first of all, SDN was developed to solve a problem that many organizations decided they didn't have. Didn't really care about that vendor lock in as much as they cared about wrapping their arms around their growing networks. And that's exactly what SDN of today is designed to do because it allows us to, first of all, form those overlays that we talked about and create the network architectures that we want independent of the underlying hardware.

9:02And then we also have those elements of programmability and network assurance that again help us wrap our arms around the networking, manage and maintain it over time. So I hope has been informative for you, and I'd like to thank you for viewing.

0:00When I was in high school, I saw the musical Fiddler on the Roof. And if you've never seen that, it's a story that really challenges the perspective of tradition, why do we do things the way we do them. And in networking, we have a lot of traditions. We've got Spanning Tree, for example. We've got loop prevention and all kinds of ways that we architect our networks in a very traditional sense. I mean, these networks have been around for 20 and 30 years now. And a lot of ways, we haven't changed a whole lot of the way we do things. Now, in the last video, I mentioned that there are a lot of challenges that organizations had around this large growing and sprawling networks.

0:36And I want you to take my word for it, we're going to go ahead, and dive in, and take a look at how these traditional networks causes grief when we're trying to manage and maintain them. Let's dive in. For better or worse, we decided to build the foundation of the internet and all of our networks on ethernet. And let's be real, ethernet is kind of a terrible protocol. I mean, it was one of the very first attempts to create communications across a medium, an ether, and introduce this concept of broadcasts. And here we are, nearly 50 years later, still using the exact same protocol.

1:08And we've made a few tweaks here and there, but this problem of broadcast still exists. In fact, a lot of what we do today is to work around these broadcasts. For example, when we build our layer to networks, we usually have some kind of distribution layer, and we have an access closet down here that we need to connect to. And so when we have many switches in the access closet, what are we supposed to do? Are we supposed to loop all the way through these switches? Or hey, do we head off the top one, maybe loop through the top switch, and then have another loop down here? And then we have to worry about which of these links we're going to block.

1:41So we might have to block this link, and this link in here, maybe even this link. And the reason why we're blocking those links is because of broadcasts. We can't form a broadcast storm. If we actually loop these switches together without Spanning Tree running, then we're going to cause a network outage. And so we're forced to choose between looped triangle configurations and looped square configurations. And of course, regardless of how we deploy it, we have to run Spanning Tree on top of it. And Spanning Tree is a bit of a nightmare, because we have to manage which one is the root switch, and what are our link costs, and are we going to deploy any extensions like root guard or BPDU guard.

2:18And as if that's not enough, we also have loop guard, and UDLD, and bridge assurance, and then we do worry about Rapid Spanning Tree and Multi-instance Spanning Tree. And all of this has been done to deal with the inadequacies of ethernet. And so then, our idea was to limit where Spanning Tree really was needed. And so we came up with ideas for this access layer. For example, we came up with chassis switches, which would reduce the Spanning Tree topology. And then stackable switches as well for the same reason. And then in the data center, we came up with this technology called virtual port channels.

2:49And all of this is to reduce the impact of Spanning Tree, which, again, is there to help us deal with the inadequacies of ethernet. And so all of these technologies that we've been developing over time centers around the fact that scaling out layer two networks via this protocol is painful. So the question is, why are we building out on layer two? Why don't we just do layer three? We could do layer three to the access layer. That is an option. So why aren't all organizations deploying layer three out on the networks? Well, this comes down to this concept of policy.

3:20Think about this for a moment, where do we deploy our security policies? Where do we deploy our QoS policies? In most cases, we're deploying these to a VLAN or potentially a subnet. And of course, in most networks, there's a one to one relationship between these. Because our policies are getting deployed to the VLANs, we need these VLANs to be stretched. We need them to exist as many places as possible, which makes us so we can't deploy layer three to the access layer in most cases. Because again, with the limitations of networking, we know that if I've got a switch out here that's connected down and it's a layer three communication, well, whoever is connected to this switch and whoever is connected to the switch on the right, these two devices can't be on the same subnet.

4:04They can't be on the same VLAN, because they have layer three segmentation between them. And here's the question that we have to ask in all of this, why? Why are we deploying networks in such a way as if this was the 1980s or 1990s? Why haven't we evolved beyond Spanning Tree, for example? Why haven't we gone away from policies being tied to VLANs? Why can't we do layer three everywhere and allow these hosts to be on the same subnet? And as if that's not all bad enough, how are we doing all of this configuration?

4:35How are we doing all of this maintenance? Usually, it's you and me with the network techs. We're logging into these devices manually, deploying these policies, tuning Spanning Tree, doing our best to maintain this network as it becomes more and more critical to our business needs. And as much as I personally love being on the CLI, I know that it's inefficient, and I know that it's error prone. It's like when you're driving. You trust yourself at the wheel, but you don't trust anybody else around you. And the CLI is the same way, right?

5:05I trust myself, but I don't know that I would trust my co-worker to go properly configure something on the network core without me. And so we know that humans are error prone. We make mistakes. And the reality is that we have the technology to do this better. We've got ways of architecting this so that our policies aren't bound to our VLANs anymore. We can have computer systems, software go out and do the configuration, so we're not being inefficient with our time, and we're not making mistakes. And yet, we can get away from Spanning Tree. We can finally deploy layer three everywhere and rid of that protocol once and for all.

5:39So I think all three of these are doable if we continue to explore software-defined networking and the benefits that it can provide. So with that, I hope this has been informative for you. And I like to thank you for viewing.

0:00OK, I got a riddle for you. Why did the network engineer cross the road? And the answer, probably to get around spanning tree because sometimes it feels like that's half of what we do is dealing with the pain points that spanning tree provides. As I mentioned last video, we've got chassis switches and stackable switches and virtual port channels, and all these are great at helping us deal with spanning tree, but none of them outright get rid of spanning tree. In this video, we're going to explore the concept of overlays and underlays, and as we're going to see, overlays will help us finally get rid of spanning tree in our networks. And on top of that, they're going to add a lot of other benefits as well.

0:33So let's go ahead and dive in. In many cases, the physical design of our network can dictate what the logical configuration is going to look like. For example, we take a look at a traditional network here. This is kind of what we draw in the last video. How we have a distribution layer up here, and then we have client A and client B, and for whatever reason, these two clients need to be on the same subnet. Well, if we want them on the same subnet and therefore, the same VLAN, we're going to have to extend Layer 2 through this topology, which means that we're now creating a large Layer 2 domain. And again, we discussed this.

1:04This is problematic because now we have to worry about spanning tree and first hop redundancy protocols and all kinds of things that are required in order to extend Layer 2 everywhere. Unfortunately, in traditional networks, we don't have much of a choice. We're going to do what we can in this scenario, and usually what we can do is convert these links to trunks or maybe they're trunks to begin with and we'll extend that VLAN down and increase the broadcast domain of that VLAN. In order to overcome this, this requires a new way of thinking about how we build networks, and part of the way we're going to build networks differently is by leveraging an overlay.

1:36Let's take a look at an example here of a network that has five devices, and let's say that they are physically connected like this. Some kind of strange configuration, and that's well and good, except what I really want is for this router in the middle to have direct connections to the four different routers. I want this to be my network design, even though I understand that this connection right here and this connection right here, these don't actually physically exist. Well, in order to accomplish this, I can leverage an overlay, and an overlay really is just a bunch of network tunnels that create the architecture that I want.

2:10So now in my green network here, these are all tunneled connections. Tunneling requires encapsulation de-encapsulate, and so when I send from this router here in the middle to the router down here at the bottom left, yeah, physically it has to follow where there's actually connections, right? I mean, at some point, we are still bound by the physical network. However, I'm going to encapsulate it into a tunnel on the router and physically send it down to this router, down the bottom right, but that router in the bottom right is not going to see the details of that packet. It is simply going to say, you know what, you're destined for the router in the bottom left, so I'm going to forward it right along.

2:44And that router will receive it and de-encapsulate it. And effectively, what we've done is we've sent it logically directly to the destination router. So the way I like to describe this is to say that we might have a bunch of physical equipment and they're physically connected in some way, but then what we do is we lay a piece of paper on top of that network topology and we draw the topology that we actually want. And the topology we want, this is the overlay. Whereas, the topology that we have, this here, is the underlay.

3:14So let's look back at the network on the left. What if we didn't make this a trunked interface? What if we made this a Layer 3 connection instead of Layer 2? You're already saying, OK, Jeff, that's great and all except we needed A and B to be on the same subnet. In order to do that, we need to extend Layer 2, but what if that Layer 3 network is simply our underlay? What if we design an overlay that will give us what we actually want? And what we actually want can be accomplished by extending a Layer 2 tunnel between these two switches. Now we can share, let's say VLAN 100 between the two switches while still having a Layer 3 network that is serving as the underlay.

3:51And we can accomplish this with a protocol we call VXLAN or the virtual extensible local area network protocol. This is a Layer 2 tunneling mechanism that allows me to accomplish exactly what I've drawn out here. So this is great for a campus environment, but especially imagine it in a data center infrastructure. We might have hundreds of data center edge switches and the need to keep VLANs spread throughout the entire data center. Well, now we can have all of these hundreds of switches connected at Layer 3, and Layer 3 means no spanning tree. We're done with spanning tree. We said it's obsolete.

4:22We want to get rid of it, and this is how we can get rid of it. Incidentally, we can get rid of first hop redundancy protocols as well because the first hop redundancy protocols used to run in the distribution layer. But now that we have a Layer 3 network, those gateways can no longer live in the distribution layer, and so we get rid of first hop redundancy protocols and install anycast gateways at each of the switches. So this paradigm allows us to get rid of protocols left and right. It's a really good deal. Now this is great for Layer 2, but what can we do from a Layer 3 perspective? Well, let's think about an MPLS domain. In most cases with MPLS, we are going to share our routes with our service provider and those also get shared among all of the service provider routers.

4:59This allows, for example, site A traffic to reach site B via the MPLS cloud rather than having to get sent down to the core and back up, which would be inefficient. But the downside to this is that the MPLS provider now needs to know about every single subnet in my environment. Well, what if we turn the MPLS circuit into an underlay? What if, instead of sharing routes with our service provider, we extend tunnels between our sites? Now I no longer need to worry about sharing my routes with the service provider. Instead, I send the traffic at the data plane level to the service provider router and that router's only purpose is to get the traffic across its own domain.

5:37It will send that traffic across the MPLS domain and then get dropped off with the appropriate router. Now, yes, physically, we are still sending traffic into the MPLS cloud, and it is bouncing around all of the routers in there, and then physically lands at our remote site. But what's happening from a logical perspective is I am directly handing that traffic from one of my switches to my remote routers. From a logical perspective, this is a direct connection. These two routers would see each other, for example, as OSPF neighbors or EIGRP neighbors or whatever routing protocol we're running.

6:08And we have plenty of protocols today that would support this, such as GRE, but also Cisco's locator ID separation protocol or LISP. So it's really good that we have the protocols in order to get this done, but here's the question, would you want to do this manually on your own? Because I could have come to you 10 years ago and said, hey, we've got these GRE tunnels, and we could build tunnels everywhere in the network. And the response from you, rightfully so, should be, oh my goodness, I don't want to have to manage and maintain all of those tunnels over time. What if one change happens and that's going to propagate throughout my whole network?

6:39I mean, the idea of manually configuring and managing all of these tunnels would be a nightmare. But fortunately, this is something that software defined networking helps us get around because now we have a software controller that can manage all of these tunnels for us. And so it's a game changer in the fact that we can deploy these tunnels automatically and achieve all the benefits that they provide. So what are our takeaways? Well, first of all, we know that the physical topology of a network is largely going to dictate for us what that logical topology is going to need to be. And that's no good. We don't want that anymore. We want to get away from that restriction.

7:10And so in order to accomplish that, we're going to take the physical network and turn that into a network underlay. Now the underlay isn't going to necessarily know where all of the clients in the network are. Its main concern is getting from one end of the underlay to the other end. And if the underlay is what we have in the physical architecture, then the overlay is what we want. And we accomplish that by building tunnels over, being the overlay, over the underlay. And so what we're going to find is that SDN is the glue that holds all of this together. So with that, I hope this has been informative for you, I'd like to thank you for viewing.

0:00It is time to hold Cisco's feet to the fire, and fortunately, there is no literal fire. We don't need protective gear or anything like that. We simply want Cisco to show us what they've been doing, because they've been telling us all about this software defined world and how important it is for us to learn programmability and such. But what have they been doing to make sure that they are relevant in this age of software defined infrastructures? Well, in this video, we're going to explore all of the different solutions that Cisco offers where they've integrated software defined networking. Let's dive in. Given this is a course on software defined access and DNA Center, it probably makes sense to start with that particular solution.

0:34But in order to understand what SDA is we need to understand the Campus Fabric. Here the idea of the Campus Fabric. Typically, we have some number of core devices, and this would include a true network core, it would include distribution layers and such, whatever holds the core of our network together. And then we have these edge switches. These would be our access layer switches out in our access closets, and our users are attaching to these edge switches. And let's say we have a couple of access switches on the right and a couple more here on the left, and these are all connected in to these core devices. Whatever those connections are, they're kind of irrelevant because this forms that underlay concept.

1:10This is the physical layout of our network devices, and it's no longer relevant for how we're going to deploy our network. And the reason it's no longer relevant is because we're going to deploy an overlay on top of this = In a Campus Fabric environment, we are going to form that overlay between all of these edge devices. We're going to turn all of those core and distribution devices into the underlay, which means it's the network that's holding all this together. As such, when we have a user attaching to the switch, it gets put into the tunnel and forwarded out to the appropriate egress switch, so it can communicate with its destination.

1:44Cisco defines the Campus Fabric as such. We use VXLAN for the data plane. That would be the tunnels that we've drawn out. However, VXLAN does not define our control plane information for us. In other words, when I send my packet to this switch, how does this switch right here know where to send that traffic? It's got to put that into a VXLAN tunnel and forward it to a remote switch. We have no idea which switch to send it to, and that's why we need a control plane, to tell us where in the network other devices are. And we have a lot of different options for control planes, but in a Campus Fabric, we're going to use a Cisco protocol called the locator ID separation protocol, or LISP, and that will be our control plane.

2:20Now this is a great start, but it still falls short in one key area. In a Campus Fabric, Cisco wants integrated security, meaning it's not an afterthought. It's not something we layer on top. It is something that is built into the very fabric of this network, and the way we're going to accomplish that is by deploying Cisco Trust SEC or CTS. Cisco Trust SEC is going to provide integrated security for us by identifying who this person is, who they're trying to speak to, and whether that communication should even be allowed. In order to deploy Cisco Trust SEC, we're going to leverage the identity services engine or ISE, another Cisco product that can be deployed on its own, but when combined with VXLAN and when combined with LISP, this forms what Cisco calls the Campus Fabric.

3:04Now if you're like me and you love being on the CLI, you might be inclined to fire up your computer, connect to these network devices, and deploy VXLAN tunnels and deploy LISP at the CLI, and to deploy ISE into your environment, and that works great. We can deploy a Campus Fabric in that way. However, that is a very manual process, and we talked about the disadvantages of manual systems. This is extremely inefficient for me as a network engineer to try to build and maintain over time, and it's error prone. I might make a mistake. Instead, it would be fantastic for us to have a true software defined networking solution that involves a controller, and the controller that Cisco created to deploy a Campus Fabric is called DNA Center.

3:44So where does software defined access fall into all of this? Well, software defined access, or SDA, is like a math problem. We say SDA is equal to a Campus Fabric plus DNA Center or DNA-C. If I leverage DNA Center, I deploy that as a controller into my infrastructure, which by the way, today is a physical controller. So I'm installing a physical appliance into my network, and I have it deploy a Campus Fabric, and I have it manage and monitor and maintain that Campus Fabric over time, then according to Cisco, that is software defined access.

4:19However, software defined access is not the only software defined networking solution Cisco has in their portfolio. They have two other such solutions, and it's important that we understand exactly what those are. The first solution is called software defined WAN. Software defined WAN is more than just an industry trend. In this case, it is the name of Cisco's product. Cisco originally developed their own software defined WAN infrastructure, called iWAN. However, iWAN has been deprecated because Cisco went out and bought a company called the Viptela. And Viptela, we no longer call any of Cisco's products Viptela.

4:49We've retired that name. Instead what we have is Cisco SD-WAN. So, yes, SD-WAN is the technology trend, but it is also the name of Cisco's product. Now in the case of SD-WAN, this is going to look very similar to us after exploring what software defined access looks like because we're going to have a WAN environment where we have a service provider in the middle that's providing connectivity to all of our routers. And traditionally, we have to share routes back and forth. We mentioned this in an earlier video, and that's all well and good, except wouldn't it be great if we didn't have to do that?

5:20And the service provider didn't have to know all of the routes in my network in order for me to communicate? Well, that is exactly what SD-WAN solves for us. It does the same concept of building those tunnels out from edge routers to edge routers. However, instead of VXLAN, we are going to use IPSec tunnels since SD-WAN is really more of a Layer 3 technology, and we don't need the Layer 2 benefits that VXLAN provides. One of the best benefits to this technology is that I can actually have a second WAN service provider in the mix, and I can build tunnels through that WAN service provider as well.

5:50So now I've got a completely integrated solution with multiple tunnels to the same destinations, and I can choose the best path depending on the scenario. So, for example, if I'm trying to communicate from router A to router B, I know I've got two different paths I can choose. One goes through one service provider, and one goes through the other. And so maybe depending on my application, I might want to choose one over the other. Maybe one has more bandwidth, but the other service provider is more reliable, and so it gives me full control over my network traffics in an SD-WAN solution. Now no SD-WAN solution is complete without a controller, and SD-WAN is no exception.

6:24In Cisco SD-WAN we have a controller called the vManage. Now the little v in vManage is actually a reference to Viptela, but make no mistake. This solution has been fully integrated with Cisco hardware. We can deploy ISR routers, for example, to the edge and participate in an SD-WAN architecture. Now the last solution we need to be aware of is called application centric infrastructure, ACI. This is a data center technology that's going to work again, very similarly to SD Access, even in the fact that we use VXLAN. The difference lies in the underlay.

6:54In the data center, we're going to build a spine leaf topology, where we have a spine layer of switches, and we have a leaf layer of switches. And we connect every spine to every leaf but no spines connect to other spines and no leaves connect to other leaves. And you guessed it. We're going to build those VXLAN tunnels among all of these edge devices. And because we have these VXLAN tunnels, our core devices no longer need to know all of the different Mac addresses and IP addresses that live in this environment. That drastically improves our ability to Layer 2 scaling any data center, which with traditional infrastructures, this is a big problem.

7:28But ACI makes that solution quite simple. We deploy Cisco's Application Policy infrastructure Controller, or APIC, as the controller that manages this SDN solution. So as you can see here, Cisco has invested heavily into software defined infrastructures. In fact, they have three different solutions for three different places in the network. First of all, we have this concept of Campus Fabric. Campus Fabric is VXLAN plus LISP plus Cisco Trust SEC, and then if we add DNA Center in, now we have software defined access or SDA. SDA belongs where the users are.

7:58Now Cisco's SD-WAN product, that belongs where the wide area network is, which is what the name implies. We're going to use that to help us better utilize our WAN circuits. And last but not least is application centric infrastructure, ACI. ACI belongs inside the data center and helps us really get a grasp on Layer 2 scaling inside the data center, which traditional architectures struggle with. So Cisco has given us three different options for three different network locations, and we can leverage the best one for the need. So with that, I hope this has been informative for you, and I'd like to thank you for viewing.

0:00We've reached the end of our skill, and that means it's time to review what we've learned by taking a quiz. Don't hesitate to pause this video if you need more time to answer any of the questions. So first up out of four questions, what original goal of SDN failed to align with organizational care-abouts? Well, using controllers to improve management is not only something we cared about then, it's something we care about now. As is offering network assurance. This idea that we can use artificial intelligence and machine learning to proactively tell us what's going on in our network.

0:31Increase programmability features. If Cisco's defnet program is any indication that programmability features are still highly desirable in this space. Last but not least, commoditizing network hardware, making it so we can deploy any old switch into the network isn't something that the industry actually cared all that much about. And so D is the answer. SDN originally wanted to help commoditize that network hardware and make it so a Cisco switch is really no different from a Dell switch. But fortunately for us in the Cisco world, this didn't come to pass, and Cisco's doing just fine and dandy in this SDN world.

1:03Next up, where are network policies typically applied in traditional network architectures? Well, I'll admit this is a little bit of a subjective question because we're asking where it's typically applied, and we can always find exceptions to these rules. However, what we're going to find in most network architectures is that our network policies are being deployed to VLAN interfaces because it allows those policies to be deployed between subnets. If we're to deploy policies under the switchpot, that would be even worse than deploying it to a VLAN interface.

1:34However, the ultimate goal of what we really want to accomplish is to deploy policies to the users that are attached to the network, and this can apply to applications as well. So if a particular user application needs a security policy or a QoS policy or any number of different network policies than we can apply those wherever in the network they're attached. Whether they're attached wirelessly or to a physical switch part or through the data center, for example. Sort of the goals of SDN is to remove this restriction that we have by applying policies to VLANs and subnets and other network constructs and apply them to the actual entity of the user or the application that we're trying to apply that policy to.

2:11So all that to say, the answer here is B. Question number three, what new network paradigm is formed by the use of tunnels? Well, if you check out the source down here, it's probably one of these two, right? If we remember, the underlay is the physical network, so that would be the network that we have. Remember, we drew this picture where we kind of attach all these routers in some fashion, and then we pretend to put down a piece of paper and we draw those same four routers, except we attach them in whatever way we want.

2:42This now is the logical formation of the network, and we form this via tunnels. Now as you can tell by the way we do this, the overlay is going to consist of the tunnels and that goes over the underlay, which is the physical network. So our answer is the overlay. Last question here, what are the major components of Cisco Software Defined Access or SDA? Well, we've got to first remember what Cisco SD Access is all about, and remember, it's like a math problem.

3:14SDA is equal to Campus Fabric plus DNA Center. Now we do find the DNA Center is one of our answers, however, what are the components of Campus Fabric? And remember that this is a math problem as well, because Campus Fabric is equal to VXLAN plus LISP at the control plane, plus Cisco Trust SEC, which by the way is deployed via the identity services engine or ISE. So we have four different components as part of the Campus Fabric, and we can see that those are all in our answers. So we have ISE, Cisco Trust SEC, VXLAN, and LISP.

3:46In fact, the only answer that we don't need that's listed here is spanning tree protocol, and that is a huge blessing. One of the goals that we should have for deploying an SDN fabric is to eliminate spanning tree. So that wraps up this quiz. How did you do? If you find yourself with any gaps in your knowledge, make sure and go back and watch the appropriate videos in order to fill those. Otherwise, congratulations on completing describe software defined networking. I hope this has been informative for you, and I'd like to thank you for viewing.