Explain VXLAN and EVPN

0:00[MUSIC PLAYING]

0:05Welcome to explain VXLAN and EVPN.

0:08VXLAN or the Virtual Extensible Local Area Network

0:11is an extension to VLANs.

0:13It's going to help us scale outer layer 2 data centers.

0:15And Ethernet VPN or EVPN, that's going to help us

0:19know where all of the MAC addresses in our data center

0:21live.

0:22It actually combines with VXLAN.

0:24Because what we're going to find is that VXLAN is a great data

0:27plan protocol, but it doesn't really

0:28have anything in the way of a control plane.

0:30And that's where EVPN is going to come to the rescue.

0:33So throughout this skill, we're going to focus primarily

0:35on how VXLAN operates.

0:36And then at the end, we'll see how EVPN comes in and really

0:39complements it well.

0:40Come on and have a lot of fun with me exploring

0:42how exactly VXLAN is going to work for us inside our data

0:46centers.

0:46With that, I'll see you in the next video.

0:00[MUSIC PLAYING]

0:05So why are we using VXLANs?

0:07And what are these Virtual Network Identifiers, or VNIs,

0:09that we keep hearing about?

0:10In this video, we're going to unpack

0:12what exactly VXLAN does for us in the data center

0:14and how it accomplishes it.

0:15And then also learning more about that Virtual Network

0:18Identifier, or that VXLAN tag.

0:20Let's take a look.

0:21If we're going to talk about a new technology then

0:24we better find out ways that that new technology

0:26is making our life easier.

0:27And so let's start with the problems that we have.

0:30In a data center today, we're running out of VLANs.

0:33When you think about modern enterprise,

0:35service provider data centers, a lot

0:38of times we deliver VLANs per customer,

0:40maybe a set of VLANs per customer.

0:42But we only have 4096, so let's called that 4K VLANs,

0:46we're going to run out pretty fast,

0:47especially in the modern era.

0:49Furthermore, we're still scaling with Spanning Tree Protocol.

0:52And not to mention Spanning Tree Protocol, but also first hop

0:55redundancy protocols, which are often limiting us to,

0:58let's say two aggregation switches,

0:59in a particular architecture.

1:02And so we do throw things in there

1:03like virtual port channels and such,

1:05but it's really just patchwork.

1:07We're still dealing with archaic technology like Ethernet,

1:10broadcast storms, Spanning Tree Protocol, again.

1:12And we've got to get away from that in our data centers,

1:15if at all possible.

1:16And lastly, when we expand our data

1:18centers via these Layer 3 pods, we

1:20introduce Layer 3 boundaries.

1:22And layer 3 boundaries that causes problems

1:24because we like Layer 2 in our data center.

1:27That's why have all of these problems,

1:28really, is because we are so obsessed with Layer 2

1:31inside of our data centers, to keep our applications

1:33on the same subnets, or for that matter,

1:35dealing with storage traffic and live migration and such.

1:38So this is where VXLAN is going to come to the rescue.

1:42VXLAN is going to enable us to better scale our networks,

1:44and it's going to accomplish that in two primary ways.

1:47First of all, it's going to increase

1:48the number of broadcast domains that we have available to us.

1:51So when we're talking about the number of VLANs for example,

1:54we don't need to worry about that anymore.

1:55We can way beyond 4,000 with the VXLAN.

1:58And second of all, VXLAN is going

1:59to enable us to punch through our Layer 3 domains.

2:02It's going to extend Layer 2 over Layer 3,

2:05which means we're no longer going to be bound by this Layer

2:073 pod architecture that we've been building our data

2:09centers with.

2:10So the way this works is, when we take our data center

2:13switches, we're still going to be connecting them

2:15downstream to our 4,000 VLANs.

2:18That part isn't going to change.

2:19However, when we enable VXLAN on the switch,

2:22it becomes what's known as a VXLAN Tunneling Endpoint,

2:25or VTEP.

2:26Now one VLAN is going to get mapped, in most cases,

2:29to a single Virtual Network Identifier, or VNI.

2:32We might have a couple of VLANs coming in, they each get

2:35mapped to different VNIs.

2:36And then each one of those VNIs is

2:38going to be able to be extended through a Layer 3 boundary.

2:42Let's say we have now this Layer 3 architecture,

2:44we're sending it through a Layer 3 network, or fabric,

2:47and then we connect to another VTEP on the other side.

2:50Well, that VTEP is going to receive those VNIs, that

2:54encapsulated traffic that VXLAN has enabled us to send,

2:57and it's going to translate that back into the individual VLANs

3:00that we're originally connecting with.

3:02That means that we have effectively extended this Layer

3:042 network all the way across through this Layer 3 boundary.

3:08Furthermore, we might have a lot of different VTEPs out here.

3:11We'd have dozens, or even hundreds, of VTEPs

3:13on this Layer 3 network.

3:14Because, hey, Layer 3 allows us to scale.

3:16So we don't need to worry about a whole lot of our limitations

3:19anymore, at least as far as network segmentation is

3:21concerned.

3:22And so we can connect to as many of these VTEPs as we desire,

3:25and each connection is going to be a tunneled interface that's

3:28going to be from loopack interface

3:29to loopback interface.

3:30Now in order to accomplish this, we're

3:32going to use a VXLAN header.

3:33We're going to break down the packet here in the next video.

3:36But for now, the VXLAN header is an 8 byte header,

3:38that's got 1 byte dedicated for flags,

3:423 bytes dedicated to this Virtual Network Identifier.

3:44And if we do quick math there, that's 24 bits.

3:47That means we have 16 million different Virtual Network

3:50Identifiers.

3:51Technically by the way, it's 16,777,216.

3:56So I would say that's closer to 17 million

3:59relative to 16 million.

4:01But, hey, everyone likes to say it's 16 million

4:03and that's fine.

4:04And then that leaves 4 bytes left that are simply reserved.

4:08So we're not going to use those inside the data

4:10center for the most part, however for example,

4:12we do see Cisco take advantage of some

4:13of that space in their Software Defined Access, or SDA

4:16solution, that exists in the Campus environment.

4:19Now something we need to be aware of with these VNIs,

4:21is that they can be scoped differently

4:22depending on our desire.

4:24We have two primary ways of scoping the VNIs.

4:27First of all is a network scope.

4:29Network wide scope means that if we're going to apply,

4:32let's say this VNI, let's just call this VNI,

4:35I don't know, 100,272.

4:38Why not.

4:39So if we were to apply that VNI to a particular VLAN in here,

