Understand VXLAN Concepts

0:01(upbeat jingle)

0:05<v ->So you as a data center professional,</v>

0:07or a candidate who's going

0:08for the JNCIP Data Center Certification Exam,

0:11you looked at the blueprint of this course outline

0:14or the JNCIP Data Center Exam blueprint,

0:17and you saw EVPN-VXLAN and you circled it,

0:20because you know, based on some experience,

0:23or word of mouth, or based on things

0:24that you've already seen here at CBT Nuggets,

0:27that really what makes a data center a data center,

0:30really the protocols that make it work

0:31the way that it does is EVPN-VXLAN.

0:35This is really the big topic,

0:36and this is really the reason

0:38why you go for this certification exam,

0:40and the reason why you study it here on CBT Nuggets.

0:43Well, here's the kicker.

0:44I'm gonna tell you right now

0:45that the reason you're really going here

0:47is because you want to answer these questions.

0:49What makes EVPN-VXLAN so special?

0:52Why is it dominant in the data center

0:55and not necessarily in other environments?

0:57How do you lay out an EVPN-VXLAN environment,

1:00and how do you actually configure it, deploy it,

1:02validate it, and troubleshoot it,

1:04and then have something really cool up and running?

1:07There's a lot of moving parts,

1:08a lot of components to EVPN-VXLAN.

1:11And to answer those questions,

1:12like "what makes it so great?"

1:14is really to answer a few questions.

1:16Why is VXLAN special?

1:18Why is EVPN special?

1:20And why is it that when they're combined together,

1:23they make something special for the data center?

1:25So what we really need to do is we need

1:27to break apart our big question into smaller questions,

1:29starting with what makes VXLAN so special.

1:33And that's what this set of videos is all about,

1:34really diving into VXLAN, understanding the key terms,

1:38how it functions, how it can be designed,

1:40and how it's evolved throughout the years.

1:43Now, in the next set of videos,

1:44we're gonna be focusing in on EVPN,

1:46and at that point you'll be able to bring it all together.

1:49We'll be able to talk about why the combination

1:51of EVPN-VXLAN is a special one for the data center

1:55before we actually jump on the CLI and get it configured.

1:58So for now, what we're going to do

1:59is we're gonna start talking about VXLAN,

2:01really introducing the point of VXLAN.

2:04What are the key terms?

2:05How does it really work?

2:06How can you design a layout, different layouts for VXLAN?

2:10And how has it evolved throughout the years?

2:12So get ready, because this is gonna be some big stuff,

2:13but it's so much fun.

2:15I'll see you there.

0:01(bright music)

0:05<v ->So, what is the point of VXLAN?</v>

0:07Why did we create it?

0:08What makes it so special?

0:10What problem does it solve?

0:12VXLAN at the end of the day is a layer 2 VPN,

0:16and you hear a lot about layer 2 VPNs

0:18when you go into the service provider space.

0:20But when you go into the service provider space,

0:22you don't hear a lot about VXLAN.

0:24Instead, you're hearing about things like MPLS

0:26or different forms of MPLS combinations with BGP.

0:30So in this video, what we're gonna do

0:31is we're gonna talk about how VXLAN really works,

0:33or at least at a very fundamental level,

0:35and understanding why VXLAN was created

0:38and what problems does it solve.

0:39So let's get going talking about the point of VXLAN.

0:42I'll see you there.

0:43So what is the point of VXLAN?

0:45To answer that question is really to answer the question,

0:48why did we need VXLAN in the first place,

0:50or what was the problem with our traditionally designed

0:53layer 2 enterprise and data center infrastructures?

0:56And we already answered that question actually,

0:58way back when, when we talked

1:00about the data center foundations

1:01and we introduced EVPN-VXLAN.

1:03But to refresh ourselves a little bit

1:05and make sure that we're on the same page

1:07as to why we need VXLAN,

1:09we need to reexamine this just a little bit.

1:12Now, the big thing here is when we deployed layer 2

1:15absolutely everywhere,

1:16so in this case, I would have things

1:18like 802.1Q trunk ports this way, this way,

1:21this way, this way, this way, this way,

1:23blah, blah, blah, blah, you get the idea.

1:24All of these are 802.1Q trunk ports.

1:26What do we know happens then?

1:28We have trunk ports or switches interconnecting to switches.

1:31We then have to have loop prevention mechanisms

1:34because of the very nature of how broadcast traffic works.

1:37And to do that, we run something

1:39like Spanning Tree Protocol.

1:40And in order to prevent these broadcast storms

1:43and these switching loops from occurring,

1:45we end up blocking links.

1:46We just stop traffic from ever making its way

1:49back into our switch by blocking

1:5250% roughly of the available links,

1:54or maybe more, maybe less depending on your environment,

1:57but roughly 50% of the available links

2:00in this particular topology such that this traffic

2:03could never actually return back.

2:05And that's fine up 'til a point.

2:08That's fine for an enterprise,

2:10that's fine for an access layer switch.

2:12But in the data center,

2:13we need extraordinarily high throughput

2:17for our very expensive, extraordinarily expensive

2:19data center switches and routers in order to actually handle

2:23extraordinarily powerful servers

2:26and the constant stream of requests

2:28and services that they're trying to provide

2:30back to our enterprise,

2:31or more importantly, back to our tenants.

2:34Since one of the revenue generating streams

2:36that many different public clouds or colocation systems is,

2:39is that they have a data center.

2:41Now they're just gonna lease out some of it to tenants

2:44so that they can come along, spin up their own services

2:47and leverage our already existing equipment

2:49and are already existing throughput and bandwidth

2:52and everything like that.

2:53So we can't afford to block half of our links

2:57or limit half of our topology,

2:59but we also can't afford to have switch loops

3:03because then nothing works, right?

3:04I mean, that's a huge problem

3:05because it just eats up our CPU

3:06until all of our devices are pegged out and then rebooting

3:09and trying to start over again.

3:11So what we ended up doing,

3:12as you can see here in the diagram,

3:14is we put /31 routed interfaces

3:18absolutely positively everywhere.

3:21So all of these devices,

3:22they no longer have broadcast domains

3:25that span from one switch to the next.

3:28That's kind of the idea,

3:29is if you wanna get off of this switch,

3:31you have to be routed off of your subnet.

3:34So that's actually a really cool thing,

3:36because when we deployed this,

3:37when we actually deploy this

3:38with things like IGPs, like OSPF or IS-IS,

3:42now by default we have loop-free topologies.

3:46IS-IS and OSPF are loop-free

3:48because of their link state databases

3:50and the nature of link state protocols.

3:52Link state protocols all agree

3:54on every single possible route in the topology.

