Describe Software-Defined Networking

0:00Welcome to describe software defined networking,

0:02and by the way, welcome to this whole course on software

0:04defined access in DNA Center.

0:06Cisco's software defined access or SDA is a software defined

0:10networking or SDN solution, and if we don't understand

0:13what SDN is then we're going to have a hard time understanding

0:16what the goals of an architectural like software

0:18defined access really are.

0:20And so throughout the course of this series,

0:22we're going to take a look not only at defining what SDN is

0:24and the benefits, we'll also take a look

0:26at the variety of Cisco SDN offerings they have available,

0:29because SDA is not their only one.

0:31So come along with me, we'll have a lot of fun exploring SDN

0:34and what exactly that is.

0:35And with that, I will see you in the next video.

0:00I used to joke that SDN stood for still don't know,

0:02because we didn't know what SDN was supposed to be.

0:06And that was true back in the maybe mid 2010s,

0:09because early on, when SDN was developed,

0:11everybody had a different vision for what it was supposed to be

0:14and what it was supposed to accomplish.

0:15But these days, fortunately, we do know what SDN is.

0:18And so in this video, what we're going to do

0:20is explore exactly where SDN came from,

0:23what the general idea was behind it,

0:26and then where we are today with what SDN is.

0:29Let's dive in.

0:30Building networks in the late 2000s and the early 2010s

0:33usually involved a difficult conversation,

0:36and that conversation revolved around the idea of vendor lock

0:39in.

0:40The idea was this, we kind of had a choice

0:42between going all in on a company like Cisco

0:45or trying to shop around and find

0:47the best deal at the moment.

0:48For example, maybe we need some of the features

0:50that Cisco would offer and so we'd deploy our core network

0:53onto Cisco, but then maybe another vendor like HP or Dell

0:57would come in with cheaper switches,

0:58and we'd deploy those at the access layer,

1:01and then we'd connect them up and we'd have

1:02to manage this environment.

1:04Now as we know, managing a Cisco switch

1:05is completely different than managing an HP switch,

1:08and so we had the difficulty of making sure

1:10that we had techs who were comfortable with managing

1:12both types of equipment.

1:14And then we simply had the interoperability,

1:16the technical issues, with running

1:18these particular switches with each other.

1:20For example, Cisco runs per VLAN Spanning Tree,

1:23and HP ran Common Spanning Tree and getting

1:25these to interface with each other

1:26sometimes caused some problems.

1:28And so we had this concept of vendor lock

1:30in, where if you were to build part of your network

1:32on one vendor like Cisco, you should probably just

1:34build the entire rest of your network on that vendor as well.

1:37Now for those of us in the Cisco world,

1:39that was no problem, right?

1:40We'd say, OK, let's just deploy Cisco everywhere.

1:43It's what we know.

1:43It's what we're comfortable with,

1:45but that wasn't always the best solution for organizations,

1:47and the organizations in the rest of the technical world,

1:50they knew this.

1:51And so they had this idea, and the idea

1:53was to move all of the intelligence of the network

1:56to a centralized controller.

1:58And this controller would then manage the individual hardware

2:01components on the network regardless

2:03of whether they were made by Cisco or Dell

2:05or HP or any other vendor.

2:07This controller would be standards

2:09based so that any switch hardware vendor could

2:11participate in this ecosystem, and specifically, this standard

2:14came to be known as open flow.

2:16You may have heard of open flow.

2:18It doesn't get much attention these days,

2:19but it is where SDN started.

2:21And this controller would interface

2:23with commodity hardware.

2:24What that means is that the hardware that we're deploying

2:27it on, in other words Cisco and HP and Dell switches,

2:30these don't need specialized ASICs or specialized anything

2:33in order to participate and integrate with that controller.

2:36And the theory of software defined

2:37networking was that we were going to avoid this vendor

2:40lock in problem because now we could deploy Cisco

2:43into the core if that's what we wanted.

2:45We could deploy HP to the edge if that's

2:47what we wanted because we can use the same controller

2:50to manage both.

2:51That solves the problem of this manageability issue,

2:54and it solves the problem of technical interoperability

2:57because we're all standards based now,

2:59and we're building it on commodity hardware.

3:01Even Cisco would have to deploy hardware that

3:03aligns with this architecture.

3:05And as you can imagine, this wasn't great news for Cisco.

3:08In fact, many heralded SDN as being the death of Cisco,

3:12and the reason for that is because Cisco loves hardware.

3:16Cisco loved to build specialized hardware.

3:18Why Cisco is more expensive is because they build

3:21their own ASICs, for example, and the table sizes

3:24that they include, the resources on Cisco switches

3:26are usually far greater than what we

3:28find on comparable platforms.

3:30And so is Cisco's secret sauce was hardware,

3:33and we were commoditizing hardware and making everything

3:36based on a software controller, well,

3:38you can see why people predicted that this

3:40would be bad news for Cisco.

3:41Now this paradigm isn't exactly where the industry went,

3:45and part of that is certainly because Cisco

3:46was guiding the industry away from this paradigm

3:49because it really would have been bad news for Cisco