4:43maybe it's VLAN 10, the question we need to ask

4:45is whether this identifier is significant

4:48only to the local switch, or to the entire network.

4:51So again, we have the idea of scoping it

4:53via the whole network, and then we also

4:55have the idea of scoping it locally.

4:57So what's the difference here?

4:58Well if it's scoped network wide,

5:00then that means that 100,272 on this

5:03switch also from presents that VLAN 10.

5:06At least that same broadcast domain,

5:08even if we'd use a different VLAN

5:09identifier on the other side.

5:11But that's true also for all of these different VTEPs that

5:14are on the network.

5:15So across dozens, and maybe even hundreds,

5:17or thousands of VTEPs on our network,

5:19we have to reserve that VNI everywhere.

5:22Even if that broadcast domain doesn't exist on all of those

5:24switches.

5:25Now on the one hand that's inefficient, on the other hand,

5:27we have 16 million of these, so maybe it doesn't particularly

5:30matter.

5:31And so that's why the benefit to a network scope

5:33is that it's simple.

5:35We don't need to worry or stress out about that VNI changing

5:37anywhere, it's going to be the same

5:39throughout the entire network.

5:40The downside is management, because we

5:43have to worry about the fact that this VNI is

5:46reserved everywhere.

5:47We can't repurpose that VNI, by accident,

5:49anywhere in the environment.

5:50And on the one hand, yes, again, 16 million is a lot of values,

5:54but on the other hand, we can start

5:56to overlap pretty quickly, especially in very large scale

5:58data centers.

5:59This is where we might want to consider a locally scoped VNI.

6:02A locally scoped VNI is going to behave a little bit like MPLS,

6:06for those who have studied MPLS tags.

6:08And the way this works is, this 100,272 VNI

6:12might come in on this switch and be received on a different VNI.

6:16It might be received on 256,771.

6:21Now the same policy gets applied,

6:23it still gets mapped to the same broadcast

6:24domain on both sides as VLAN 10 example that we're using.

6:28But the advantage to this is that we

6:30don't have to worry about overlapping VNIs

6:32anywhere else in the data center,

6:33we only need to worry about it on a local switch.

6:35100,272 only needs to apply to this specific VLAN

6:40on this specific VTEP.

6:42So the advantage of this is, from a management perspective

6:45it can be a little bit easier, but the downside

6:47is that it's less readable from a human perspective.

6:50I can't just look at this VNI over here, 256,771,

6:54and know intuitively that it maps over here to this VNI.

6:58So as we can see, VXLANs are a game changer in the data center

7:01space.

7:02They're going to vastly increase our scalability from a Layer 2

7:05perspective.

7:05And they're primarily going to handle

7:07that in two different ways.

7:08First of all, we have those 16 million different VNIs

7:11at our disposal, that's an incredible amount of broadcast

7:14domains that we can now support.

7:15And second of all, we can now tunnel our traffic, our Layer 2

7:18traffic, through a Layer 3 fabric.

7:20That's going to change the way that we build our data centers,

7:22as we're going to continue to see throughout the skill.

7:25Now lastly, when it comes to those VNIs,

7:27we need to keep in mind that we have two different scopes.

7:29We have the network based scope, that

7:31means that we are going to have one VNI represent

7:34a particular broadcast domain everywhere

7:36throughout the entire data center.

7:37And in some cases, smaller data centers especially,

7:39it's going to make a lot of sense.

7:41But then we also have this concept of locally scoped.

7:43Locally scoped means the VNI is only

7:45significant to the local switch, and those tags

7:47change as we traverse the network.

7:49And so that's going to matter more for large scale

7:52deployments and large scale data centers, as opposed

7:54to the smaller ones.

7:55I hope this has been informative for you

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

0:05By now, you've probably heard about leaf-spine architectures,

0:08this crazy new way of connecting all of our data center

0:10switches together inside of these larger fabrics.

0:13If you've been working your way through the DC Core Course,

0:15then we've mentioned this a couple of times.

0:17And maybe, again, you've seen this already in the real world.

0:20But the reality is that leaf-spine is only doable

0:23because we have VXLAN.

0:25VXLAN gives us the layer 2 scaling across layer 3 fabrics,

0:29and hey, guess what?

0:30That totally enables us to deploy

0:32leaf-spine architectures.

0:33So in this video, we're going to take a look

0:35at how VXLAN and the leaf-spine come together

0:37in order to deliver these large-scale deployments.

0:39Let's take a look.

0:40As mentioned, leaf-spine is becoming very popular

0:42these days.

0:43Leaf-spine can also be occasionally referred to

0:46as a Clos fabric.

0:47And this is named after Charles Clos, which maybe I'm

0:50saying his name wrong.

0:51I don't know.

0:51But either way, the Clos fabric or the leaf-spine architecture

0:54has been around for a very long time.

0:57So the question is, why is it becoming popular now?

0:59And the short answer is VXLAN.

1:01Let's go ahead and draw this out.

1:03And what we find here is that we've got

1:05a spine layer and a leaf layer.

1:08Let me label these.

1:09We've got spines up here, and we've

1:11got leaf switches down here.

1:13And at first glance, this is going to look pretty similar

1:16to an aggregation access layer, where we might have the network

1:19core up here-- and we call this the Agg layer--

1:21and the access layer down here.

1:23But the similarities end pretty quickly,

1:25because right away, we see that we connect these switches very

1:28differently.

1:29Specifically, we connect spine switches to leaf switches.

1:32So every leaf to every spine, every spine to every leaf.

1:35And that's it.

1:36We do not connect spines to spines.

1:38We do not connect leaf switches to leaf switches.

1:41And the differences don't end there,

1:42because we're accustomed to the intelligence of the network

1:45living higher up on these higher layers, but not so

1:48with spine switches.

1:49All of the intelligence actually lives down here

1:51at the leaf layer.

1:53The spine switch has one job--

1:55to bring traffic in and send it right back out.

1:58We want to switch traffic between our leaf switches

2:00as fast as possible.

2:01That is all the spine switch is designed to do.

2:04Furthermore, our external connections

2:05don't come into the spines.

2:07Our internet block, for example, is

2:08going to come in at the leaf layer, as is the campus

2:12architecture.

2:12So when we connect back to the campus or possibly the network

2:15core, that's going to come in at the leaf layer, as well.

2:18The leaf-spine is designed for scaling.

2:21We absolutely need to be able to scale out to very large layer

2:242 fabrics in our data centers today.

2:26We've made that comment a couple of times now.

2:28And we talked about how VXLAN helps us to scale,