3:58Therefore, they know how to get,

4:00they all agree on the fastest way

4:02to get from point A to point B.

4:03It's as if all of these switches have the exact same roadmap

4:08and we all agree based on traffic patterns

4:10that this is the fastest way to get there

4:12because we all have the same roads and the same paths.

4:15If, however, any of these devices

4:17didn't have the same roads,

4:19we could actually create a potential loop,

4:21but that's one of the protection mechanisms

4:23of link state protocols, is they're typically loop-free

4:26because they all have the exact same consistent database.

4:29And the second thing is,

4:31is because we all agree on the exact same paths

4:34and we know they're loop-free, if there is a potential

4:36to use more than one path to reach a destination,

4:40we can now do load balancing

4:41or what they call equal-cost multi-pathing.

4:45So we actually moved away from limiting our links

4:48and limiting our bandwidth

4:49towards actually load balancing across it.

4:51This was a huge step for us

4:53by moving into /31s and layer 3 absolutely everywhere.

4:57But the challenge then becomes in the data center

5:00is the fact that most traffic in a data center

5:03actually moves east to west,

5:05and the very technologies themselves

5:08are that we have servers that are very powerful

5:12that we now break down into little bitty mini servers

5:15in the forms of virtual machines.

5:17That's kind of the whole virtualization thing

5:19that you've probably heard of at this point,

5:21with ESXi and Hyper-V and some other device

5:25like Citrix XenServer and things like that.

5:27So now we in a data center, let me hide Knox for a second,

5:30We in a data center deploy servers absolutely everywhere,

5:34and then we deploy little virtual machines,

5:36or our tenants deploy little virtual machines.

5:39Here, let me draw a tenant's pink virtual machine over here.

5:42And this is all well and good because these servers

5:45can be in direct communication with each other.

5:48For instance, this server right here

5:51can communicate over layer 3 infrastructure

5:54down to this server and they can then say, like,

5:57"Hey, Mr. Web server over here,

5:59"that web server is actually a host

6:03"that is running four load balanced web VMs.

6:08"They're all servicing my website."

6:10And the problem that could happen here

6:12is that this web server could say,

6:13"Oh my goodness, my CPU percentage is at 95%,"

6:17or, "My RAM percentage is at 95%."

6:22We're really, really overutilized,

6:24while this server over here is just chilling

6:26with a CPU percentage of 5%

6:29and maybe a RAM percentage of 3%, just make something up.

6:34So this device says,

6:35"Hey, can I send you some of my workload?

6:38"Can I send you some of my VMs,

6:40"and then we could coordinate the load balancing

6:42"of these VMs between each other."

6:44And they say, "Sure."

6:45So, two of these VMs immediately migrate over here,

6:51and this is all well and good,

6:52except for these VMs were part of this subnet over here,

6:57and now they can't reach this subnet

7:00because our broadcast domain stops right here

7:03because we have a layer 3 domain in the core.

7:06If this VM right here has the IP address,

7:101921681.5,

7:14and this VM over here has 1921681.7,

7:20how do they communicate directly to each other?

7:22Well, since they're on the same subnet,

7:24they would be trying to generate frames, right?

7:26They would be trying to generate frames

7:27and communicate on layer 2.

7:29But when the frame comes into this switch,

7:31what then happens?

7:32It can't be sent over a trunk port over here

7:35the way you would normally expect.

7:37It doesn't communicate over the same VLAN

7:39because we have layer 3 all throughout the course

7:42separating our broadcast domain,

7:44and this is the challenge that we have

7:46when we introduce /31s everywhere.

7:49In a data center, these VMs are moving left to right

7:53absolutely all the time in rapid-fire secession.

7:56These host machines, these big servers,

7:59are constantly in communication trying to figure out

8:01how can we balance our load out

8:03so that we're not overutilized and cooking our hardware

8:06or anything like that.

8:07So these VMs are migrating back and forth all the time,

8:11but they need to maintain connectivity

8:13within their own subnet,

8:15within their own virtual networks.

8:17So the need became that we needed to get this device

8:20at 192168.15's frames over here onto this device

8:26so that they can communicate directly to each other.

8:28Enter VXLAN to the rescue.

8:30VXLAN is all about creating a tunnel, a logical tunnel

8:36from point A to point B.

8:39The whole idea is that the frame

8:41could make its way into the local switch,

8:43and the switch would say, "Oh, you know what?

8:46"This frame is destined for a VM over here

8:50"off of that switch, so what I'm gonna do

8:53"is I'm gonna take this original frame,

8:55"I'm gonna box it in like this, and I'm gonna sandwich it

8:58"inside of my own layer 3 packet

9:02"destined for this tunnel endpoint."

9:05So the packet will be routed through the spine,

9:09over here down to the switch,

9:11and that switch will know to de-encapsulate it

9:13by stripping off the layer 3 header,

9:15and then it receives a frame that it can punt

9:17right down here to the server.

9:19Now, how does this actually work?

9:21There's a lot more to it than just that,

9:24and that's what this set of videos

9:25and the next set of videos is really all about.

9:28Right now we're just trying to conceptually understand

9:31what the point of VXLAN is and why we need it.

9:35The real thing that you should take away from this video

9:37is that we have broadcast domains

9:40for all of our virtual machines on these servers,

9:43but these broadcast domains are broken up by a layer 3 core.

9:47This is what we're end up going to end up calling

9:49the underlay or the underlay portion of our fabric.

9:53And we need to get these frames over our underlay

9:57in such a way that the frame can be carried

10:00over to the remote destination,

10:02and then sent out towards the broadcast domain

10:05that it needs to belong in.

10:06And it does this by just tunneling a frame

10:09inside of an IP packet.

10:11It's actually kind of a straightforward concept

10:13when you really think about it.

10:14It makes a lot of sense.

10:15It's no different from how we tunnel a layer 3 packet

10:18inside of a layer 3 packet

10:20when we deploy a site-to-site VPN, right?

10:23We're just ascending our inside IP packet

10:26that's inside of our network over the public internet.

10:30The internet is just routing the outer IP packet,

10:32and that's kind of the same thing we're doing here.

10:34Our core is just routing our outer IP packet

10:37until it reaches the tunnel endpoint,

10:39which knows to strip it off,

10:41and it's being left with a frame

10:43that it can forward down directly towards its host.

10:45Now, like I said, there's more to it than that,

10:48but it's just understanding the concept,

10:50and that's really what matters right now,

10:51is that we are just going to be tunneling traffic

10:54throughout a broadcast domain over a layer 3 core.

10:58That is the point of VXLAN.

11:00Now, in the next video, we're gonna examine