3:51if this is where SDN landed.

3:53And the other part is just the reality

3:55that most organizations weren't as concerned about vendor lock

3:58in as what the SDN architects were.

4:01It wasn't a problem that was top of mind for them.

4:03What they cared more about was the idea

4:05that their networks were growing and becoming more important.

4:09Everything now is riding on the network.

4:11School systems, for example, that teachers

4:14used to be able to get up on a whiteboard and teach a class,

4:16and now they can't do that because all of the students

4:19tools and teachers tools are all internet enabled.

4:22And so all of these organizations, what they really

4:25needed was the ability to maintain and manage

4:27a network over time.

4:28And fortunately, SDN was able to provide

4:31some of the tools that would enable us as network engineers

4:34in order to do that.

4:36So where did we end up from an SDN perspective?

4:38Well, modern day software defined networking does still

4:41involve that controller.

4:42We still have that as part of our SDN designs,

4:45but then the hardware does typically

4:47align from a vendor perspective with that controller.

4:50We don't have to.

4:51We can still rely on open flow, for example,

4:53but it's just not commonly seen in the industry.

4:56Instead, we're typically going to put a Cisco controller

4:59with a Cisco set of hardware, and as you can imagine,

5:01Cisco isn't the only vendor out there.

5:03For example, HP and Dell, we talked about,

5:05they have their own solutions.

5:07But, hey, inside the datacenter, so does VMware, the hypervisor

5:11manufacturer, which you think, OK, well, they're

5:13good at virtual servers, but guess what?

5:15They have their own virtual networking suite.

5:17Now remember, our goal with SDN is now to solve the problems

5:20that our organizations are facing with large scale

5:23networks, and one of those problems

5:24is if we need to stretch layer 2 between two locations,

5:27then we are greatly extending the broadcast

5:29and spanning tree domain of that particular subnet.

5:33However, we can solve that problem with the power of SDN.

5:37So we build out our network to be physically connected,

5:39but then we want to change the way that the network looks

5:43using software, and the way we do

5:45that is with this concept of the overlay.

5:47And overlay equates to a set of tunnels.

5:50We're going to use tunneling as a network construct in order

5:53to connect different switches to each other

5:55and form the topology we really want.

5:57For example, in this network here,

5:58let's say this is layer 3 connectivity,

6:00and if it's layer 3 connectivity, that

6:02means I can't have the same subnets directly attached

6:04to these two different switches.

6:06Well, with the concept of this overlay, we can do that.

6:09We can build a tunnel between these two switches

6:11and enable that subnet to live out both locations.

6:14And the best part is this controller

6:15is going to handle that overlay creation for us.

6:18So in the end, we basically get to decide whatever topology we

6:22want, we can deploy onto an existing underlay,

6:25where the underlay is the physical hardware.

6:28On top of that, we have this concept of programmability.

6:31You've probably heard of this using things like REST APIs

6:34or netconf to configure a networking gear,

6:36and using structured language like JSON and XML

6:39in order to accomplish that.

6:40And in most cases, we can use these programmability elements

6:43on the SDN controller itself.

6:45And the SDN controller is going to use

6:46those same programmability elements

6:48to push configuration changes down to the network hardware.

6:50And on top of that, SDN nowadays offers this concept

6:53of network assurance.

6:55Assurance leverages artificial intelligence and machine

6:57learning or AIML in order to analyze the network

7:01and figure out, hey, what's really going on here?

7:03And maybe there's a problem that's

7:05coming that hasn't even been reported yet.

7:07And so this assurance engine can alert the admin to say,

7:10hey, there's a problem.

7:11You need to get onto your computer

7:13and fix this problem before it becomes a bigger issue.

7:16And we're able to do this because of this controller,

7:19where we're aggregating all of the configuration

7:21and aggregating all of the data points from the network

7:24into one place.

7:25Now this is great and all but we could still

7:27do some of this on commoditized hardware.

7:29So where does Cisco really shine in this space?

7:32Well, one of the things that Cisco has done

7:33is they have built their SDN architectures on what we

7:36call a declarative SDN model.

7:38The declarative model says that I'm

7:40going to tell you what to do, and these hardware pieces

7:43have the intelligence in order make that happen.

7:45In other words, these switches are still

7:47performing writing adjacencies.

7:49They're still running EIGRP or OSPF,

7:52and the alternative that a lot of other vendors run

7:54is an imperative model.

7:56In an imperative model, the controller

7:58is not really pushing configuration down as much

8:00as it's playing the role of the control plane.

8:02Meaning that it makes all of the forwarding decisions

8:05and then populates routing tables and Mac address tables

8:07and such so the switches and routers

8:09can make their forwarding decisions

8:10without actually participating in the control plane.

8:13And one of the biggest problems with this model

8:15is that the controller itself is very important.

8:17If the controller goes down for any reason,

8:19the network grinds to a halt because we've just

8:22lost the control plane.

8:23But not so in a declarative model.

8:25If the declarative model loses its controller,

8:27then we can maybe not make configuration changes,

8:30but the network continues to hum along.