2:31but now we need an architecture that scales, as well.

2:33So let's look at how leaf-spine scales.

2:35First of all, we have the independent scaling

2:38of different resources in the data center.

2:40Specifically, we have our backbone layer.

2:43And so when we think about our backbone layer,

2:45when we think about that, we might

2:47think about packets per second and how many packets we

2:49can process in a moment, as well as the bandwidth.

2:52And so if we need additional switches

2:54for processing additional packets, well, guess what?

2:57We just expand the spine layer.

2:58We add another spine, connect that spine

3:00into all the different leaves, and our load balancing

3:02takes care of the rest.

3:03Furthermore, if we need more bandwidth,

3:05we can simply expand the number of connections

3:07that we have between our leaf and spine switches.

3:09Adding a connection to a port channel is not disruptive.

3:12Neither, by the way, is adding a spine switch into the network.

3:15And so we can scale out our network backbone

3:17far more simply than we can with an aggregation layer.

3:20And furthermore, if we need ports,

3:22we need additional connectivity at the edge, well,

3:24we simply add leaf switches in.

3:26So we install a new rack into the data center.

3:28We can throw a couple new leaf switches

3:30at the top of that rack, connect them into the spines,

3:32and voila.

3:33We have expanded our data center footprint.

3:36The second way that we improve scaling with leaf-spine--

3:38and I love this one-- is this concept

3:40of declaring a two-hop behavior for all traffic in the data

3:45center.

3:45In other words, when a packet arrives on a leaf switch,

3:48I guarantee you that, regardless of where it's going in the data

3:51center, it's going to get there not in more than two

3:54hops and not in less than two hops.

3:56It is precisely two hops to every destination.

3:59I always go to one spine switch and that spine switch always

4:02sends me down to the appropriate leaf switch, whichever

4:05leaf switch is my destination.

4:07That's incredible, not just from a latency perspective,

4:09but also from a jitter perspective.

4:11And I know when we talk about network jitter,

4:12we tend to talk about voice over IP packets.

4:15And maybe we don't have a lot of that going on

4:17in the data center.

4:18But all applications are affected by jitter.

4:20And so if we can deliver a consistent experience

4:22in the data center, then that's going

4:24to make all of our applications behave better.

4:26Furthermore, we can make our network services available very

4:29seamlessly throughout the infrastructure.

4:31In other words, we bring our services

4:32into a pair of switches.

4:34Maybe we've got a dedicated pair--

4:36I'm trying to figure out where to draw this in this diagram.

4:38Let's put them up here--

4:39a dedicated pair of leaf switches that

4:42are coming into these spine switches here,

4:44and these leaf switches have all of our network services.

4:47We think about things like network load balancers,

4:49and cloud gateways, and next-generation firewalls.

4:52And because of our two-hop behavior,

4:55we have very seamless access to all of those services.

4:58Furthermore, we have other services,

4:59such as anycast gateways, that we can deploy out

5:02onto the network that reduce our routing behavior

5:05from an overhead perspective.

5:07So we can deploy a gateway to every one of these leaf

5:10switches, meaning that we can get routed locally.

5:12We don't have to get forwarded up to the spine, or formerly

5:15the aggregation layer, in order to get routed.

5:17And by delivering our services everywhere throughout the data

5:19center and making it a maximum of two hops away,

5:22we've enabled those services to be accessible for everyone.

5:25So what's going on with VXLAN?

5:27Why is it so important that it enables this architecture?

5:30Well, the ideal situation with the leaf-spine architecture

5:34is that these connections in here are layer 3.

5:37If we want this architecture to scale out,

5:39we have to leverage layer 3 at some point.

5:42Imagine having dozens of leaf switches

5:43and several different spine switches

5:45and all of the connections are layer 2.

5:47And imagine the spanning tree nightmare

5:49that we're going to have in that situation.

5:51Imagine having our broadcast storms going everywhere.

5:54We need layer 3 scalability.

5:56But at the same time, we need a host on this leaf switch

6:00and a host on this leaf switch to be on the same subnet,

6:03because we need layer 2 services in the data center, as well.

6:06This is why VXLAN is such a beautiful solution,

6:08because now we can have these subnets stretched out,

6:11such that these hosts can be on the same VLAN,

6:13and yet, our fabric is layer 3.

6:16We use VXLAN to tunnel through the layer 3 fabric from one

6:19leaf switch to another and stretch that layer 2

6:21boundary for us.

6:23So it enables a layer 3 backbone,

6:25but then furthermore, again, we've got these 16 million

6:28different segment IDs.

6:29So now we have virtually no limit

6:31to the amount of broadcast domains

6:32that we can have inside a single data center.

6:34So even if we were to make leaf-spine work

6:36on traditional VLANs, we'd be limited to that 4,000 broadcast

6:40domains inside the data center, and that would only

6:42be so effective.

6:44So yes, we can now take advantage of far more broadcast

6:46domains by leveraging VXLAN on top of this architecture.

6:50One more extension to this architecture

6:52we'd want to consider is the idea

6:53of having a virtual host connecting

6:56into one of these leaf switches, and maybe a couple

6:58of these leaf switches.

6:59And the idea here would be that we have a virtual switch

7:02inside of this virtual host.

7:04And Cisco makes these virtual switches-- the Nexus 9000v,

7:07for example, and way back in the day, the Nexus 1000v.

7:11And these vSwitches can run VXLAN.

7:13That said, they are functionally a VTEP.

7:16And by deploying a VTEP into our virtual space,

7:18well, now we need to be able to tunnel straight to them.

7:21Well, in a leaf-spine, we can do that.

7:23We can essentially turn this into a virtual leaf switch,

7:25and therefore extend our VXLAN tunneling policies down

7:30into that virtual space.

7:31This further increases the scale of our environment

7:33to extend down into the virtual domain.

7:35So yes, we can even deploy virtual leaf switches

7:38into our infrastructure.

7:39And that's not just a Cisco technology,

7:41that exists with a lot of the different hypervisor

7:43manufacturers.

7:44So regardless of whether we're scaling out physically

7:46or virtually into the virtual space, either way,

7:49VXLAN on top of leaf-spine architecture

7:51really gives us the scaling that we desperately

7:54need in the data center.

7:55So as we see here, leaf-spine is built

7:57for scaling layer 2 fabrics.

7:59It does the same thing as VXLAN, except where VXLAN does it

8:02from a network logical layer perspective,

8:04spine-leaf does it from a physical perspective.

8:07For example, we see that spines are only