11:02why aren't we also talking about EVPN,

11:04since the whole point of the data center topology

11:07is EVPN-VXLAN, right?

11:08So that's what we're gonna talk about next.

11:10In the meantime, I hope this has been informative for you,

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

0:00[MUSIC PLAYING]

0:06Wait a minute, Knox.

0:07I came here to learn about EVPN VXLAN,

0:09why aren't we talking about EVPN VXLAN?

0:12Why aren't we talking about EVPN?

0:14In this video, we're going to do is fundamentally

0:16break our mind apart for a second, divorce ourselves

0:20from the concept of EVPN and VXLAN.

0:22And reconsider the fact that EVPN and VXLAN

0:25are two completely separate protocols that just so happen

0:29to be able to work together.

0:30So let's take a moment to actually examine

0:32what it means to break apart the data plane from the control

0:35plane in this video.

0:36I'll see you there.

0:37So to me personally, this is honestly

0:39a big topic to kind of wrap your head around.

0:42Because lots of times, up at least until this point,

0:45throughout your associate journey, your specialist

0:47journey, you deploy a protocol, and it just works.

0:50But the interesting thing about VXLAN

0:52is it, more than likely, will not work on just its own.

0:57It's going to need some help getting a frame from point A

1:00to point B.

1:01And what we're really talking about here

1:03is the fact that this solution of EVPN VXLAN

1:07is actually two completely separated protocols.

1:10Two completely separated solutions that just so

1:13happen to be able to interact with each other.

1:16Think about it another way.

1:17Remember in the previous example,

1:18let me kind of clear up my screen.

1:20Let me clear Knox here for a second.

1:21If I brought this server down here and we migrated a VM,

1:25right?

1:26How did this switch, right here, know

1:30that it needs to build a tunnel over here to this switch?

1:34And how did it know that when a frame comes

1:37in from this VM destined to this VM-- or I should say this VM,

1:42how did it know that it should go over the tunnel?

1:46This is kind of the tricky part is that VXLAN by itself

1:49is not designed to do that.

1:51It's not designed to know this.

1:53It relies on EVPN in order to figure that out.

1:57And I've kind of mentioned this already a few times,

1:59I'm going to mention it again.

2:00EVPN is nothing more than iBGP, that's really it.

2:04It's just iBGP.

2:06I know it seems scary because it's got E and a VPN,

2:09and you're like, oh, it's going to be like some mega-layer VPN.

2:11No, it's just iBGP.

2:13Instead of carrying layer 3 prefixes,

2:16it's carrying MAC addresses.

2:18And this is really how it's going to work.

2:20If I were to give you a crash course on EVPN, when

2:24this VM sends in its frame for the first time into the switch,

2:29this switch does exactly what all switches do.

2:32How does a switch make a forwarding decision?

2:34How does a switch actually decide

2:37where frames should be sent?

2:39When frames come into a device, the first thing a switch does

2:43is it learns the source MAC address.

2:46In this case, this switch is going

2:48to say, OK, I've just learned this VM's

2:50MAC address on this interface.

2:52So whenever I receive return traffic, or traffic destined

2:56to that MAC address, I know to point it out this interface.

2:59Now, the next thing it does is it

3:01says OK, do I know where the destination MAC address go?

3:05And if it doesn't know it, it floods it

3:07out all the interfaces in the same VLAN,

3:09except the one that turned it on, right?

3:10We know this, or it sends it out the trunk boards

3:12until it gets to the destination and we learn about a response

3:16traffic, right?

3:17That's how this switch normally works.

3:19Well this is similar.

3:20This is similar.

3:21At the point when we've got EVPN up and running, remember,

3:24we really just have iBGP up and running.

3:27So we form iBGP neighbor relationships

3:31to all of our peers.

3:32And, when we learn about a VM's MAC address, what do?

3:36We do we advertise it to all of our iBGP peers.

3:41We say, hey, I've got this MAC address.

3:44You can reach this MAC address off of me.

3:47Route a packet to me.

3:49So the alternative is when this virtual machine over here

3:52on the left sends its frame up to this switch,

3:55it learns about the MAC address and then advertises it back

3:59over here.

4:00Now, MAC address to MAC address communication

4:03is now facilitated.

4:05Unicast MAC address communication

4:07is now facilitated.

4:08Because both of these devices have-- both of these switches

4:11have learned they're locally connected MAC addresses

4:14and then advertised them towards each other.

4:17So now we can tunnel these MAC addresses over here.

4:20When we receive a frame destined for the MAC address over here

4:24in the bottom left corner, we know

4:26that we need to tunnel it to this switch, who advertised it

4:29to me in the first place.

4:31OK, this all makes sense.

4:33We understand how the MAC addresses are now learned.

4:37But the big thing to understand is

4:39there are actually many different ways

4:42that you could go about learning these different types

4:44of technology.

4:45EVPN is just one control plane that can be used by VXLAN.

4:51LISP is another control plane that can be used by VXLAN.

4:55PIM is another control plane that can be used by VXLAN.

4:59Do you see where I'm going with this?

5:01We don't have to use EVPN.

5:04We just choose to use EVPN in the data center.

5:07Now why?

5:08We're going to talk about that when it comes time

5:10to actually talk about EVPN.

5:12For now, you need to understand the concept

5:14that VXLAN is its own protocol.

5:17It's its own data plane.

5:19It can handle figuring out how to build tunnels

5:22from one endpoint to the next endpoint

5:25and sending frames over those tunnels.

5:27But it can't actually learn MAC addresses.

5:30It's not about advertising and learning MAC addresses at all.

5:34It relies on, OK, hey EVPN, did you

5:37learn where I should send this MAC address?

5:39Oh, you did?

5:40OK, thanks for that.

5:42I'll go ahead and handle sending it from here.

5:44VXLAN is just 50% of the equation.

5:48It's just a data plane.

5:49And like I say, it is a solution that is primarily

5:53used in data centers.

5:55It is not primarily used in service providers

5:57who, often, are trying to figure out the exact same thing.

6:01How do we deploy a Layer 2 VPN?

6:03How do we tunnel frames across our backbone?

6:06They end up using MPLS instead of VXLAN.

6:10Why?

6:11Because not all of their traffic is east to west.

6:14They require using protocols like RSVP

6:18to perform very specific traffic engineering calculations when

6:23it comes to things like bandwidth reservations.

6:25I mean, think about a service provider at the end of the day,

6:27what do they sell?

6:28They sell bandwidth.

6:29I mean, you go in your home, what did you do?

6:31You bought a connection to a service provider.

6:33But specifically, you bought a connection

6:35with a certain speed, right?