8:31And that's because the intelligence is still

8:33in the hardware, and that's how Cisco provides us

8:36with the value of SDN without devaluing their own hardware.

8:39So what did we learn here?

8:40Well, first of all, SDN was developed

8:41to solve a problem that many organizations decided

8:44they didn't have.

8:44Didn't really care about that vendor lock in as much

8:46as they cared about wrapping their arms around their growing

8:49networks.

8:50And that's exactly what SDN of today

8:52is designed to do because it allows us to, first of all,

8:56form those overlays that we talked about

8:58and create the network architectures that we

9:00want independent of the underlying hardware.

9:02And then we also have those elements

9:04of programmability and network assurance

9:06that again help us wrap our arms around the networking,

9:08manage and maintain it over time.

9:10So I hope has been informative for you,

9:11and I'd like to thank you for viewing.

0:00When I was in high school, I saw the musical Fiddler

0:02on the Roof.

0:03And if you've never seen that, it's

0:04a story that really challenges the perspective of tradition,

0:08why do we do things the way we do them.

0:11And in networking, we have a lot of traditions.

0:13We've got Spanning Tree, for example.

0:15We've got loop prevention and all kinds of ways

0:17that we architect our networks in a very traditional sense.

0:21I mean, these networks have been around for 20 and 30 years now.

0:24And a lot of ways, we haven't changed a whole lot

0:27of the way we do things.

0:28Now, in the last video, I mentioned

0:29that there are a lot of challenges that organizations

0:32had around this large growing and sprawling networks.

0:36And I want you to take my word for it,

0:38we're going to go ahead, and dive in, and take a look

0:40at how these traditional networks causes

0:42grief when we're trying to manage and maintain them.

0:45Let's dive in.

0:46For better or worse, we decided to build

0:48the foundation of the internet and all of our networks

0:50on ethernet.

0:52And let's be real, ethernet is kind of a terrible protocol.

0:55I mean, it was one of the very first attempts

0:57to create communications across a medium, an ether,

1:01and introduce this concept of broadcasts.

1:04And here we are, nearly 50 years later,

1:06still using the exact same protocol.

1:08And we've made a few tweaks here and there,

1:10but this problem of broadcast still exists.

1:13In fact, a lot of what we do today

1:15is to work around these broadcasts.

1:17For example, when we build our layer to networks,

1:19we usually have some kind of distribution layer,

1:21and we have an access closet down here

1:23that we need to connect to.

1:25And so when we have many switches in the access closet,

1:28what are we supposed to do?

1:29Are we supposed to loop all the way through these switches?

1:32Or hey, do we head off the top one, maybe loop

1:35through the top switch, and then have another loop down here?

1:38And then we have to worry about which of these links

1:40we're going to block.

1:41So we might have to block this link, and this link in here,

1:44maybe even this link.

1:45And the reason why we're blocking those links

1:47is because of broadcasts.

1:49We can't form a broadcast storm.

1:51If we actually loop these switches together

1:53without Spanning Tree running, then we're

1:55going to cause a network outage.

1:57And so we're forced to choose between looped triangle

2:00configurations and looped square configurations.

2:03And of course, regardless of how we deploy it,

2:05we have to run Spanning Tree on top of it.

2:07And Spanning Tree is a bit of a nightmare,

2:09because we have to manage which one is the root switch,

2:12and what are our link costs, and are we

2:15going to deploy any extensions like root guard or BPDU guard.

2:18And as if that's not enough, we also

2:20have loop guard, and UDLD, and bridge assurance,

2:22and then we do worry about Rapid Spanning

2:24Tree and Multi-instance Spanning Tree.

2:26And all of this has been done to deal with the inadequacies

2:30of ethernet.

2:31And so then, our idea was to limit where Spanning

2:34Tree really was needed.

2:35And so we came up with ideas for this access layer.

2:38For example, we came up with chassis switches,

2:40which would reduce the Spanning Tree topology.

2:42And then stackable switches as well for the same reason.

2:45And then in the data center, we came up

2:46with this technology called virtual port channels.

2:49And all of this is to reduce the impact of Spanning Tree, which,

2:52again, is there to help us deal with the inadequacies

2:55of ethernet.

2:56And so all of these technologies that we've been developing over

2:58time centers around the fact that scaling out layer

3:01two networks via this protocol is painful.

3:05So the question is, why are we building out on layer two?

3:08Why don't we just do layer three?

3:09We could do layer three to the access layer.

3:11That is an option.

3:13So why aren't all organizations deploying layer

3:15three out on the networks?

3:18Well, this comes down to this concept of policy.

3:20Think about this for a moment, where do we

3:22deploy our security policies?

3:24Where do we deploy our QoS policies?

3:27In most cases, we're deploying these to a VLAN or potentially

3:32a subnet.

3:33And of course, in most networks, there's a one to one

3:35relationship between these.

3:36Because our policies are getting deployed to the VLANs,

3:39we need these VLANs to be stretched.

3:42We need them to exist as many places as possible, which

3:45makes us so we can't deploy layer three to the access layer

3:47in most cases.