8:09going to connect to leaf switches and vice-versa.

8:10We're not connecting leaves to leaves.

8:12We're not connecting spines to spines.

8:14The only thing we're doing is enabling

8:16the backbone connection, essentially, via the spine.

8:19So a spine switch cares primarily

8:21about bringing traffic in from one leaf

8:22and forwarding it out to the next leaf as fast as possible.

8:25And lastly, we see that leaf-spine connections

8:27are built as layer 3.

8:28We're building a layer 3 fabric.

8:30And VXLAN is the magic that gives us

8:32the ability to move layer 2 packets across this layer 3

8:36boundary.

8:36I hope this has been informative for you,

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

0:00[MUSIC PLAYING]

0:05Now that we know what VXLAN is, and we

0:07know the architecture we're deploying it on,

0:08it's time to investigate how it actually behaves.

0:11In VXLAN, at its routes is very much a data plane protocol.

0:14We're going to find out that we need

0:16to throw some enhancements around, potentially,

0:18to make the control plane work.

0:19But for now, let's first start with the data plane,

0:21and see how exactly it functions when

0:23we're talking about tunneling these packets

0:24through this Layer 3 backbone.

0:25Let's take a look.

0:27So we know that one of VXLANs primary functions

0:29is to extend Layer 2 connections over Layer 3 fabrics.

0:33Let's try this out here.

0:34We've got a switch on the left, and we call this a VXLAN

0:38Tunneling End Point, VTEP.

0:40And we're going to connect that via a Layer 3 connection

0:43to another VTEP.

0:45And maybe there's another bunch of switches in here.

0:47Again, maybe there's a spine switch in here

0:49that connects us between these two leaf switches.

0:51However this comes together doesn't really

0:53matter, what we're trying to accomplish is the same.

0:56So we know that we've got a host on the left here

0:58and it's, let's just say, on VLAN 10.

1:00We've got another host on the right, that's also in VLAN 10.

1:03So how exactly is VXLAN going to extend connectivity

1:06between these two different devices?

1:08Well, the way we're to do this is with encapsulation.

1:11We are going to tunnel our traffic from one VTEP

1:14over to another VTEP.

1:16And so the way this is going to work

1:17is this frame, this Layer 2 frame,

1:19is going to come into the VTEP on the left.

1:21And so let's just draw this out.

1:23And let's show that we have now A Layer 2 frame.

1:25This Layer 2 frame by the way, has an Ethernet header,

1:28it has an IP header, it has a Layer 4 header in there.

1:31And we are going to encapsulate that into a VXLAN header.

1:36Now this VXLAN header is 8 bytes in size.

1:38And as we discussed, this 8 bytes

1:40is going to include a 3 byte, in other words

1:42a 24 bit, Virtual Network Identifier.

1:45That 24 bit Virtual Network Identifier gives us--

1:48You remember now--

1:4916 million different network segments that we can use.

1:52Now we're not done because we still need to get from point A

1:55to point B, and the VXLAN header isn't

1:56going to include information on how to accomplish that.

1:59As such, we're going to, first of all encapsulate

2:01this into a UDP header.

2:03And this UDP header is going to have

2:05a destination port of 4,789.

2:09And finally, we still need our IP addresses in here.

2:12So we're going to throw an outer IP header on there, that's

2:14going to have the source IP address of the VTEP

2:16on the left, and the destination IP address of the VTEP

2:19up on the right.

2:20Now any time we talk about tunneling,

2:22we're going to have to talk about the idea of MTU.

2:25And so we need to figure out how exactly our Layer 3

2:27infrastructure needs to be adjusted for the new MTU

2:29to support VXLAN.

2:31And so if we draw a dividing line right here, and we say,

2:34OK, well this is the original packet,

2:35and so we know that we're good here.

2:37Well look at everything to the left of that line.

2:40We need to account for all of that when it comes to our MTU.

2:43So that Ethernet header is 14 bytes, for example.

2:46The VXLAN header, we've said, is 8.

2:48UDP is another 8 bytes.

2:50And the IP header that we're adding on to the front,

2:52is another 20 bytes.

2:54So we add this all together, 20 plus 8 plus 8, that's 36.

2:57Plus 14, that gives us 50 bytes.

3:00We need to increase our MTU by 50 bytes.

3:03And it's worth noting by the way,

3:04that we do technically have a VXLAN option to include

3:08the Dot1q header.

3:09We're assuming, with 14 bytes, that we

3:11don't have a VLAN tag in there.

3:13If, however, we do have a VLAN tag, then

3:15we need to account for another 4 bytes.

3:17And if we were to include that, then we'd

3:19need to increase our MTU by 54 bytes in actuality.

3:22Now fortunately, in most cases, we're

3:24not going to be doing this, so let's not

3:25worry too much about it.

3:26Just have it in the back of your mind

3:28that that's technically an option in real world scenarios.

3:30For the sake of what we're going to be looking at, from a DC

3:33Core perspective, from a Cisco perspective,

3:35we're likely going to be talking about 50 bytes as the MTU

3:37increase that we need to add into our Layer 3 fabrics.

3:40Now one other thing worth mentioning

3:42is that fragmentation is not actually supported by VXLAN.

3:46Now what's interesting about this

3:47is that there's a Do Not Fragment bit that we

3:49can set in the IP header.

3:51And that's not actually configured with VXLAN,

3:53we leave that alone.

3:54So in theory, from a technical perspective,

3:57it can be fragmented.

3:58However, it's not supported, and it does result

4:00in some weird behavior if we forget to increase the MTU.

4:03Let's just increase the MTU and be done with it

4:05and not worry about fragmentation.

4:07Now when we consider the VTEP, we're

4:09going to divide it into two different types of interfaces.

4:11We have the IP interfaces, that face the Layer 3 network.

4:14And we have LAN interfaces that are

4:15going to face, well, the downstream LAN, the Layer 2

4:18domain.

4:19Now let's explore how VXLAN works from a data plane

4:21perspective.

4:22Let's say that we have this Layer 2 packet, or Layer 2

4:25frame, that's showing up on the VTEP.

4:27So we have this.

4:28We have a destination Mac address of,

4:30let's say Mac address B, over here hanging out on VLAN 10

4:33on the right side.

4:34So this switch is going to check its CAM

4:36table, just like it would always do from a Layer 2 perspective.

4:39It's going to look to see, hey, do I know where destination--

4:42I guess I didn't write this-- destination Mac address of B.

4:44So do I know where B lives.

4:46Now in a typical Layer 2 environment,

4:48B would probably be attached to an interface.