6:36100 megs up or 10 megs up, 100 megs down,

6:39or synchronous fiber, or whatever you did.

6:41You bought it.

6:42And you were guaranteed a bandwidth reservation.

6:44That's kind of the idea here, is with MPLS,

6:47service providers have the ability

6:49to actually perform traffic engineering, such

6:51that when they promise a customer they're

6:53going to get this much bandwidth,

6:55they can use MPLS to actually reserve that bandwidth

6:58throughout the path.

6:59So that way, they can actually deploy a Layer 2 VPN,

7:02like EVPN MPLS and say, OK, you're

7:05going to get this much bandwidth when you go from this site

7:08to that site.

7:09So this is why they went with MPLS instead of VXLAN.

7:13Now we went with VXLAN because it's so

7:16stinking fast and scalable for east to west traffic.

7:20And it responds very quickly when it's coupled with EVPN.

7:23So this is the big thing right now

7:24that you got to wrap your head around,

7:26is we're only focused on the data plane right now.

7:28But at least you got an idea as to how

7:31it's going to know how to make forwarding decisions before we

7:33actually dig deep into how EVPN operate.

7:36So this is separating the control and the data plane.

7:39I hope this has been informative for you.

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

0:01(cheerful music)

0:07<v ->Now, one of the cool things about VXLAN is</v>

0:08there's really not many new key terms to bring

0:11to the table when it's time to learn VXLAN.

0:13There's really only a couple,

0:15but they're important key terms.

0:17And they really introduce the concepts

0:19and technologies about how VXLAN works.

0:22So while this video is focused on introducing you

0:25to the key terms like a VNI and a VTEP,

0:28what we're really talking about here is,

0:29how does a VNI work and how does a VTEP work?

0:33So in this video, that's exactly what we're going to cover.

0:36What is a VNI and a VTEP and how do they really work

0:39in order to bring VXLAN to life?

0:41Let's see.

0:41Let's get going.

0:42All right, usually when I say like, let's just learn

0:44some terms and some definitions, my eyes kind of roll

0:47because that's gonna be boring content.

0:49It's reminds me of like English class when you had

0:51index cards that were just words and definitions.

0:54That's not gonna be the case in this video.

0:56When we introduce key terms with VXLAN,

0:59this is really digging into how VXLAN works

1:02and one of the biggest selling points

1:04for why you want to go with VXLAN.

1:06The other cool part is there's really not

1:08many key terms to VXLAN.

1:09Let's talk about the first one.

1:11When we have these devices, these switches here,

1:13my leaf switches, and they wanna build tunnels

1:16to each other, the big thing that we call this,

1:20we call these switches now VTEPs.

1:23VTEPs stands for Virtual Tunnel Endpoint.

1:27Pretty straightforward.

1:28It makes a whole lot of sense.

1:29This is where a tunnel starts and stops.

1:33It's an endpoint for where tunnel can be

1:36a accumulator or where they can go.

1:38And we end up forming VTEPs, or I should say tunnels

1:42to every single one of my potential partners here.

1:46So it kind of becomes a full mesh

1:49of tunnels between my VTEPs.

1:52The other interesting part is VTEP neighbor ships,

1:56VTEP tunnels are always done based on loop back addresses.

2:00This actually has a pretty big design implementation

2:03or consideration when it comes time to

2:05implement VTEPs and VXLAN in your environment

2:08because now we have to know how to get from one

2:11loop back address to the next in the most optimal manner.

2:14Of course, we also have equal-cost multi-pathing in the mix.

2:17Did you notice this about the actual spine leaf

2:20design itself, is that spines never actually connect

2:24to spines and leaves never actually connect to leaves?

2:26But the other interesting thing is,

2:29is that every leaf connects to every spine

2:31and every spine connects to every leaf.

2:33Therefore, destinations are always only two hops away.

2:39So I can go one hop here, then down here.

2:42I can go one hop here, then down here.

2:44I can go one hop here, then back over here.

2:47Destinations are always two hops away

2:49in a spine leaf environment.

2:50So therefore, no matter how our tunnels end up laying out,

2:53we can get a frame from one end of our data center all the

2:58way to the other end of our data center in exactly two hops.

3:02And that's a big design consideration.

3:04So really the big thing that you need to know,

3:06first of all, is that when we talk about these switches,

3:09we actually refer to them as VTEPs.

3:12This is where the switch is going to be a tunnel endpoint.

3:15And all of our VTEPs typically form a full mesh

3:19as long as they need to, as long as they need to

3:22tunnel traffic towards each other.

3:24Now, how do they know when they need to?

3:27This comes up into the next big talking point,

3:29and that is VNI, Virtual Networks

3:33and Virtual Network Identifiers.

3:36Pretend for a moment that we

3:37have this blue client right here.

3:39We are a public cloud.

3:40And we now have someone who's come along,

3:42they've given us their credit card and they wanna

3:44start spinning up resources in their environment.

3:47So they spin up a couple VMs.

3:49What is a big thing that those VMs do?

3:51They communicate on a network.

3:52And they want to be able to declare that they wanna use

3:56VLAN 10 as their network to communicate on.

4:00Well, no big deal so far.

4:02Except, maybe there is a big deal.

4:04What happens now when a pink client comes along

4:08and they spin up VMs and they want to use VLAN 10?

4:13Well, by default you would think that they actually couldn't

4:15because then they would have overlapping broadcast domains.

4:18For instance, if I had a VM here and a blue VM here,

4:23and we build our tunnel like so,

4:26so far so good.

4:28As this VM goes to communicate over the tunnel,

4:31it'll get de-encapsulated and the device will go,

4:34oh, VLAN 10, but wait a minute, it's got two VLAN 10's.

4:36So that doesn't really work well, does it?

4:39So you would then think, okay, well then we're limited

4:43to the amount of VLANs that we have.

4:45We can never have overlapping VLANs, right.

4:47Well, the other big problem with that is

4:49that there are only 4,094 usable VLANs

4:53because VLANs are a 12 bit number.

4:56So now effectively what I'm saying is the maximum amount

5:00of customers we could have then is 4,094 customers.

5:03Would that work for AWS?

5:04Would that work for Azure? No.

5:07And these customers would only have to want one VLAN.

5:10That doesn't work that way.

5:11The cool thing that VXLAN brings to the table,

5:15they use a 24 bit identifier

5:18to identify their customer's VLANs.

5:21This is probably one of the cooler things.

5:23So we can say for customer pink, use a VNI

5:28or a VLAN identifier, a Virtual Network Identifier

5:31of something like 65,322, make something up.

5:36And we say, blue customers VLAN 10

5:39is directly mapped to this VNI.