3:48Because again, with the limitations of networking,

3:51we know that if I've got a switch out here that's

3:54connected down and it's a layer three communication, well,

3:57whoever is connected to this switch

3:59and whoever is connected to the switch on the right,

4:01these two devices can't be on the same subnet.

4:04They can't be on the same VLAN, because they have layer three

4:06segmentation between them.

4:08And here's the question that we have to ask in all of this,

4:11why?

4:12Why are we deploying networks in such a way

4:15as if this was the 1980s or 1990s?

4:18Why haven't we evolved beyond Spanning Tree, for example?

4:21Why haven't we gone away from policies being tied to VLANs?

4:25Why can't we do layer three everywhere

4:27and allow these hosts to be on the same subnet?

4:31And as if that's not all bad enough,

4:33how are we doing all of this configuration?

4:35How are we doing all of this maintenance?

4:37Usually, it's you and me with the network techs.

4:40We're logging into these devices manually,

4:43deploying these policies, tuning Spanning Tree,

4:45doing our best to maintain this network

4:48as it becomes more and more critical to our business needs.

4:51And as much as I personally love being on the CLI,

4:53I know that it's inefficient, and I

4:56know that it's error prone.

4:58It's like when you're driving.

4:59You trust yourself at the wheel, but you don't

5:01trust anybody else around you.

5:03And the CLI is the same way, right?

5:05I trust myself, but I don't know that I would trust my co-worker

5:08to go properly configure something on the network core

5:11without me.

5:12And so we know that humans are error prone.

5:14We make mistakes.

5:16And the reality is that we have the technology

5:18to do this better.

5:20We've got ways of architecting this

5:22so that our policies aren't bound to our VLANs anymore.

5:24We can have computer systems, software

5:27go out and do the configuration, so we're not

5:30being inefficient with our time, and we're not making mistakes.

5:33And yet, we can get away from Spanning Tree.

5:35We can finally deploy layer three everywhere

5:36and rid of that protocol once and for all.

5:39So I think all three of these are

5:41doable if we continue to explore software-defined networking

5:44and the benefits that it can provide.

5:46So with that, I hope this has been informative for you.

5:48And I like to thank you for viewing.

0:00OK, I got a riddle for you.

0:01Why did the network engineer cross the road?

0:04And the answer, probably to get around spanning tree

0:07because sometimes it feels like that's half of what we do

0:09is dealing with the pain points that spanning tree provides.

0:12As I mentioned last video, we've got chassis switches

0:14and stackable switches and virtual port channels,

0:16and all these are great at helping

0:18us deal with spanning tree, but none of them

0:20outright get rid of spanning tree.

0:21In this video, we're going to explore the concept of overlays

0:24and underlays, and as we're going to see,

0:26overlays will help us finally get rid of spanning tree

0:29in our networks.

0:30And on top of that, they're going

0:31to add a lot of other benefits as well.

0:33So let's go ahead and dive in.

0:34In many cases, the physical design of our network

0:37can dictate what the logical configuration

0:39is going to look like.

0:40For example, we take a look at a traditional network here.

0:43This is kind of what we draw in the last video.

0:45How we have a distribution layer up here,

0:48and then we have client A and client B,

0:49and for whatever reason, these two clients

0:51need to be on the same subnet.

0:53Well, if we want them on the same subnet and therefore,

0:55the same VLAN, we're going to have

0:57to extend Layer 2 through this topology, which

1:00means that we're now creating a large Layer 2 domain.

1:03And again, we discussed this.

1:04This is problematic because now we

1:05have to worry about spanning tree and first hop redundancy

1:08protocols and all kinds of things

1:10that are required in order to extend Layer 2 everywhere.

1:13Unfortunately, in traditional networks,

1:15we don't have much of a choice.

1:16We're going to do what we can in this scenario,

1:18and usually what we can do is convert these links to trunks

1:21or maybe they're trunks to begin with

1:23and we'll extend that VLAN down and increase the broadcast

1:26domain of that VLAN.

1:27In order to overcome this, this requires a new way

1:29of thinking about how we build networks,

1:32and part of the way we're going to build networks

1:34differently is by leveraging an overlay.

1:36Let's take a look at an example here of a network that

1:38has five devices, and let's say that they are

1:40physically connected like this.

1:43Some kind of strange configuration, and that's

1:45well and good, except what I really

1:47want is for this router in the middle

1:50to have direct connections to the four different routers.

1:53I want this to be my network design,

1:55even though I understand that this connection

1:58right here and this connection right here,

2:00these don't actually physically exist.

2:02Well, in order to accomplish this,

2:03I can leverage an overlay, and an overlay really

2:06is just a bunch of network tunnels

2:08that create the architecture that I want.

2:10So now in my green network here, these

2:11are all tunneled connections.

2:13Tunneling requires encapsulation de-encapsulate,

2:15and so when I send from this router

2:18here in the middle to the router down here at the bottom left,

2:21yeah, physically it has to follow where there's actually

2:24connections, right?

2:25I mean, at some point, we are still

2:26bound by the physical network.

2:28However,