4:50However, in VXLAN, we have the possibility of attaching B

4:54to an IP address.

4:56And specifically, this would be the IP address

4:58of the VTEP on the other side.

5:00If that's the case, we're going to encapsulate that packet

5:03and send it across as a tunneled connection

5:05through that Layer 3 fabric.

5:07The VTEP on the other side is going

5:08to de-encapsulate it, check its own CAM table,

5:11realize that Mac address B lives out port, whatever that is,

5:141/1 we'll call it.

5:16So it just forwards that 1/1, and it makes it

5:18towards its destination.

5:19So that's it.

5:20From a data plane perspective, VXLAN

5:22is pretty straightforward.

5:23But now we need to have a conversation, right?

5:25Because how exactly did the VTEP on the left

5:28know where Mac address B lived?

5:30And there are a couple of different ways

5:32we are going to explore in this skill,

5:33starting with the Flood and Learn methodology

5:35in the next video.

5:36So as we see here VXLAN is going to use a MAC-in-IP/UDP

5:40encapsulation.

5:41That means that we've got the IP address, the source of the VTEP

5:44that's sending it, the destination on the other side.

5:46And then from a UDP perspective, we use port 4789.

5:50Next we got to consider MTU, always,

5:52with any tunneling mechanism.

5:54And with VXLAN, when we add it up,

5:55that IP header, the UDP header, the VXLAN header, and then

5:59that Ethernet header that we're encapsulating,

6:01we've got to take that into account as well.

6:03We add all those up, it comes out to 50 bytes

6:05that we need to increase our MTU in the Layer 3 fabric.

6:09And lastly, VTEPs are going to bring a packet in, realize,

6:12hey, in my CAM table I've got it destined for a VTEP,

6:15so I'm going to encapsulate that,

6:17send it across the Layer 3 network,

6:19and allow the VTEP on the other side

6:20to de-encapsulate it, and then from there,

6:22check its own CAM table to figure out what to do with it.

6:24I hope this has been informative for you

6:26and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:05As mentioned, VXLAN is primarily a data plane protocol.

0:08It's not an expert at figuring out

0:10where all of the Mac addresses live in the domain.

0:13But fortunately for us, there is a built

0:14in mechanism to handle this, in case

0:16we don't have a control plane protocol

0:18that we're deploying otherwise.

0:19So in this video, we're going to explore how exactly VXLAN

0:21leverages Flood and Learn, as its means of learning where all

0:24of those Mac addresses live.

0:26Let's dive in.

0:27So let's draw out an architecture here,

0:28let's do spine and leaf.

0:30And let's just assume that we've got one spine here,

0:32just for simplicity's sake.

0:34We'll draw four different switches.

0:35We've got connectivity to all four of those.

0:38Hopefully we'd never actually deploy a single spine

0:40architecture into a data center.

0:42And as we think about this concept of Flood and Learn,

0:44we should be thinking about another protocol, specifically

0:48Ethernet.

0:48Think about the way that Ethernet

0:50learns where Mac addresses are.

0:52We don't have a control plane protocol running,

0:54we're not running OSPF for Mac addresses, for example.

0:57Instead, when we have a switch and we receive a packet,

1:00and we do not know where the destination lives,

1:02what does the switch do with it?

1:04Well it floods it out.

1:05It floods it out by sending it out all of the interfaces

1:08that it has on it, other than the interface

1:10that it received it on.

1:11And by flooding it out, eventually, the theory

1:14is, that packet will land where it's supposed to land.

1:17And ideally that host will send something back to us,

1:20and when that packet arrives we're

1:22going to learn where exactly that hosts lives.

1:25So maybe it lived out this interface.

1:27And so next time we get a packet in, instead of flooding it out,

1:30we simply send it out the interface

1:32that now we know where it lives.

1:33So eventually we achieve sort of a steady state operation.

1:36I mean, certainly we're going to be learning new Mac addresses

1:39always, and we're going to be learning that Mac address move,

1:41and such.

1:42So we get as close to a steady state operation as possible,

1:46and we do it all without a control plane protocol.

1:49This is a Flood and Learn technology.

1:51And so we're going to do something very similar

1:53with VXLAN.

1:54However, with VXLAN we don't have the luxury of flooding out

1:57via a Layer 2 broadcast, because we have this Layer 3 network

2:00segmentation in place.

2:02And so we're going to need to come up

2:03with a new way of doing this.

2:04And so the way we're going to accomplish this is, yes,

2:07with multicast.

2:09Now multicast is going to create that flooding environment,

2:12that ability to send packets out and get them everywhere

2:15in the network, and it's going to do it

2:16as efficiently as possible.

2:18Let's dive right into an example.

2:20Let's say we have a VNI, a Virtual Network Identifier,

2:23that maps to VLAN 20, it doesn't matter

2:25what the VNI is in this case.

2:27And so what we're going to do is we're

2:29going to map a multicast address to it.

2:31Let's use 239.1.1.1.

2:35Furthermore, we're going to have a second VNI.

2:37Let's map this to VLAN 30, and we'll

2:39create a multicast address of 239.1.1.2 for this VNI.

2:44What we're going to do is we're going to form a multicast tree

2:47through the spine architecture.

2:49So let's say VLAN 20 exists on the first three switches,

2:53and VLAN 30 is going to exist on the last three switches.

2:55So we've got a little bit of an overlap here.

2:57We've got switches that support both VLANs 20 and 30,

3:00and we have switches that only support one or the other.

3:03What going to do is we're going to build a multicast tree

3:05through the spines.

3:07And so this multicast tree is going

3:08to be built according to each one

3:10of the addresses on the left.

3:11So what I just drew here is the multicast tree for VNI 20.

3:16And so now we can draw a new multicast

3:18tree that maps out to the VNI that maps to VLAN 30.

3:21The way multicast trees work is that when a packet arrives

3:24destined for the multicast address,

3:26in the green case of 239.1.1.1, it's

3:29going to forward it out all of the interested paths.

3:31Basically, we're going to forward it

3:33out the other branches on that tree.

3:35And so that gives us an avenue to flood traffic

3:38for that particular VNI.

3:40Let's see this in action.

3:41Let's say I have a host with a Mac address of A

3:44and it's attached to this switch here on the left.

3:46Meanwhile, we have a host on switch 3

3:49that's also attached to the same VNI,

3:51the same VLAN, the same broadcast domain, ultimately.

3:54And we'll call that Mac address B.

3:56Now we are sending a packet onto this network with a destination

4:00Mac address of B. And the switch here on the left,