5:42And then for our pink customer, we could say,

5:44use a VNI of something like 131,013, make something up.

5:49And we say, pink customers VLAN 10 gets mapped to this VNI.

5:54So when we advertise our Mac addresses, we also say,

5:59hey, I learned this Mac address on this VNI.

6:02So now when the frame goes over the tunnel,

6:06this VTEP can receive the frame encapsulated

6:10with a packet that also identifies the virtual network

6:13that it belongs to, like 131,013.

6:17And this device can go, oh, 131,013,

6:20that's specifically associated with my pink client.

6:24Therefore, I'll de-encapsulate the frame

6:27and send it out towards the interfaces

6:30that face my pink client.

6:32So this is the huge, huge win about VXLAN,

6:35is the fact that it can now support millions

6:38upon millions of virtual networks.

6:41And that means our customers can now have

6:43overlapping VLANs because we can use the VNI

6:47to uniquely identify our customers VLAN.

6:50And that way we can send the traffic layer three

6:53throughout the entire topology.

6:54And we just say, this is specifically associated,

6:56this frame it's specifically associated with this VNI.

7:00So when you receive this frame, send it out

7:02towards all of the devices that are connected

7:04towards this VNI in that VLAN.

7:06Now, I do wanna specify that it is usually

7:09or sometimes manually mapping this VLAN to a specific VNI.

7:14But there are ways that you can automate that process too.

7:16There are discovery and advertisement methods

7:20that you should know exists.

7:21And that way when you get into the expert level tier,

7:23those are the things that you'll need to know.

7:25But when it comes time to configure it,

7:26we're just gonna do a basic manual mapping of a VLAN

7:29to a VNI and you'll be kind of surprised at how easy it is.

7:32So this has been introducing the two key terms

7:35for VXLAN, VTEPs and VNIs.

7:38I hope this has been informative for you.

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

0:06Now, the temptation is to say that VXLAN

0:08comes in many different shapes and sizes.

0:10But in a data center, it only comes in two shapes and sizes.

0:14The options that we have when a data center is deploying

0:17EVPN-VXLAN are really down to spine-leaf architectures

0:21or spine-only architectures.

0:22So that's what we're going to cover in this video is

0:25what are the differences between these two

0:26and when would you actually use them.

0:28Here's the spoiler.

0:29You're pretty much almost always going

0:31to use spine-leaf architecture.

0:32Spine-only really comes in for a transitional period when you're

0:36moving towards EVPN-VXLAN.

0:38So what are the businesses that actually use this

0:41and what are the use cases and how is it actually laid out?

0:43That's what we're talking about in this video.

0:45Let's get going.

0:46Now, when we talk about VXLAN, especially EVPN-VXLAN,

0:50in the data center, we are almost exclusively

0:53talking about deploying it in the spine-leaf model.

0:56But you need to know that there are a couple different styles

0:59of EVPN VXLAN that can actually be deployed,

1:04and that's spine-leaf or spine-only EVPN-VXLAN.

1:10And this actually has a very large implication

1:13about the flavors and behaviors of EVPN itself.

1:18Now, this won't make a whole lot of sense yet.

1:21You have to actually dive deep into EVPN

1:24to understand the impacts that it has.

1:26But I wanted to set this up now.

1:28I wanted to set this up now because this

1:30is, at the end of the day, a deployment designed for VXLAN.

1:34So let's start off by talking about EVPN-VXLAN in spine-leaf.

1:39We understand some of the moving components now.

1:41We understand VTEPs and VNIs.

1:43And when this traffic comes in, we have slash 31s absolutely

1:48everywhere throughout our core.

1:50So we're going to be routing traffic

1:52as it moves over a tunnel.

1:55Here, let me draw a little tunnel here.

1:57Over a tunnel, let's say this tunnel right here.

2:00So as a frame comes in, we'll encapsulate it in the packet,

2:04and it'll be routed up into a spine and then

2:07back down towards one of the other leaves.

2:09That's another VTEP.

2:10So in the spine-leaf deployment, the VTEPs

2:14exist on the leaf tier.

2:17This is the big thing.

2:17And the spines really do nothing more than facilitating very

2:22fast routing between the leaves.

2:24And the traffic still moves, primarily east to west.

2:28That's the idea here is that really

2:30the brains of the operation are actually the leaves themselves.

2:34We also remember this is where external networks connect in,

2:37and this is also where like the internet will connect in.

2:39It'll all connect in on the leaf tier,

2:42and these routes will all be propagated this way.

2:44Now, the actual deployment of the underlay and the overlay,

2:47we're not there yet.

2:48But just know right now in the spine leaf deployment,

2:50this is the gist of it here is that our VTEP

2:53and our routing decisions themselves

2:55and how we tunnel traffic, that all occurs on the leaf layer.

2:59But for traditional enterprises and traditional data centers

3:04that are currently running layer 2 everywhere,

3:06what are you going to do if you want to deploy EVPN-VXLAN?

3:10Are you literally going to just take a weekend

3:12and log in to all of your devices

3:15and deploy layer 3 absolutely everywhere?

3:18If you're a large enterprise or a medium to large data center,

3:21there's absolutely no feasible way.

3:23What you would have to do is you would

3:25have to transition into EVPN-VXLAN by first deploying

3:30EVPN-VXLAN on your spines.

3:32So instead of having slash 31 everywhere, mark that out.

3:36You're still going to have 802.1q trunks all the way up

3:41to your spines.

3:42But then this is where things get wild.

3:44You're spines are now going to be the VTEPs.

3:48And we will now interconnect our spines

3:51so that the tunnel looks like this.

3:54The tunnels now exist between the spines.

3:57And of course, you're going to have more than two spines.

3:59You're going to have multiple spines like so,

4:01and they'll tunnel each other like this.

4:03And they'll be the ones who will share, OK, well,

4:06I've just learned about this MAC address off of this link.

4:09So if you want to reach this MAC address, you can reach me here.

4:13And if they want to tunnel the traffic through the VTEPs,

4:16they'll be able to do it this way.

4:18That way you'll now start propagating

4:20the learning of MAC addresses throughout EVPN-VXLAN

4:24environment even though you're going

4:26to be trunking this traffic up towards the spines.

4:28Now you're thinking to yourself, wait a minute.

4:30802.1q, that means spanning tree protocol.

4:33That's correct.

4:34That's why our spines now are deployed

4:38with multi-chassis link aggregations

4:41down to the actual leaves themselves.

4:44And that deployment itself, right there

4:47deploying an MC lag between a spine and a leaf, in EVPN

4:52is a massive, massive, massive consideration.

4:57And when we get into EVPN-VXLAN, you'll