2:28I'm going to encapsulate it into a tunnel on the router

2:31and physically send it down to this router,

2:33down the bottom right, but that router in the bottom right

2:36is not going to see the details of that packet.

2:38It is simply going to say, you know

2:39what, you're destined for the router in the bottom left,

2:42so I'm going to forward it right along.

2:44And that router will receive it and de-encapsulate it.

2:46And effectively, what we've done is

2:48we've sent it logically directly to the destination router.

2:52So the way I like to describe this

2:53is to say that we might have a bunch of physical equipment

2:57and they're physically connected in some way,

2:59but then what we do is we lay a piece of paper

3:01on top of that network topology and we draw the topology

3:06that we actually want.

3:07And the topology we want, this is the overlay.

3:10Whereas, the topology that we have,

3:12this here, is the underlay.

3:14So let's look back at the network on the left.

3:16What if we didn't make this a trunked interface?

3:19What if we made this a Layer 3 connection instead of Layer 2?

3:22You're already saying, OK, Jeff, that's great and all except we

3:25needed A and B to be on the same subnet.

3:28In order to do that, we need to extend Layer 2,

3:30but what if that Layer 3 network is simply our underlay?

3:33What if we design an overlay that will give us

3:35what we actually want?

3:37And what we actually want can be accomplished

3:39by extending a Layer 2 tunnel between these two switches.

3:43Now we can share, let's say VLAN 100 between the two switches

3:47while still having a Layer 3 network that

3:50is serving as the underlay.

3:51And we can accomplish this with a protocol

3:53we call VXLAN or the virtual extensible local area network

3:57protocol.

3:58This is a Layer 2 tunneling mechanism

3:59that allows me to accomplish exactly what I've drawn out

4:02here.

4:02So this is great for a campus environment,

4:04but especially imagine it in a data center infrastructure.

4:07We might have hundreds of data center edge switches

4:10and the need to keep VLANs spread

4:12throughout the entire data center.

4:13Well, now we can have all of these hundreds of switches

4:16connected at Layer 3, and Layer 3 means no spanning tree.

4:20We're done with spanning tree.

4:21We said it's obsolete.

4:22We want to get rid of it, and this

4:23is how we can get rid of it.

4:24Incidentally, we can get rid of first hop

4:26redundancy protocols as well because the first hop

4:29redundancy protocols used to run in the distribution layer.

4:31But now that we have a Layer 3 network,

4:33those gateways can no longer live in the distribution layer,

4:35and so we get rid of first hop redundancy protocols

4:37and install anycast gateways at each of the switches.

4:41So this paradigm allows us to get rid

4:43of protocols left and right.

4:44It's a really good deal.

4:45Now this is great for Layer 2, but what can

4:47we do from a Layer 3 perspective?

4:49Well, let's think about an MPLS domain.

4:51In most cases with MPLS, we are going

4:53to share our routes with our service provider

4:55and those also get shared among all of the service provider

4:58routers.

4:59This allows, for example, site A traffic

5:01to reach site B via the MPLS cloud rather than having to get

5:04sent down to the core and back up, which would be inefficient.

5:08But the downside to this is that the MPLS provider now

5:10needs to know about every single subnet in my environment.

5:13Well, what if we turn the MPLS circuit into an underlay?

5:17What if, instead of sharing routes

5:18with our service provider, we extend

5:20tunnels between our sites?

5:23Now I no longer need to worry about sharing my routes

5:26with the service provider.

5:27Instead, I send the traffic at the data plane level

5:31to the service provider router and that router's only purpose

5:34is to get the traffic across its own domain.

5:37It will send that traffic across the MPLS domain

5:39and then get dropped off with the appropriate router.

5:43Now, yes, physically, we are still sending traffic

5:45into the MPLS cloud, and it is bouncing around

5:47all of the routers in there, and then physically

5:50lands at our remote site.

5:51But what's happening from a logical perspective

5:54is I am directly handing that traffic from one of my switches

5:57to my remote routers.

5:59From a logical perspective, this is a direct connection.

6:01These two routers would see each other, for example,

6:04as OSPF neighbors or EIGRP neighbors

6:07or whatever routing protocol we're running.

6:08And we have plenty of protocols today that would support this,

6:11such as GRE, but also Cisco's locator ID separation protocol

6:15or LISP.

6:15So it's really good that we have the protocols in order

6:18to get this done, but here's the question,

6:20would you want to do this manually on your own?

6:22Because I could have come to you 10 years ago and said,

6:24hey, we've got these GRE tunnels,

6:26and we could build tunnels everywhere in the network.

6:28And the response from you, rightfully so,

6:31should be, oh my goodness, I don't

6:32want to have to manage and maintain all of those tunnels

6:34over time.

6:35What if one change happens and that's

6:37going to propagate throughout my whole network?

6:39I mean, the idea of manually configuring and managing

6:42all of these tunnels would be a nightmare.

6:44But fortunately, this is something

6:46that software defined networking helps us get around

6:48because now we have a software controller that can manage

6:50all of these tunnels for us.

6:52And so it's a game changer in the fact