4:03it doesn't know where B is.

4:06So what are we going to do with this frame?

4:08Well for all we know Mac address B might live out

4:10one of our own interfaces.

4:11And so we're going to flood it out all of the interfaces

4:14according to our typical Ethernet Layer 2 flooding

4:16rules.

4:17However, because VXLANs in play, we

4:19know that we have ports out all of these other switches that

4:22have connections to hosts that are in the same broadcast

4:25domain.

4:26And so we need to give them the opportunity

4:28to flood this packet out all of their interfaces as well.

4:31This is where we're going to send it

4:32via this multicast stream.

4:34We're going to send it up with a destination

4:36address of whatever our multicast address is,

4:39in this case 239.1.1.1.

4:41That tells the spine switch to send it down

4:44to all of the VTEPs in the environment that

4:46want to receive that particular traffic for that VNI.

4:49At this point, both of these other VTEPs

4:51are going to receive this traffic

4:52and flood it out all of their interfaces.

4:54So, yes, on some of these VTEPs it doesn't go anywhere.

4:58It just lands on the switch and it floods out

4:59all the interfaces, just like in a traditional Layer 2 network.

5:03However, over here on all right, we

5:05know that we are going to flood it out all of our interfaces,

5:07and one of these packets is actually going

5:09to arrive on the destination.

5:11Now the first thing that happens over here on the right

5:13is that our CAM table gets updated.

5:16Our CAM table now shows that Mac address A lives out VTEP,

5:20we'll just call that VTEP 1.

5:22Let's say we have 1, maybe it's a dot 1 interface.

5:25Dot 2, dot 3, and dot 4, on these four different leaf

5:29switches.

5:30So we'll say that it's actually attached to IP address dot one.

5:34So now this host decides to respond,

5:36which is usually what happens in a network stream,

5:38and so it's sending traffic with a destination of Mac address A.

5:42Well this switch knows where Mac address A lives,

5:45it lives out VTEP 1.

5:46And so it's not going to take advantage

5:48of the multicast streams, instead it's

5:50going to bundle that up and send it

5:52via unicast through the spine switch down to the VTEP

5:55on the left.

5:57The VTP will de-encapsulate it, and the first thing

5:59it's going to do, it's going to update its own CAM table.

6:02It's going to see that Mac address B now lives out VTEP--

6:05We'll just call it the IP address of dot 3.

6:08And then we send that Layer 2 frame down towards the host.

6:11So just like a traditional Ethernet environment,

6:13by flooding the traffic and learning it

6:16as the return traffic comes back,

6:18we are eventually going to achieve

6:19as close to a steady state operation as we can get.

6:22Again, learning new Mac addresses always,

6:24learning Mac addresses that move around,

6:27potentially, all of that's still going

6:28to happen in update, just as it would in a traditional Ethernet

6:31environment.

6:32However, one thing to be aware of

6:34is that we're going to have to continue to deal

6:36with what we call BUM traffic.

6:37That would be Broadcast Unknown Unicast and Multicast traffic.

6:41All three of these traffic types are

6:42going to continue to use the multicast tree.

6:44So if I have a broadcast packet that needs to go everywhere,

6:47well, guess what, I've got a multicast tree that's

6:49going to enable me to do that.

6:50That broadcast has to fit into one of these VNIs,

6:53because each VNI is a broadcast domain.

6:55And so I will use the appropriate multicast address

6:58to send that out.

6:59I'll receive the broadcast in, I'll

7:01forward it out all of my local interfaces,

7:03just like I normally would.

7:04And I will also send it up that multicast tree.

7:07The multicast tree will turn around and send it

7:09down to all of the appropriate VTEPs that

7:11need to then flood it out all of its associated interfaces.

7:14The same thing with unknown unicast.

7:16The only difference with multicast,

7:17is that our multicast streams might

7:19look a little bit different, because we only

7:21need to send to the VTEPs that have interested parties.

7:24So if we do nothing else and simply deploy VXLAN

7:26as it was built, then it has this control plane

7:29functionality built in, and we'll be just fine.

7:31However, we need to understand that we

7:33can add control plane functionality on top

7:36of VXLAN native operation.

7:38Now we have several different options for that.

7:40First of all, we do have a concept

7:42called Ingress Replication.

7:44Ingress Replication is when we have a unicast backplane.

7:47Ideally, this never happens, but in the event

7:50that we can't actually send multicast traffic

7:52across our spine switches, or whatever our Layer 3

7:54core is, we're going to have to use ingress replication.

7:57Which basically uses the same methodology,

8:00except it's going to require a lot of manually mapping VNIs

8:03to VTEPs, because we need to understand which VNIs live

8:07where, we can no longer automatically discover

8:08that via multicast.

8:10And furthermore, we're going to have

8:11to replicate a lot of this traffic, hence

8:13Ingress Replication.

8:14So if I need to send a packet to four different VTEPs, or 40

8:18different VTEPs, or 400 different VTEPs,

8:20I'm going to have to replicate that and send

8:22it unicast to every single VTEP that requires it.

8:25Now beyond this, we have an option

8:26that we're going to study in more depth in the next video,

8:29and that is known as BGP Ethernet VPN, or EVPN.

8:34This is going to proactively tell us

8:35where the Mac addresses are, and again, we're

8:37going to be covering that in more detail here shortly.

8:39On top of that, when we look at prepackage solutions,

8:41like Cisco SDA.

8:43Software Defined Access leverages VXLAN

8:45and it relies on LISP at the control plane

8:47to advertise where the Mac addresses are.

8:49And we have something similar with Cisco Application Centric

8:52Infrastructure, ACI, here in the data center,

8:54where we are leveraging a Cisco created

8:56protocol called the Council of Oracle's Protocol, or COOP.

8:59But fortunately, even though we seem

9:00to have a lot of different options

9:01available to us, including, by the way simply relying

9:04on Flooding and Learning.

9:05We are starting to see the industry converge around

9:08a standard, and that would be BGP EVPN.

9:11So as we summarize this, VXLAN lacks a native dedicated

9:15control plane.

9:15Instead, we're going to rely on Flood and Learn, very

9:17similar to how Ethernet functions.

9:20So the way we do this is that we're

9:21going to have to flood it out to all of the different VTEPs.

9:24But the difference between VXLAN and Ethernet,

9:26is that VXLAN we can't just flood it out

9:28from broadcast perspective, we have

9:30to get it across that Layer 3 boundary

9:31through the spine switches.

9:33And so what we're going to do is we're

9:34going to form these multicast trees