4:59understand why we typically don't do spine-only deployments

5:04in a data center.

5:05Now, this design model right here--

5:07I want to stress this--

5:08where you have multihoming, that's

5:10really what this is called.

5:11This switch is now multi-homed to EVPN-VXLAN.

5:15It now has a link up here as well as a link up here.

5:18It sees this as one LACP link.

5:20We know this because we know MC lag.

5:22This device is now multihome.

5:24This really actually comes up in the service provider world.

5:28Because they'll have customer equipment,

5:30like a customer switch, that is now

5:32multi-homed to our two provider equipments

5:35to provide redundancy.

5:36So you deploy MC lag this way.

5:39And then when they want to have a layer 2 VPN

5:42and they send frames in, then this

5:44becomes an EVPN consideration.

5:46And that's really where you see this in the EVPN world,

5:49and we're going to talk a lot more about this.

5:51But you should know that in the EVPN-VXLAN deployment,

5:55doing spine only is going to have a major implication as we

5:59deploy MC lag between spines and leads.

6:03But for the most part, we deploy spine-leaf because it just

6:07keeps things nice and clean with layer 3 everywhere

6:10and our VTEP, instead of being at the spine layer,

6:12they're deployed at the leaf layer.

6:15So this is understanding the two different deployment

6:17models for EVPN-VXLAN in a data center.

6:20You've got spine-leaf, which is almost

6:22deployed like 95% of the time, and spine-only

6:26which is primarily used as a transition towards spine-leaf

6:29to start edging away from layer 2 links absolutely everywhere.

6:33So that's been understanding the two design models.

6:35I hope this has been informative for you,

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

0:01(soft music)

0:06<v ->So quite frankly, if I'm being honest,</v>

0:08there's not a whole lot to actually inspecting a VXLAN frame

0:12as it's being traversed across a Layer 3 infrastructure.

0:15If we were to inspect the actual encapsulated frame,

0:18and look at what's going on, it looks kind

0:20of exactly like what you would expect.

0:22However, you do have to consider

0:23how much overhead is eaten up when we actually use

0:26EVPN and VXLAN.

0:28So in this video, what we're gonna do is we're gonna

0:30decipher the VXLAN packet just a little bit more.

0:33I'll see you there.

0:34Now, I challenge anyone to find a better source

0:37of information on a protocol than the RFC itself.

0:41This is one of the best ways that we can actually inspect

0:43what is actually carried in a VXLAN header

0:46and how much overhead is it really eating up.

0:49And if I jump down into section 5 of RFC 7348,

0:54let me actually zoom in a little bit here.

0:56That way we can see big text.

0:57Let me see, make sure I'm not in the way, okay, cool.

0:59So we've zoomed in quite a bit.

1:00Let me zip down.

1:01Okay, look, right here, the VXLAN header

1:05that we're adding into the mix is an 8-byte field,

1:08that is 64 bits that we've tacked

1:12on for the VXLAN header.

1:14Recall for a second that

1:15what are we really talking about though?

1:16We have our original payload, our original frame.

1:19If we think about the way a frame looks,

1:21we've got a source MAC, a destination MAC,

1:24and then we have a source IP and a destination IP,

1:30that's the Layer 3 portion.

1:31We have a source port and a destination port,

1:34and then we have the payload, right?

1:36The data that comes after that.

1:37Well, we're taking this,

1:38and we're sandwiching it inside of another packet.

1:43So what we're doing is right here,

1:45we're shoving in a VXLAN specific header

1:49to be used by VTEPs.

1:51Then we have our source and destination ports.

1:56The destination port for VXLAN is a well-known UDP port.

2:00That is UDP port 4789, that's how I remember it,

2:05I just like "7, 8, 9".

2:06It's just easy to remember that way.

2:07So we've got a source port that's generated by a device,

2:10and then a destination port for UDP 4789.

2:13Then we've got our Layer 3 header

2:15for the routing throughout the core.

2:16And then the next hop MAC addresses,

2:19we've got the Layer 2 header,

2:20you get the idea here.

2:21So we've taken our original device,

2:23we've shoved in 64 bits potentially for the VXLAN header,

2:28then taken up that additional space for the ports,

2:32the IP addresses,

2:33and the MAC addresses to be used

2:35to move this traffic throughout the core.

2:37So this is already some interesting things

2:40to really consider, but let's inspect the VXLAN header

2:42a little bit closer.

2:44I'm gonna actually zip down to the diagram,

2:46instead of just reading that boring info to you,

2:48and we'll jump down to the VXLAN header.

2:50Well, what do you see here?

2:51We see a bunch of "reserves", and then a "reserved"

2:55and then dead smack in the center, the VNI.

2:58Ah, now it makes a whole lot of sense.

3:00When we send traffic

3:02to destination port 4789, we then say,

3:08oh wait, the device that received it says,

3:09"Wait a minute, this is coming in on UDP 4789."

3:12"Therefore, it must be VXLAN traffic,"

3:14"because that's the application specific port."

3:16"Let me see, before I de-encapsulate this,"

3:19"which virtual network,"

3:20"therefore, which of my customer's VLANs"

3:23"is this really associated with?"

3:24So it looks in the VNI,

3:26and then says, "Ah, I know, this is for, you know,"

3:30"my Pink customer's VLAN 10."

3:32"Let me strip off all of that unnecessary information"

3:34"and boom, what am I left with?"

3:37The original payload, the original frame

3:40that exists right there.

3:41So we see the original inner ethernet header.

3:44There could be some additional info,

3:46like we see we could keep VLAN tag information

3:48if we wanted to keep

3:49that VLAN tag information.

3:50And then the actual payload, the actual payload itself,

3:54followed by lastly, a frame check sequence.

3:56So inspecting this actual, this actual payload,

3:59what changes with the VXLAN header,

4:02and how does it actually transmit throughout the topology?

4:05I think is really important.

4:06So for recapping it from the top,

4:08we've got our outer ethernet header.

4:09This is going to be, if we understand the OSI model,

4:12and how traffic moves throughout the network.

4:14The outer ethernet header is my next hop MAC address, right?

4:17That's my destination next hop MAC address

4:19that's gonna be as it traverses through the core.

4:21Then I scroll down, we've got the outer IPv4 address.

4:25This is really gonna be the destination IP address

4:27of the VTEP device.

4:29Then the outer UDP header.

4:30This is the VXLAN destination of UDP 4789,

4:34the VXLAN header, really that's the VNI,

4:37so we know what network it goes to.

4:38And then, the original inner ethernet header

4:41and the payload itself.

4:42So now we've deciphered the VXLAN packet,

4:45and we actually know how traffic moves