6:53that we can deploy these tunnels automatically and achieve all

6:56the benefits that they provide.

6:58So what are our takeaways?

6:59Well, first of all, we know that the physical topology

7:01of a network is largely going to dictate

7:03for us what that logical topology is

7:05going to need to be.

7:06And that's no good.

7:07We don't want that anymore.

7:08We want to get away from that restriction.

7:10And so in order to accomplish that,

7:11we're going to take the physical network

7:13and turn that into a network underlay.

7:15Now the underlay isn't going to necessarily know

7:17where all of the clients in the network are.

7:19Its main concern is getting from one end of the underlay

7:22to the other end.

7:23And if the underlay is what we have

7:25in the physical architecture, then the overlay

7:27is what we want.

7:29And we accomplish that by building tunnels

7:32over, being the overlay, over the underlay.

7:35And so what we're going to find is

7:37that SDN is the glue that holds all of this together.

7:40So with that, I hope this has been informative for you,

7:42I'd like to thank you for viewing.

0:00It is time to hold Cisco's feet to the fire,

0:02and fortunately, there is no literal fire.

0:04We don't need protective gear or anything like that.

0:06We simply want Cisco to show us what they've been doing,

0:08because they've been telling us all about this software defined

0:11world and how important it is for us to learn

0:13programmability and such.

0:15But what have they been doing to make sure

0:18that they are relevant in this age of software

0:20defined infrastructures?

0:21Well, in this video, we're going to explore

0:22all of the different solutions that Cisco

0:24offers where they've integrated software defined networking.

0:27Let's dive in.

0:28Given this is a course on software defined access and DNA

0:31Center, it probably makes sense to start

0:32with that particular solution.

0:34But in order to understand what SDA is we

0:36need to understand the Campus Fabric.

0:39Here the idea of the Campus Fabric.

0:40Typically, we have some number of core devices,

0:42and this would include a true network core,

0:44it would include distribution layers and such,

0:47whatever holds the core of our network together.

0:49And then we have these edge switches.

0:51These would be our access layer switches out

0:53in our access closets, and our users

0:54are attaching to these edge switches.

0:56And let's say we have a couple of access switches on the right

0:59and a couple more here on the left,

1:00and these are all connected in to these core devices.

1:04Whatever those connections are, they're

1:05kind of irrelevant because this forms that underlay concept.

1:10This is the physical layout of our network devices,

1:13and it's no longer relevant for how we're

1:15going to deploy our network.

1:16And the reason it's no longer relevant

1:18is because we're going to deploy an overlay on top

1:21of this = In a Campus Fabric environment,

1:24we are going to form that overlay between all

1:26of these edge devices.

1:28We're going to turn all of those core and distribution devices

1:30into the underlay, which means it's the network that's

1:33holding all this together.

1:34As such, when we have a user attaching to the switch,

1:37it gets put into the tunnel and forwarded out

1:40to the appropriate egress switch,

1:41so it can communicate with its destination.

1:44Cisco defines the Campus Fabric as such.

1:46We use VXLAN for the data plane.

1:49That would be the tunnels that we've drawn out.

1:51However, VXLAN does not define our control plane information

1:53for us.

1:54In other words, when I send my packet to this switch,

1:57how does this switch right here know

1:59where to send that traffic?

2:00It's got to put that into a VXLAN tunnel

2:02and forward it to a remote switch.

2:04We have no idea which switch to send it to,

2:06and that's why we need a control plane,

2:07to tell us where in the network other devices are.

2:10And we have a lot of different options for control planes,

2:12but in a Campus Fabric, we're going

2:14to use a Cisco protocol called the locator ID separation

2:17protocol, or LISP, and that will be our control plane.

2:20Now this is a great start, but it still

2:21falls short in one key area.

2:23In a Campus Fabric, Cisco wants integrated security,

2:26meaning it's not an afterthought.

2:28It's not something we layer on top.

2:30It is something that is built into the very fabric

2:32of this network, and the way we're

2:34going to accomplish that is by deploying Cisco Trust

2:37SEC or CTS.

2:39Cisco Trust SEC is going to provide integrated security

2:42for us by identifying who this person is,

2:45who they're trying to speak to, and whether that communication

2:48should even be allowed.

2:49In order to deploy Cisco Trust SEC,

2:50we're going to leverage the identity services engine

2:53or ISE, another Cisco product that

2:55can be deployed on its own, but when combined with VXLAN

2:58and when combined with LISP, this forms what

3:01Cisco calls the Campus Fabric.

3:04Now if you're like me and you love being on the CLI,

3:06you might be inclined to fire up your computer,

3:08connect to these network devices,

3:10and deploy VXLAN tunnels and deploy LISP at the CLI,

3:14and to deploy ISE into your environment,

3:16and that works great.

3:17We can deploy a Campus Fabric in that way.

3:20However, that is a very manual process,

3:22and we talked about the disadvantages

3:24of manual systems.

3:25This is extremely inefficient for me

3:27as a network engineer to try to build and maintain over time,

3:30and it's error prone.

3:31I might make a mistake.

3:33Instead, it would be fantastic for us