9:36and send our traffic across those multicast connections.

9:40Lastly, once we do learn where that destination is--

9:43the first part's the flood part, now we have the learn part.

9:46So fortunately, just like with Ethernet,

9:47when a packet comes back and we see, hey,

9:50that particular destination Mac address lives out

9:53a particular VTEP.

9:55Well now I can put that into my CAM table,

9:57and I can make sure that I send that via unicast,

10:00just to the VTEP that needs it, when a unicast packet next

10:03arrives.

10:04I hope this has been informative for you

10:05and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:05Now that we understand how exactly VXLAN operates

0:08outside of a control plane protocol,

0:10now let's introduce one.

0:11We're going to be talking about the Ethernet VPN,

0:13or EVPN technology, that's going to serve

0:16as a control plane for our VXLAN environment.

0:18Let's dive in and figure out how exactly this works.

0:21Ethernet VPN is going to rely on the Border Gateway

0:24Protocol, or BGP.

0:26Now what I like to say about BGP is that it's not actually

0:29a routing protocol.

0:30We think about OSPF, and EIGRP, and such,

0:33and those are true routing protocols,

0:34they can only carry one piece of information,

0:37and that would be an IP subnet.

0:39However, BGP is more of an information carrying protocol.

0:42We can use it to carry all kinds of things.

0:44And when we do, we call it Multiprotocol BGP, or MPBGP.

0:49Now when we think about Multiprotocol BGP,

0:51oftentimes we're thinking about IP version 6, and NPLS,

0:55and such.

0:56However, why couldn't we use BGP to carry

0:58Mac address information, along with Virtual Network

1:01Identifiers, and such.

1:02And that's exactly what we're going to do.

1:04We're going to leverage Multiprotocol BGP,

1:06carry this information, and we're

1:08going to call it the Ethernet VPN, otherwise known as EVPN.

1:12Well let's draw out a topology here, let's give ourselves,

1:15again, a single spine switch, just

1:16for simplicity of conversation sake,

1:18not that we'd ever deploy a single spine switch.

1:21Now what we're going to do is we're

1:22going to configure these devices for Multiprotocol BGP.

1:25We put BGP on all of the leaf devices,

1:29and we put BGP up here on the spine.

1:32Now specifically on the spine, we're

1:33going to make this a BGP route reflector.

1:36If you've studied BGP then you probably

1:38know what a route reflector is.

1:39If not, the gist of it is that BGP peers

1:43require a full mesh of connectivity

1:45in a normal environment.

1:46And so rather than form a full mesh of peers

1:50among all of these, we can use a route reflector

1:52in order to, more or less, turn it

1:54into what we'd expect with EIGRP or OSPF,

1:57or simply have direct relationships

1:58with the upstream device.

2:00Now I forgot to include my physical connectivity,

2:02so let me get that in there.

2:03So the way this works is we're going

2:05to abandon our Flood and Learn methodology.

2:07We no longer need it, because we're

2:08going to proactively advertise our connections to one another.

2:12And so let's say we've got a particular IP and Mac address

2:15combination hanging off of this VTEP,

2:17we know that it's attached to a particular VNI.

2:20And so now we can advertise that upstream to say,

2:23hey, I've got an IP address, I've got a Mac address,

2:25it's part of this VNI.

2:26And that route reflector is going

2:28to push that advertisement down to the other VTEPs.

2:31So when we consider the CAM table here on the right,

2:33we're going to have our Mac address that we just learned,

2:36and we're going to know which VTEP it's attached to.

2:39Maybe we have VTEPs 1, 2, and 3, labeled here again.

2:42So in our case, this Mac address is attached to VTEP 1.

2:45That means, right from the get go,

2:46if I get a packet in that's destined

2:48for that particular Mac address, well,

2:50I can unicast that over to VTEP 1 without having to flood it.

2:54That works great from a unicast tree perspective.

2:56And meanwhile, by the way, we continue

2:58to rely on multicast, or the BUM traffic that we talked about.

3:01So the Broadcast Unknown Unicast and Multicast, it still

3:04needs to get sent to multiple VTEPs at once,

3:06and so we're still going to rely on those multicast trees

3:09in order to make that happen.

3:10Now as if that's not good enough,

3:11we get a couple of other benefits by leveraging BGP.

3:14Specifically, we get a true sense of peering relationships.

3:17We're actually forming BGP peers with one another,

3:20which allows us to do things like authenticate

3:22those relationships.

3:23We no longer need to worry about rogue devices showing up

3:26in our VXLAN domain.

3:27Furthermore, we can take advantage of ARP suppression.

3:30If you're working your way through the DC Course,

3:32do you remember we talked about this concept with OTV?

3:35And the idea here is simply, if I get an ARP request,

3:38let's say I've got a device down here,

3:40it sends an ARP request for that IP address

3:42earlier that we talked about.

3:43Well that is a broadcast packet, and so

3:45normally I would take advantage of the multicast tree,

3:47I would forward that out to all of my VTEPs.

3:49But the reality is that I already

3:51know what the Mac address is for that IP address,

3:53because it was advertised to me via EVPN.

3:56And because I know that this IP address belongs to this Mac

3:59address, I can simply send down an ARP response

4:03without having to forward that into the rest of the network.

4:06ARP traffic is not an insignificant part

4:08of my data center busyness.

4:10And so just the fact that I can prevent flooding ARP requests

4:13throughout the entire domain, that's

4:14a pretty big benefit to deploying EVPN.

4:17So let's look at an example here.

4:19Let's say I'm attaching a brand new host to VTEP 2.

4:21It's got an IP address of A. It's got a Mac address, well,

4:25also of A. And we'll say it's part of VLAN 20.

4:29Now we know that VLAN 20 is going

4:30to get mapped to a particular VNI upstream,

4:33it doesn't particularly matter what that VNI is.

4:36Well soon as we send any kind of traffic into that VTEP,

4:39the VTP is going to learn several things.

4:41It's going to learn the IP address,

4:42it's going to learn the Mac address,

4:44it's going to learn its interface,

4:45it's going to understand, based on the interface,

4:47what VNI it's attached to.

4:48It's going to take all of that information,

4:50advertise it via BGP.

4:52That means that this information is

4:54going to get distributed to the other VTEPs in the environment.

4:57Now let's go and clean up this drawing here just

4:59to make this more clear.

5:00So now the other two VTEPs both know

5:02that Mac address A, and IP address A for that matter,

5:05belong to VTEP 2.

5:06So A belongs to 2 here on the left, A belongs to 2