4:47throughout the topology,

4:48and how it's received by a VTEP.

4:50And it knows how to de-encapsulate it,

4:53and which interfaces and which broadcast domains

4:56it needs to send the original frame out of.

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

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

0:00(bright music)

0:06<v ->One of the interesting things that's easy to overlook</v>

0:08is when you focus in on VXLAN,

0:10what are you really focused in on?

0:12You're focused in on taking a frame

0:14and moving it across an infrastructure

0:17so that it can communicate

0:18in the exact same broadcast domain

0:20no matter where these devices live within our data center.

0:23But what happens when they don't want to communicate

0:26within the broadcast domain?

0:28I mean, these VMs, they spin up,

0:29they have a default gateway, right?

0:31And they wanna be routed out to the internet sometimes.

0:33How then do we handle this scenario

0:36when we've deployed EVPN-VXLAN?

0:38How do we actually handle routing when the devices

0:41are configured to actually tunnel frames?

0:44That's what this video is all about,

0:45understanding our layer 2 and our layer 3 gateways

0:48in the various designs that can be deployed

0:50of EVPN-VXLAN.

0:52Let's get going.

0:53Now, here's an interesting one that you, like I say,

0:55may have been easily overlooked

0:57when we're talking about VXLAN,

0:59because at the end of the day, VXLAN's real purpose in life

1:02is to make sure that we're tunneling frames

1:05from one broadcast domain across our data center

1:08to reach the same broadcast domain.

1:11The broadcast domain has now been broken up

1:14by layer 3 links,

1:15but we can still reach it because that's the whole purpose.

1:18This actually introduces the first key term.

1:21If we've got this blue device right here,

1:23my blue devices are in VLAN 20,

1:25and they're associated with the VNI of 4920.

1:29So we've got VLAN 20 existing all over the place,

1:32and we agree that this is for VNI 4920.

1:36We now build a tunnel to our remote VTEP,

1:40and we agree, "Hey, we're looking for MAC addresses

1:42"in VNI 4920, so if you learn of any MAC addresses

1:47"that are associated with VNI 4920, send them my way."

1:51So EVPN steps in, it does its thing.

1:53We share MAC addresses,

1:54and now all of a sudden we've got communication

1:56for the broadcast domain associated with VLAN 20

2:00or VNI 4920.

2:01That makes this device, this VTEP,

2:04called a layer 2 gateway.

2:07We can now extend layer 2 communications

2:11across our data center because these devices

2:14are now layer 2 gateways.

2:16So that's honestly pretty straightforward.

2:18We understand that why

2:20this would be called a layer 2 gateway.

2:21It's just 'cause we're extending layer 2 communications.

2:24But what about layer 3?

2:26How does layer 3 work at all?

2:28And this is actually a huge talking point

2:31about EVPN and EVPN-VXLAN.

2:35Well, the first things first,

2:36what you need to know about this,

2:38this is one of the most incredible and cool design concepts

2:41that there are, is that these VTEPs,

2:43these switches on our leads,

2:45they will serve as the default gateway

2:50for our client devices, our host servers or virtual machines

2:54or any of the devices that are communicating into this.

2:57Now, how does this really work?

2:59This is actually pretty cool.

3:00Let's say VLAN 20 here,

3:02my blue VLAN associated with VNI 4920,

3:06let's say it exists in the 10.1.1.0/24 subnet.

3:11So we wanna give this device

3:13a gateway IP address of 10.1.1.1.

3:17No problem.

3:18Now this device can communicate into the switch

3:21and reach its default gateway.

3:23But then what happens?

3:24Let's say we now wanna route traffic from VLAN 20

3:29to VLAN 30?

3:30Let's say this is, make something up

3:32like a Windows 10 computer, a host computer,

3:35and it needs to be routed over here towards this file share.

3:41Makes sense.

3:41This is a pretty typical need in our environment.

3:44How does that then work?

3:46Honestly, if you think about the stuff that we covered

3:48in the previous video when we talked

3:50about how a VXLAN packet is actually formed,

3:53it makes a whole lot of sense.

3:55All we're gonna do is we still use VTEPs

3:58and we still use the same tunnel,

4:00but instead we just say the destination VNI is now 4930.

4:06So this device will communicate

4:07and send a packet to its default gateway, and it says,

4:10"Look, I'm trying to get over here into this pink subnet,"

4:14which, make something up.

4:15It could be something like 10.1.2.0/24,

4:20and the device will say, "Okay, well, since I know

4:23"about VNI 4930, I'm gonna go ahead

4:26"and encapsulate your frame and send it over via VNI 4930,

4:32"and that way it'll go out towards the pink customer

4:35"and the pink file share."

4:37And the file share will reply

4:38with a very similar traffic pattern.

4:41When it comes time to reply,

4:42this switch will send it with a VNI of 4920,

4:46and it'll come back towards this switch like so.

4:49That then means that these devices are now layer 3 gateway,

4:53but there's a very critical thing

4:55that you need to understand about data centers,

4:58and it all comes down to virtual machine mobility.

5:01So it's not just as simple as just a default gateway.

5:04What we actually have to deploy to make this work

5:07is an anycast gateway.

5:10Let me clear up the screen a little bit

5:11and I'll show you what I mean.

5:12One of the biggest things

5:13that makes a data center a data center is the fact

5:16that what we're really doing at the end of the day

5:18is spinning up a whole bunch of little virtual machines,

5:21and these server hosts can migrate these virtual machines

5:26back and forth all the time, and they absolutely do.

5:30But think about this.

5:31If these virtual machines had the default gateway

5:33of 10.1.1.1, and that was existing here,

5:37what happens when this virtual machine

5:40migrates all the way over here towards this switch up here?

5:44Well, without any sort of special configurations

5:47or anything really going on here,

5:48we would have to jump onto the virtual machines,

5:51reconfigure the default gateway to now be the IP address

5:54of the new VTEP, the new switch,

5:57and then it would have to ARP for that new IP address,

5:59find out the MAC address,

6:00and then default gateway communications could resume.

6:04What we can do, however, though,

6:06is we can actually configure these switches to tell them,

6:09"Hey, you are going to be a VTEP,

6:10"and you are also going to be an anycast gateway."

6:14So we will tell all of these VTEPs

6:16that you will all support the exact same virtual IP address

6:21and the exact same MAC address.

6:25Here, I'll write that as abbreviated.

6:27That way when a virtual machine migrates

6:30from one host to the next, the default gateway

6:33remains the exact same and the ARP resolution

6:37remains the exact same, and therefore connectivity

6:40during a migration never really gets lost.

6:43You may lose one or two packets, but that's about it.