3:34to have a true software defined networking solution that

3:37involves a controller, and the controller

3:40that Cisco created to deploy a Campus

3:42Fabric is called DNA Center.

3:44So where does software defined access fall into all of this?

3:48Well, software defined access, or SDA, is like a math problem.

3:51We say SDA is equal to a Campus Fabric plus DNA

3:56Center or DNA-C. If I leverage DNA Center,

4:00I deploy that as a controller into my infrastructure, which

4:03by the way, today is a physical controller.

4:05So I'm installing a physical appliance into my network,

4:08and I have it deploy a Campus Fabric,

4:11and I have it manage and monitor and maintain that Campus Fabric

4:14over time, then according to Cisco, that

4:17is software defined access.

4:19However, software defined access is not

4:21the only software defined networking solution Cisco

4:23has in their portfolio.

4:24They have two other such solutions,

4:26and it's important that we understand

4:28exactly what those are.

4:29The first solution is called software defined WAN.

4:32Software defined WAN is more than just an industry trend.

4:35In this case, it is the name of Cisco's product.

4:37Cisco originally developed their own software defined WAN

4:39infrastructure, called iWAN.

4:41However, iWAN has been deprecated

4:43because Cisco went out and bought

4:44a company called the Viptela.

4:46And Viptela, we no longer call any

4:48of Cisco's products Viptela.

4:49We've retired that name.

4:51Instead what we have is Cisco SD-WAN.

4:54So, yes, SD-WAN is the technology trend,

4:56but it is also the name of Cisco's product.

4:58Now in the case of SD-WAN, this is

4:59going to look very similar to us after exploring what software

5:02defined access looks like because we're

5:04going to have a WAN environment where we have a service

5:07provider in the middle that's providing connectivity

5:09to all of our routers.

5:11And traditionally, we have to share routes back and forth.

5:14We mentioned this in an earlier video,

5:16and that's all well and good, except wouldn't it be great

5:18if we didn't have to do that?

5:20And the service provider didn't have

5:21to know all of the routes in my network in order for me

5:23to communicate?

5:24Well, that is exactly what SD-WAN solves for us.

5:27It does the same concept of building those tunnels out

5:29from edge routers to edge routers.

5:31However, instead of VXLAN, we are

5:33going to use IPSec tunnels since SD-WAN

5:35is really more of a Layer 3 technology,

5:37and we don't need the Layer 2 benefits that VXLAN provides.

5:40One of the best benefits to this technology

5:42is that I can actually have a second WAN service

5:45provider in the mix, and I can build tunnels through that WAN

5:49service provider as well.

5:50So now I've got a completely integrated solution

5:52with multiple tunnels to the same destinations,

5:55and I can choose the best path depending on the scenario.

5:59So, for example, if I'm trying to communicate from router A

6:01to router B, I know I've got two different paths I can choose.

6:04One goes through one service provider,

6:06and one goes through the other.

6:07And so maybe depending on my application,

6:09I might want to choose one over the other.

6:11Maybe one has more bandwidth, but the other service provider

6:13is more reliable, and so it gives me

6:15full control over my network traffics in an SD-WAN solution.

6:19Now no SD-WAN solution is complete without a controller,

6:22and SD-WAN is no exception.

6:24In Cisco SD-WAN we have a controller called the vManage.

6:27Now the little v in vManage is actually

6:29a reference to Viptela, but make no mistake.

6:31This solution has been fully integrated with Cisco hardware.

6:34We can deploy ISR routers, for example, to the edge

6:37and participate in an SD-WAN architecture.

6:40Now the last solution we need to be aware of

6:42is called application centric infrastructure, ACI.

6:45This is a data center technology that's

6:47going to work again, very similarly to SD Access,

6:50even in the fact that we use VXLAN.

6:52The difference lies in the underlay.

6:54In the data center, we're going to build a spine leaf topology,

6:57where we have a spine layer of switches,

6:59and we have a leaf layer of switches.

7:02And we connect every spine to every leaf

7:03but no spines connect to other spines

7:05and no leaves connect to other leaves.

7:07And you guessed it.

7:08We're going to build those VXLAN tunnels among all of these edge

7:12devices.

7:13And because we have these VXLAN tunnels,

7:14our core devices no longer need to know

7:16all of the different Mac addresses and IP addresses

7:19that live in this environment.

7:21That drastically improves our ability

7:22to Layer 2 scaling any data center, which

7:25with traditional infrastructures,

7:26this is a big problem.

7:28But ACI makes that solution quite simple.

7:30We deploy Cisco's Application Policy infrastructure

7:33Controller, or APIC, as the controller

7:35that manages this SDN solution.

7:38So as you can see here, Cisco has invested heavily

7:40into software defined infrastructures.

7:42In fact, they have three different solutions

7:44for three different places in the network.

7:45First of all, we have this concept of Campus Fabric.

7:48Campus Fabric is VXLAN plus LISP plus Cisco Trust SEC,

7:51and then if we add DNA Center in,

7:53now we have software defined access or SDA.

7:56SDA belongs where the users are.