5:09here on the right.

5:11And now when a packet arrives on the left here,

5:13let's say, and its destination is Mac address A,

5:16well I already know where that is, it's part of my CAM table.

5:19And so I don't need to flood it anymore.

5:21I can encapsulate that into a VXLAN.

5:23I can tunnel it through the spine switch,

5:25and it will arrive on the appropriate VTEP via unicast.

5:28Meanwhile also, if an ARP request comes in

5:31for that particular IP address.

5:33So an ARP request saying, hey, where

5:35is IP address A on the network.

5:38Well I can get that ARP response back directly from the VTEP.

5:41It doesn't have to get flooded into the rest of the network,

5:43instead I will get a response back instantly

5:45from the upstream VTEP, and the rest of the network

5:48never needed to hear about it.

5:49So that's a best of both worlds scenario.

5:52Now as we can see, EVPN is going to do us a large favor.

5:54It's going to leverage Multicast Protocol BGP, or MPBGP,

5:58to send, proactively, IP addresses,

6:01and Mac addresses, and VNIs, to the other VTEPs.

6:04What that allows is that it makes it

6:05so we don't have to use flooding behavior anymore

6:07to learn where everything is.

6:09Instead, for unicast at least, we no longer

6:11need to flood traffic, we can simply

6:13send it right where it needs to go because our upstream VTEP

6:16already knows where it goes.

6:17Now keep in mind that throughout all of this, the BUM traffic,

6:20the Broadcast Unknown Unicast and Multicast traffic,

6:22that's still going to rely on those multicast trees

6:25because we still need to deliver that to multiple VTEPs at once.

6:28However, these Multiprotocol BGP peerings

6:31bring with them some enhancements.

6:33Like for example, we can authenticate

6:34our peering relationships.

6:36And ARP suppression.

6:37ARP suppression is fantastic in a data center,

6:39it's just one set of broadcast traffic

6:43that we don't need to deal with anymore inside our data

6:45centers.

6:46I hope this has been informative for you

6:48and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:05We have reached the end of another skill, which

0:07means it's time to review what we've learned by taking a quiz.

0:09First up out of five questions.

0:11Describe the VXLAN header, breaking it down by bytes.

0:19Well the VXLAN header is 8 bytes in size,

0:21and so as we break that down, we have 1 byte that's

0:24dedicated to flags, and we have 3 bytes that

0:27are dedicated to the Virtual Network Identifier.

0:29That Virtual Network Identifier, remember, 3 bytes,

0:3224 bits, that gives us 16 million different network

0:35segments that we can use with VXLAN.

0:37And lastly, we have 4 bytes remaining.

0:39Those are reserved, we're not actually

0:40doing anything with them.

0:41So for now it's really just all about those first 4 bytes.

0:44If we can remember this and break it down this way,

0:46we can not only remember the size of the VXLAN header,

0:49but also the components.

0:51And as well, coming back to that MTU conversation later,

0:54we can remember what we need to do there.

0:56Next up.

0:57Where do the default gateways live in a leaf spine

0:59architecture?

1:05We touched on this briefly.

1:06Recall that we have spine switches,

1:08we have leaf switches.

1:09And one of the advantages to leaf Spine architectures,

1:12is that we can distribute the default gateway out

1:16to the individual leaf nodes.

1:17We can have the default gateway here,

1:19but we can also have the default gateway over here.

1:22This is known as an anycast gateway,

1:23meaning that we have the gateway located at multiple locations.

1:26It all has the exact same virtual IP address,

1:29but we're not running first hop redundancy protocols.

1:31The answer here is A, leaf switches.

1:34Question three.

1:35What MTU increase is required on the VXLAN underlay network?

1:43Well let's think back to that first question.

1:45We recall that the VXLAN header itself has 8 bytes,

1:48but we also know that VXLAN is embedded into IP and UDP.

1:53Now an IP header is 20 bytes and a UDP header is 8 bytes.

1:57However, that's not the end of the story.

1:58Because when we're encapsulating the entire layer

2:012 frame, well that layer 2 frame not only

2:04has the original packet, which, hey, that

2:05could be up to 1,500 bytes, but also has the Ethernet header.

2:09And when you take that Ethernet header into account.

2:11Now that Ethernet header by default is 14 bytes,

2:14and so we add up 20 plus 8 plus 8 plus 14,

2:17well that equals 50 bytes.

2:19So B is our answer.

2:20However, we might recall that there is that corner case

2:23scenario, where we could actually include the VLAN tag

2:25inside that Ethernet header.

2:27VXLAN does support that, and if we

2:28do decide to go that route for whatever reason,

2:31then we would need to account for the extra 4 bytes

2:33that the VLAN tag provides.

2:34However in most cases, we're going

2:36to be focused on that 50 byte header increase.

2:38So B, 50 bytes, that is our answer.

2:41Question four.

2:42How does VXLAN natively perform control plane operations?

2:50Well I had to hide the source, because the source gives it

2:52away.

2:53The answer is Flooding and Learning.

2:55Remember, VXLAN is focused on data plane operations,

2:58so we don't have a dedicated control plane

3:00protocol as part of VXLAN.

3:02Instead, we're going to have a control plane methodology,

3:04similar to Ethernet, where we're flooding traffic out

3:07to all of the VTEPs.

3:08And when we receive traffic back,

3:10that's when we are going to learn where

3:12Mac address actually lives.

3:13At that point, we update our CAM tables,

3:15and now we know where to send it via unicast next time we

3:18have a message for that host.

3:20Last question.

3:20It's an open ended one.

3:22What BGP configuration is added to the spine switches in a leaf

3:25spine EVPN architecture?

3:32We might recall that we have leaf switches,

3:35and then we have spine switches.

3:37And in BGP, we have to have a full mesh--

3:39Whoops, there we go--

3:40We have to have a full mesh of relationships.

3:42So if we have five different BGP nodes,

3:45then they all have to have relationship pairings

3:47with one another.

3:48Well, fortunately for us BGP gives us

3:49the option of route reflectors.

3:51So we can configure the spines to be route reflectors, which

3:54is our answer, and that allows us to only form

3:56relationships between the leaves and the spines directly.

3:59So it's important that we remember

4:00that BGP route reflectors are going

4:02to be part of our EVPN designs.

4:04Well that wraps up this quiz.

4:05If you find yourself running on empty

4:07for any of these questions, then be sure to go back

4:09and watch the appropriate videos in order to fully gas up.

4:12Otherwise, congratulations on completing Explain VXLAN

4:15and EVPN.

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

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