6:46Most of the time you don't lose anything at all.

6:49In fact, I was doing things like Plex servers

6:51back in the day, and I would actually migrate a Plex server

6:54from one VM to the next while streaming a video,

6:57and I never actually lost any packets or frames.

7:00I was able to continue streaming videos from the Plex server

7:03while it was migrating back and forth.

7:05That's how good these things are at handing off

7:08from one machine to the next,

7:10as long as the network is able to support it.

7:12So now we understand what a layer 2 and a layer 3 gateway is

7:15in the context of EVPN-VXLAN

7:19during the spine-leaf deployment,

7:20but we also understand a major concept,

7:23that we will be deploying anycast gateways

7:26on these leaf nodes.

7:27That way when these migrations take place,

7:30none of the traffic actually gets lost.

7:31So I hope this has been informative for you,

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

0:01(gentle music)

0:06<v ->Now, the last topic that we need to talk about with VXLAN</v>

0:08is more about the evolution of VXLAN's control plane.

0:12When VXLAN was implemented as an RFC,

0:15it was ratified in an RFC,

0:17it was deployed without a control plane.

0:20They call this controllerless VXLAN.

0:22And instead, what it did is it used multicast

0:25to broadcast effectively all of these MAC addresses

0:28throughout the topology

0:29until the remote devices learned the MAC addresses

0:32and then could build shortest path trees to each other.

0:35So in this video, we're gonna do is we're going to explore

0:38how this multicast deployment of VXLAN worked

0:41without a control plane.

0:43And that's actually gonna help us

0:44as we transition into the EVPN discussion

0:47in the next set of videos.

0:48So let's take a look at how multicast worked

0:50for supporting VXLAN back in the old days.

0:54I'll see you there.

0:55Now, this is not something that you need to know

0:56a whole lot of information about for real-world deployments.

1:00This is not something you're gonna encounter very much

1:02in today's production data center networks.

1:05However, you do need to know this for the JNCIP-DC exam,

1:09as well as it's just kind of fun information to have.

1:12If you ever find yourself in an impromptu

1:14networking history trivia battle,

1:17you've got this arrow in your quiver.

1:18So let me clear my head

1:20and just kind of tell you what we're talking about here.

1:22When VXLAN and the RFC was designed and deployed,

1:26there was no mention of how EVPN or BGP could be used

1:31as the control plane.

1:33Instead, what it wanted to do was let's just use multicast

1:38and handle the distribution of traffic on our own.

1:42And this is specifically going to be using PIM sparse mode.

1:46Now, if you need to pause and circle back

1:48and go watch the multicast traffic,

1:49I'd encourage you to do that

1:51because the expectation at this point is that you do know

1:54at least fundamentally how PIM sparse mode

1:56and rendezvous points really work.

1:58So how does it work?

1:59We've got our VTEPs here,

2:00this is a spine leaf architecture,

2:02so our VTEPs are going to be located on our leaves,

2:06and we have a broadcast domain,

2:08actually there's a word B there,

2:09we have a broadcast domain, VLAN 20,

2:12which we're mapping to VNI 4920.

2:15So the frame comes in on this device right here,

2:19and this device learns the MAC address.

2:22How then does it relay this MAC address information

2:27to all of the other devices that are interested

2:30in commuting on, or communicating on VNI 4920?

2:34What we really did is we associated VNI 4920

2:38with a multicast group.

2:40So we'll say, let's just call this 224.1.5.30,

2:46make something up.

2:47So we would then stand to our rendezvous point,

2:51which is sitting here in the middle of our network,

2:53we would then send a star,G,

2:57saying we would like to join the group of 224.1.5.30

3:03and the flip side,

3:04the exact same thing would happen over here for VNI 4920.

3:09The frame comes in

3:11and we have mapped that to 224.1.5.30,

3:15and this device will send a star,G to 224.1.5.30

3:22Now, because we're also sourcing traffic from 224.1.5.30,

3:27we can send our S,Gs over here to the rendezvous point

3:32who will then forward it on to the devices

3:35whoever requested a star,G,

3:38and the same thing happens in the other direction.

3:41And this is where the magic really starts to occur.

3:43When traffic that has been sourced

3:45from this device right here makes its way in

3:48and we start advertising an S,G as well as a star,G

3:53and then it makes its way over to this VTEP,

3:56this is where it gets magical.

3:57The VXLAN frame now looks like this.

4:00We have the original frame,

4:02we still have the VXLAN header

4:05which identifies the VNI of 4920

4:08but now the outer packet is 224.1.5.30, right?

4:13Well, because we know that this is associated with VNI 4920

4:19and because we now see the source IP address

4:22and because we can now learn the incoming MAC address,

4:27we now know how to build our VTEP tunnel

4:31and send direct communications over the tunnel that way.

4:35So this is how controllerless VXLAN was always working.

4:39Instead of sending traffic

4:41directly towards a unicast IP prefix,

4:44we associated a VNI with a multicast group,

4:47and all of the devices that joined the group

4:50based on communicating to the rendezvous point

4:53and originating a star,G join request,

4:56they now receive multicast traffic that comes inbound.

5:00But when they receive that multicast traffic,

5:02they immediately see the VTEP source IP address,

5:06the VNI, and they learn the MAC address

5:09that's coming inbound that way.

5:10So this is the way that multicast and PIM

5:13could have been used to actually deploy VXLAN

5:15back in the day.

5:16What we find out

5:17is that that's not nearly as scalable as using EVPM,

5:21but we'll talk about that more in the next set of videos.

5:23For now, you understand how the original RFC

5:26can called for controllerless VXLAN using multicast.

5:30It all originates the exact same way

5:31that multicast handles it,

5:32we go to a rendezvous point

5:34and then we build shortest path trees.

5:36In this case, we're building a shortest path tree

5:39towards a specific VTEP for a specific MAC address

5:42we learned on a specific VNI.

5:45I hope this has been informative for you

5:46and I'd like to thank you for viewing.

0:00(soft music)

0:06<v ->So now we have a pretty good grip</v>

0:07as to what VXLAN brings to the table

0:10and how it actually operates.

0:11We learned the key terms, we learned the designs and layouts

0:14and how all traffic would flow throughout the topology.

0:18And then we even talked a little bit

0:19about the evolution of VXLAN

0:21and how it interacted with a control plane

0:23or more or less, without a control plane by using multicast.

0:27So now that we understand VXLAN,

0:29we can transition a little bit

0:30to talk about the other half of the topic, which is EVPN.

0:34At that point,

0:35we'll have our heads wrapped around EVPN VXLAN pretty well.

0:38I hope this has been informative for you,

0:39and I'd like to thank you for viewing.