7:58Now Cisco's SD-WAN product, that belongs

8:01where the wide area network is, which is what the name implies.

8:04We're going to use that to help us better utilize

8:06our WAN circuits.

8:07And last but not least is application

8:09centric infrastructure, ACI.

8:11ACI belongs inside the data center

8:12and helps us really get a grasp on Layer 2 scaling

8:15inside the data center, which traditional architectures

8:18struggle with.

8:19So Cisco has given us three different options for three

8:22different network locations, and we can leverage

8:25the best one for the need.

8:26So with that, I hope this has been informative for you,

8:28and I'd like to thank you for viewing.

0:00We've reached the end of our skill,

0:01and that means it's time to review what

0:02we've learned by taking a quiz.

0:04Don't hesitate to pause this video if you need more time

0:06to answer any of the questions.

0:07So first up out of four questions,

0:09what original goal of SDN failed to align

0:12with organizational care-abouts?

0:19Well, using controllers to improve management is not

0:21only something we cared about then,

0:22it's something we care about now.

0:24As is offering network assurance.

0:25This idea that we can use artificial intelligence

0:27and machine learning to proactively tell us what's

0:30going on in our network.

0:31Increase programmability features.

0:33If Cisco's defnet program is any indication that programmability

0:36features are still highly desirable in this space.

0:39Last but not least, commoditizing network hardware,

0:42making it so we can deploy any old switch into the network

0:45isn't something that the industry actually

0:46cared all that much about.

0:48And so D is the answer.

0:49SDN originally wanted to help commoditize that network

0:52hardware and make it so a Cisco switch is really no

0:54different from a Dell switch.

0:56But fortunately for us in the Cisco world,

0:58this didn't come to pass, and Cisco's doing

1:00just fine and dandy in this SDN world.

1:03Next up, where are network policies

1:05typically applied in traditional network architectures?

1:12Well, I'll admit this is a little bit

1:14of a subjective question because we're

1:15asking where it's typically applied,

1:17and we can always find exceptions to these rules.

1:19However, what we're going to find in most network

1:21architectures is that our network policies

1:23are being deployed to VLAN interfaces

1:26because it allows those policies to be deployed between subnets.

1:29If we're to deploy policies under the switchpot,

1:31that would be even worse than deploying it

1:32to a VLAN interface.

1:34However, the ultimate goal of what we really

1:36want to accomplish is to deploy policies

1:38to the users that are attached to the network,

1:41and this can apply to applications as well.

1:43So if a particular user application

1:44needs a security policy or a QoS policy

1:48or any number of different network policies

1:50than we can apply those wherever in the network

1:52they're attached.

1:53Whether they're attached wirelessly

1:54or to a physical switch part or through the data center,

1:57for example.

1:58Sort of the goals of SDN is to remove this restriction

2:00that we have by applying policies

2:02to VLANs and subnets and other network constructs

2:05and apply them to the actual entity

2:07of the user or the application that we're

2:09trying to apply that policy to.

2:11So all that to say, the answer here is B.

2:14Question number three, what new network paradigm

2:17is formed by the use of tunnels?

2:23Well, if you check out the source down here,

2:25it's probably one of these two, right?

2:27If we remember, the underlay is the physical network,

2:30so that would be the network that we have.

2:31Remember, we drew this picture where

2:33we kind of attach all these routers in some fashion,

2:36and then we pretend to put down a piece of paper

2:38and we draw those same four routers, except we attach them

2:40in whatever way we want.

2:42This now is the logical formation of the network,

2:45and we form this via tunnels.

2:47Now as you can tell by the way we do this,

2:49the overlay is going to consist of the tunnels

2:52and that goes over the underlay, which is the physical network.

2:56So our answer is the overlay.

2:58Last question here, what are the major components

3:00of Cisco Software Defined Access or SDA?

3:09Well, we've got to first remember

3:10what Cisco SD Access is all about, and remember,

3:13it's like a math problem.

3:14SDA is equal to Campus Fabric plus DNA Center.

3:19Now we do find the DNA Center is one of our answers, however,

3:22what are the components of Campus Fabric?

3:24And remember that this is a math problem as well,

3:26because Campus Fabric is equal to VXLAN

3:29plus LISP at the control plane, plus Cisco Trust SEC, which

3:34by the way is deployed via the identity services

3:36engine or ISE.

3:37So we have four different components

3:39as part of the Campus Fabric, and we

3:40can see that those are all in our answers.

3:42So we have ISE, Cisco Trust SEC, VXLAN, and LISP.

3:46In fact, the only answer that we don't need that's listed here

3:49is spanning tree protocol, and that is a huge blessing.

3:52One of the goals that we should have

3:53for deploying an SDN fabric is to eliminate spanning tree.

3:57So that wraps up this quiz.

3:58How did you do?

3:59If you find yourself with any gaps in your knowledge,

4:01make sure and go back and watch the appropriate videos

4:02in order to fill those.

4:03Otherwise, congratulations on completing describe software

4:06defined networking.

4:07I hope this has been informative for you,

4:08and I'd like to thank you for viewing.