Understanding VXLAN

0:01Welcome to the content on understanding VXLAN.

0:04Right here marks one of the biggest shifts from the old versions of Juniper certification exams to the new ones.

0:11Previously, in the last iterations of Juniper certification exams, you didn't even get a data center exam until you got to the professional level.

0:20The prerequisites were to go through JNCIA and then JNCIS Enterprise.

0:26So it was only when you got to the professional exam that you started talking about EVPN and VXLAN.

0:33In the new versions of the JNCIA-DC, the JNCIS-DC, these are new exams.

0:39So they're easing you into this very big topic.

0:43So if we were comparing again in JNCIP-DC and the old exams, you would learn all of the concepts of EVPN and VXLAN and then the configurations for it.

0:56With JNCIA, we talk at a very high level about what EVPN VXLAN does.

1:03In JNCIS, we then start to break it apart.

1:07We talk about what EVPN is and what VXLAN is.

1:11But we still don't do any configurations because they're really, really big topics.

1:16And it's really important that we just understand what each of these protocols do and what the key terms are.

1:23So that's where we are now.

1:25In our first video where we're talking about the core technologies of data center, we're going to start talking about what VXLAN does.

1:33Ultimately, VXLAN is our data plane.

1:36It's not our control plane.

1:37It's our data plane.

1:39So we're going to introduce the key concepts to what VXLAN does, how it does it, and most importantly, what the key terms are.

1:47Of course, there's some alphabet soup in here that's specific to VXLAN.

1:51So it's really important that we understand things like the VTUPS and the VNI's.

1:56So without further ado, let's talk about VXLAN.

0:00We are now in the JNCIS DC and it's time to start digging more into the technologies

0:07and answering some of the bigger questions that we have. So we know just from what we learned in

0:13the JNCIS DC a couple things about data centers. One of the big things is that it has a spine

0:21leaf architecture. This is very different from the enterprise environment, isn't it? Because

0:26the enterprise environment, you see core distribution access, three tiers of network

0:33infrastructure to move traffic across an enterprise. But in the data center, we only have two tiers,

0:39the spine and leaf architecture. We also know that there is something that makes the spine

0:45leaf architecture really special, and that is the EVPN VXLAN fabric. And you also know,

0:54just based on the title of this skill, that we're really focused in on VXLAN right here.

0:59But there are still a lot of questions up in the air that we need to answer. The big one that we're

1:05answering in this video is why. Now, we already know a little bit again that a lot of traffic

1:12in a data center moves east to west. We talked again about this in the JNCIS DC. But let's start

1:18to answer some of the bigger questions of why. Why don't we use trunk ports across our switching

1:26infrastructure to minimize our layer three blueprint? Well, look at this for a second.

1:32If I have traffic, let me use something like green to point this out. If I have traffic that can go

1:40up here, then it can go something like down here, then it can go up here,

1:48then it can make its way back down here. What do we have in this? That's a loop.

1:56Knowing that this, if these were layer two links, and this was trunk ports everywhere,

2:00and we see there's two paths to get around this infrastructure, we end up with a loop.

2:07What do we do in the enterprise environment to stop that? We use spanning tree protocol.

2:14What does spanning tree protocol do? It detects this loop, and importantly, it blocks

2:21one of these links. That's fine for an enterprise environment. We still have redundant paths.

2:29Spanning tree protocol converges relatively quickly. If a link goes down, it can reconverge

2:35and renegotiate the links and get the backup links up, so to speak. That's fine.

2:42In a data center environment, though, if we have spanning tree protocol running,

2:48we effectively cut off 50% of all of our links, effectively, roughly 50% of all of our links,

2:57potential links in a data center. That means we lose 50% of our possible throughput.

3:08The big thing about a data center is throughput. We have a huge amount of traffic, I mean,

3:15a massive amount of traffic moving east to west through our data center. We spend a lot of money

3:22on these data center switches just to remove 50% of our throughput. Take it a step further.

3:29Think about things from the perspective of a public cloud, like Azure, like AWS, like GCP.

3:36Now, all of a sudden, it's not just our infrastructure servicing our apps,

3:41and we're losing 50% of our traffic. It is our customer's throughput that we lose

3:48when we use 50% of our traffic. That's a big deal. That's a big problem,

3:55and they have a certain expectation of having highly performant, also highly available resources

4:02with them. Think about this again. For every resource, like storage resource or platform

4:08as a service resource that a customer deploys, there's probably at least one copy of it

4:16living somewhere else within our infrastructure. So, it's not just they deploy one application

4:23that consumes one resource and a certain amount of bandwidth. It's actually more than that,

4:28because there's replication and backups going on at the same time.

4:33So, what do we do? Let me pause and clear the screen for a second.

4:37Instead, we solve this problem by putting slash 31 prefixes for each one of these links,

4:45making them routable. Then, we begin building our fabric with an underlay,

4:53which is really just an IGP. Lots of times, it's OSPF. Sometimes, it's ISIS. Very rarely,

5:02will you see something like IBGP in the mix right there, because we're really going to use IBGP

5:07in our overlay. So, I'm going to tell you right now, you're pretty much always going to see OSPF,

5:12maybe ISIS, depending on what the solution is that they're really bringing to the table.

5:17Safe bet that it's going to be OSPF. Now, the cool thing about this is when we deploy

5:23when we deploy slash 31s on each one of these links right here, and then we deploy OSPF,

5:30assuming all of these links are the same bandwidth, same fiber, or whatever,

5:38you will end up with equal cost multipathing, meaning that OSPF can safely send traffic over

5:49both links instead of just one. And then, we actually expand our potential bandwidth and

5:55throughput that way. That's kind of the beautiful thing about link state databases and link state

6:01protocols. They understand every possible link in every possible route to get from point A to point

6:07Z. And because they're routed interfaces instead of switched interfaces, there's really not a

6:13potential for a loop to occur here. Using things like bidirectional forwarding detection in

6:21conjunction with these protocols, we can get rapid convergence whenever a link goes down too.

6:28So, right here, by using OSPF or ISIS and slash 31 links throughout our data center,

6:35we've solved the problem of reducing our bandwidth by using spanning tree protocol. Now,

6:42every link is a possible path to use, and because these things have built in equal cost

6:48multipathing, we actually get load balancing across all possible links. Yay. But this sets

6:56up the next problem, which is what VXLAN and EVPN seek to solve. These servers right here are really,

7:03really powerful servers in the modern data center, right? And they're not just running,

7:07or they're typically, typically not just running one application. Usually, there's something like

7:13virtual machines that run here. Perhaps this is a cluster of web servers that has a load balancer

7:20in front of them. Well, across the data center, we'll have more servers right here. And maybe

7:28this one only has one little virtual machine running on it. So, when I look at this server

7:34right here, and it's got its five VMs, maybe, just maybe, it's pegged out. Maybe it has 95%

7:42CPU and 98% RAM utilization, whereas over here, we might be looking at 5% CPU utilization and 8%

7:54RAM utilization. So, these servers are smart. They're in what's called a cluster. They're in

8:01constant communication about, you know, their current workloads and health to each other.

8:07So, this server right here says, hey, I'm kind of maxed out over here. You're sitting kind of idle.

8:13Can you take some of my workload? And these virtual machines, some of them make their way

8:20over here. They're migrated. Great. But this sets up the next problem.

8:26These were all on the same virtual LAN. Let's call that VLAN 10, which is 192.168.10.whatever

8:37slash 24. Now that they've migrated over here, they expect to still be on the same VLAN,

8:45192.168.10.whatever, so that they can communicate directly to each other. But that's the problem,

8:51isn't it? When this VM, let's say that's 192.168.10.11, wants to communicate to this VM

9:00over here, let's call it .9, what happens? Well, they think they're on the same VLAN,

9:06so it builds a frame, it sends a frame up here, and that's where it dies, right? Because these

9:12are Layer 3 interfaces. If this were a frame, you know, going over Layer 2 interfaces,

9:17over switched interfaces, we could just trunk it across the network. But again, that would reduce

9:23our bandwidth by roughly 50%, our throughput by 50%, and that's no good. Customers can't have that.

9:29So we now have the next problem that we have to get a frame from here across our Layer 3 interfaces

9:38back down to this server. How do we do that? That is what VXLAN does. VXLAN is a data plane

9:50protocol. It's not a brains protocol, so to speak. It's not a thinking protocol. It doesn't know for

9:59sure, it can't figure out for sure how to get it over there, but it knows that it has a technology

10:05to get it over there. So what VXLAN will do, in conjunction with a control plane that we're

10:12going to talk about later, is it will say, okay, I've got this frame that needs to get

10:18over here to the server. So what I'm going to do is I'm going to build a logical tunnel

10:24between these endpoints like this, and we're going to take that frame from 192.168.10.11,

10:36and we're going to put it inside of a packet that is destined for this endpoint of this tunnel.

10:45So that frame will get carried through the network over the tunnel out to here to this endpoint on

10:55this switch, and this endpoint will de-encapsulate it and then send the frame down to its destination.

11:04So because it's inside of a packet, the packet can be routed through the infrastructure from

11:11one tunnel endpoint to the other tunnel endpoint, and the VXLAN technology knows,

11:16oh, I've received a packet on this specific tunnel endpoint. I need to de-encapsulate it.

11:23I'll be left with a frame, and I can forward that frame on to its destination.

11:28Now, this is oversimplified yet again. We understand the why. Why do we need

11:3431s in our data center? We also understand why we need spine leaf. Everything is two hops away

11:41in the entire data center. Two hops away. Not three, not four, not five.

11:45Goes up to the spine, down to the leaf. That's it. So we can tunnel a frame no more than two

11:52hops away from one endpoint to the other, and because we're using equal cost multipathing,

11:58we have multiple paths to get from one tunnel endpoint to the other. We can do it quickly.

12:05So now the big picture is starting to come together. We still don't understand everything.

12:10We haven't talked about EVPN, which is the control plane, and we have a lot more to talk about VXLAN,

12:16but now hopefully that little light bulb is flickering, and we'll move on to the

12:20next video where we elaborate more on how VXLAN does what it does.

0:00Now to be clear, this is not the content on EVPN.

0:03You've got a lot more content on EVPN coming up,

0:07but I feel strongly that you've really

0:09only been given half the picture.

0:12We kind of start to understand

0:14why VXLAN matters at this point.

0:16VXLAN is the technology that can build a tunnel

0:20from point A to point Z in our network

0:25and then tunnel frames through it.

0:27But what VXLAN can't do, what VXLAN doesn't do,

0:32is it doesn't learn MAC addresses.

0:35That's the weird part, right?

0:37Because when I think about this frame right here,

0:39trying to get to this VM over here,

0:42it's going to build a frame and send it into the switch.

0:46What does the switch do?

0:48When a frame arrives on a switch port,

0:51it builds a MAC address table.

0:57And it knows, okay, if I receive a frame

1:01destined to this MAC address,

1:02I need to send it out this switch port right there.

1:07And then, likewise, as frames come in

1:09on a certain interface, it says,

1:10oh, I saw this frame come in on a certain interface,

1:14so if I see a frame destined for that,

1:16I need to send it over here.

1:17Well, that's the problem because frames

1:20are not going to arrive from this VM

1:26over here to this switch naturally, right?

1:30So how would VXLAN know to tunnel a frame

1:34from here to over there?

1:36That's what EVPN does.

1:38EVPN is our control plane.

1:42Basically, it's the part that learns MAC addresses.

1:46It's what builds the MAC address table.

1:48Now, I know it seems scary because it says EVPN,

1:51but EVPN is really just IBGP.

1:55What happens under the hood is we'll run IBGP

2:00on our leaves and build neighbor relationships

2:05between our leaves like so.

2:07And what EVPN, which is really, again, IBGP does,

2:11is when a frame comes into this switch

2:15and it learns the frames, like,

2:17oh, it's off of this switch port right here,

2:20it then uses IBGP to advertise to its peers,

2:26hey, I now know this MAC address came in off of me.

2:33So if you need to send a frame to me,

2:37go ahead and send it.

2:39If you need to send a frame to this MAC address,

2:41go ahead and tunnel it to me.

2:45So now, because we're advertising

2:48all the learned MAC addresses throughout the data center,

2:52we can then use VXLAN to tunnel them

2:55from one point to the other.

2:56The cool thing about this then becomes is,

3:00let's hang on, let's draw this right here, a new server.

3:02This virtual machine right here can migrate over here,

3:09send in a new frame, and then this switch will say,

3:13hey, I've just received a new frame over here.

3:17So now this VM lives here.

3:19If you need to send a frame to this VM,

3:21you can now tunnel it to me.

3:23Then VXLAN will build a tunnel there

3:26and then ship frames over it that way.

3:29Hopefully this illustrates how EVPN is the control plane,

3:33where it advertises learned MAC addresses to IBGP peers.

3:38And then VXLAN is the piece that actually builds the tunnel

3:43from one peer to the next,

3:45and then tunnels frames over it.

3:47That's how the two work in conjunction.

3:50It is important to understand

3:52that these are separate protocols.

3:55In fact, in other environments,

3:57you don't even have to use IBGP.

4:01You can use LISP.

4:03You can use PIM.

4:07There's all sorts of control plane protocols

4:09that can track the locations of certain things.

4:12In the data center, we use EVPN,

4:15and we'll explain why we use EVPN and IBGP

4:19when we get to that content.

4:21Right now, I just want you to understand

4:24why control plane and data plane are separated,

4:28but how they work together.

0:00The good news with VxLAN is there's really only two key terms that you need to know. If you're

0:06looking at the JNCIS DC exam outline, it's pretty much the thing that they want you to take away

0:14from this section are these two key terms, VTEPs and VNIs. What are they? That's what we're going

0:23to talk about right here. Let's start with VTEPs. That is Virtual Tunnel Endpoint. Now,

0:30what does that really do? This is really the tunnel IP address when we build a tunnel from

0:36one switch to the next. If we were building a tunnel like this, this would be the VTEP IP here

0:45and the VTEP IP here. Now, what are these IPs? They're the switches loopback address.

0:53So, when we're building a tunnel from say, you know, the loopback address here of 1111

0:58and the loopback address here of 2222, these VTEP IP addresses, really the loopback addresses,

1:06are going to be advertised by the underlay, ISIS and OSPF. And that's how we get equal

1:11cost multipathing from one tunnel endpoint to the next. So, now we know when a frame comes in

1:18and it's destined over here, we're really going to be sending it to this VTEP IP address right there.

1:26Almost always, almost always in a real enterprise data center, you end up with a full mesh

1:37of tunnel endpoints. Like, so that's, got to miss my circle there. There we go. You almost always

1:42end up with a full mesh of VTEP endpoints. So, we're really talking about a full mesh

1:50of loopback to loopback communications. Now, these are usually dynamically created

1:58whenever the control plane says we need to establish communication for, you know,

2:04VXLAN tunneling, tunneling the frames back and forth. But like I said, you almost always end up

2:11with a full mesh of connectivity because at some point, you know, a tenant's virtual machine,

2:19you know, you might have green tenant and pink tenant down here. And you might have yellow

2:24tenant and green tenant over here. And then blue tenant and green tenant over here. Still, at some

2:30point, you're going to have VM to VM communication from one switch to the next. So, the first key

2:37term to take away here, virtual tunnel endpoint VTEPs, is really just loopback to loopback

2:43communication that's built for tunneling your frames. Now, here's the next thing, the VNI's.

2:50This is where it gets a little more complicated, but you'll also probably walk away going, oh,

2:56that's how it works. Pretend for a moment you are AWS. AWS rents out virtual machines.

3:05They are EC2 instances is what they're called. Elastic Cloud Compute, that's what it's short for.

3:12It's elastic because we can size up or size down a virtual machine on demand to meet our workload.

3:21So, let's say you are AWS and you have this kind of teal tenant down here. And the teal

3:30tenant spins up their own EC2 instance, which means they spin up their own virtual network.

3:37In AWS, they call those VPCs. In Azure, they call them, you know,

3:42VNets or virtual networks. It's really just a VLAN from your perspective. And they say,

3:50you know, I want to use the subnet 192.168.10.0.24. And, you know, under the hood, we might

4:00call this something like VLAN 10 to match that third octet. That's all well and good, right?

4:05Well, then, along comes the purple tenant right here. And, you know, they spin up their own AWS

4:11account. They spin up their own EC2 instance, which then spins up its own VPC. And they say,

4:18I want to use 192.168.10.0.24. This is something that is possible right now.

4:29Many tenants have overlapping subnets. So, without understanding how this is actually

4:36working right now, what would happen if the pink tenant here sends in a frame, you know,

4:42192.168.10.0, sends in a frame destined for .11. Let's say .11 is over here.

4:50The frame would come in and it would get tunneled. And then this switch is left with a, you know,

4:59192.168.10.0 location. And right now we're thinking, okay, that was VLAN 10, but, uh-oh,

5:10we've got overlapping subnets right here. How does it know to segment that traffic out

5:18to the blue tenant? Well, one of the cool things that happens, well, so let's solve this for a

5:25problem. When you're a network engineer right now, you're thinking, okay, well, we could stop

5:30them from using overlapping subnets. They would have to use a different subnet and a different

5:35VLAN. Well, the problem with that is there are 4,094 usable VLANs. Chances are you're going to

5:43use some of them for your own network, you know, behind the scenes. So, you know, scratch out some

5:48of those. That means, you know, let's just make up something. Let's say you use 10 VLANs. That

5:54would leave you with 4,084 possible VLANs, which means you can only have 4,084 customers.

6:01Would that work for AWS? Absolutely not. They probably have more than that in a single data

6:07center. At the end of the day, a VLAN is just a 12-bit, you know, array of numbers right there.

6:15And it severely limits the amount of customers and therefore subnets you can have. So what VXLAN

6:22did is it introduced the Virtual Network Identifier, or VNI. This is a 24-bit number

6:31that identifies your customers' networks. So let's say, let's go back to Teal here for a second.

6:39This customer says 192.168.10.0, that's my subnet. What VXLAN will do is it will generate

6:48a VNI, let's say 65,535 or something like that. So when it learns a MAC address in on the switch

6:59and advertises it to all of its peers, like so, it will say, I've learned this MAC address

7:10and it belongs to VNI 65,535. And since they've got a customer down here, they also know about

7:22VNI 65,535. So when a frame now comes in and goes over the tunnel to its peering switch,

7:33it will see, oh, I've got this frame that came in and belongs to VNI 65,535. I'll de-encapsulate

7:44that frame and only send it out to that particular tenant's network devices.

7:52Similarly for Purple, Purple will say, I want to use 192.168.10.0. VXLAN says, great, we'll give

7:59you a VNI of 131,119. And when it advertises its MAC addresses, boop, boop, it says, I learned this

8:10MAC address in VNI 131,119. So now when frames get tunneled over the tunnel, the frame will be

8:22included with a VNI that it belongs to. So that when it gets de-encapsulated, it'll go straight

8:28out to that tenant's network instead of all the other networks. That way the tenant can use

8:34whatever subnet and VLAN they want because it's segmented by a VNI. The VTEP is what allows

8:44switch-to-switch communication over a tunnel. The VNI is what allows multi-tenancy,

8:53such that each tenant can build their own network using whatever subnet they please.

8:59And we can then have overlapping subnets, but still segmented by the VNI.

0:00The next thing we're gonna talk about

0:01with VXLAN is gateways.

0:04When it comes to VXLAN,

0:05there are two gateways that exist.

0:08They are Layer 2 gateways and Layer 3 gateways.

0:12The first one, the Layer 2 gateway,

0:14probably the easiest to understand

0:16because it's really the entire point of VXLAN.

0:20Let's say this, we've got right down here,

0:22our Teal client is VLAN 20, which is VNI 4920.

0:28When this client plugs into the switch,

0:31we learn a MAC address.

0:32What does this switch do?

0:34We know just from our very cursory experience,

0:38EVPN is going to advertise that MAC address.

0:43Hang on, let me undo that line right there.

0:44It's gonna advertise that MAC address to its peers.

0:49Like we see over here, the Teal server has,

0:53the Teal client has a server over here.

0:55It'll say, I know about this MAC address right here

1:00that belongs to VNI 4920.

1:03So if you have any client

1:07or any traffic destined to that MAC address,

1:10you can send it to me.

1:11Likewise, if you learn about any MAC addresses on VNI 4920,

1:17I would like to know about it too.

1:19I would like to subscribe to your VNI 4920 updates.

1:25That you get.

1:26This makes it a layer two gateway

1:29because now we have the ability to tunnel frames

1:34from one end of the data center

1:35to the other end of the data center

1:37for traffic that belongs to VNI 4920.

1:42Now, the question then becomes, okay, that's great.

1:44We understand this concept with VXLAN.

1:48It's all about moving frames east to west

1:51over layer three links

1:53so that we can have layer two communication

1:56anywhere in the data center.

1:58Great, right?

1:59What happens when we're not having layer two communication?

2:04What happens when we're having layer three communication?

2:08Let me use red for this example right here.

2:12Let's say this particular host, this client right here,

2:16wants to talk to this one.

2:19Uh-oh, what do we do here?

2:21Well, we know we're gonna be tunneling a frame, probably.

2:25So let's go ahead and build a VXLAN tunnel here.

2:29But the question becomes, okay,

2:31this client is gonna send traffic outbound.

2:34We need to tunnel that traffic over here.

2:37How do we get the traffic to exit out to this?

2:40In a really simple example,

2:42let's say this is a Windows 11 client computer

2:47and this is the corporate file share.

2:49Very common traffic pattern, right?

2:52We've got clients and workers, desktops,

2:55connecting to the corporate file share.

2:56They are almost never on the same subnet.

2:59In fact, the file share is very regularly

3:02in a data center or something.

3:03So how do we make this traffic come to life?

3:06Well, what ends up happening in an EVP and VXLAN environment

3:10because this is in the data center.

3:11We're not talking about enterprise example.

3:13Let's say this is a Windows 11 VM

3:16that we rented from Azure

3:18and we're trying to get it to communicate to our file share

3:22which exists somewhere else, even on a different subnet.

3:25How does this traffic happen?

3:27Because importantly, remember,

3:30this file share can still live on a subnet

3:34that overlaps another customer subnet.

3:38We can't get around using VXLAN and just traditional routing

3:43because the whole idea is that we can use

3:46any subnet we want.

3:47So even though we've got, you know,

3:50a VLAN 20 here and a VLAN 30 here,

3:52we can't just route from teal to pink.

3:55It has to be separated by VXLAN

3:59because it's the potential

4:01for overlapping subnets elsewhere.

4:03So what we do is when this frame comes in,

4:07it builds a tunneled packet

4:10with a destination VNI of 4930.

4:18So that when it arrives, this switch goes,

4:21oh, that's destined for VNI 4930.

4:24Let's go ahead and de-encapsulate it and send it down here.

4:28Ultimately, there is going to be a policy that gets created

4:33where the tenant owns VNI 4920 and 4930.

4:44And perhaps this is something that even the tenant

4:46customizes which traffic they want to allow

4:49to communicate to each other.

4:51Maybe they don't want these two subnets to communicate

4:54or maybe they do.

4:55And when they say,

4:56I do want these two subnets to communicate,

4:58the policy then says these VNI's

5:01can be routed back and forth to each other.

5:04So when the Windows 11 client

5:06wants to talk to the file share,

5:08it will send the frame in, it will be encapsulated,

5:12and it will have a destination VNI of 4930.

5:15When the return traffic comes back,

5:17it will have a destination VNI of 4920.

5:23That makes this a layer three gateway.

5:26Specifically, the leaf will be the layer three gateway.

5:32Now here's where it gets a little trickier.

5:35Let me pause and clear the screen quite a bit.

5:38This routing, of course,

5:39was facilitated by a default gateway.

5:44So this client knows, okay,

5:45well, I'm trying to communicate to my file share.

5:48That file share is not on my subnet,

5:51so I have to send it to my default gateway.

5:53So let's say this VLAN right here,

5:55VLAN 20, VNI 4920 was 10.1.20.0.

6:02So it says, okay, well, I've got to get this routed.

6:04I'm going to send this in to my default gateway,

6:08which is 10.1.20.1.

6:12This default gateway is what says,

6:14oh, okay, this is destined for VNI 4930,

6:18so I'm going to encapsulate it

6:20and send it over with a destination VNI 4930.

6:22That's how that works.

6:23That's great.

6:24But the real question is what happens

6:28when this virtual machine migrates like this?

6:35Now it's over here.

6:36Well, when we think about default gateways

6:41and we think about traditional networks right here,

6:44do we then have to migrate the default gateway with it?

6:49Because I don't want to have to log in.

6:51Every time this virtual machine migrates in the data center,

6:54that could happen automatically without me as a customer,

6:58without my, let's say I'm the customer here, I'm the tenant.

7:01That virtual machine might migrate without my control.

7:05If I'm renting the VM from AWS

7:08and AWS's servers decide it's overloaded,

7:11it could just migrate my VM without it.

7:13So if I migrate, if this VM gets migrated without my control

7:18do I then lose my default gateway

7:20and therefore lose my layer three connectivity?

7:23No, what we actually end up doing

7:26is we use an any cast gateway.

7:32Meaning every switch that supports VNI 4920

7:38will listen on 10.1.20.1 with the same Mac address.

7:45I'm going to put AAAAAA to abbreviate this.

7:49So that when this machine migrates over here,

7:53there's already, because there's already a VNI 4920

7:57over here, there's already a 10.1.20.1

8:02listening on AAAAAAAA, or whatever it was.

8:07I don't know how many times I just said AA.

8:10There's already an any cast gateway

8:12waiting over here on the other side,

8:16ready to serve default gateway traffic.

8:19So that's how the layer three gateway works.

8:23The default gateway will exist on every switch

8:26that supports or serves this VNI.

8:29It will be an any cast gateway with the same Mac address.

8:33So that this VM can move anywhere in the data center

8:36that it wants and maintain the same default

8:40gateway connectivity and routability to its other assets

8:45and other VNIs that are managed by some policy,

8:49probably configured by the customer themselves.

8:53So VXLAN, we haven't even talked about really EVPN

8:56outside of the fact that it is the control plane

8:59and it advertises Mac addresses

9:01and their association to the VNI back and forth, right?

9:05But VXLAN, the big takeaways for you to understand here,

9:09first of all, still using Spineleaf architecture,

9:12separated by slash 31s everywhere

9:15so that we can maximize our bandwidth

9:18in our high-performance data center

9:20and therefore offer that to our customers

9:22via equal cost multipathing.

9:25Big things to understand next, VTEPs and VNIs.

9:30VTEPs are the switches, the virtual tunnel endpoints

9:32that they build tunnels back and forth to each other

9:35for encapsulating those frames and sending it over

9:38our equal cost multipath paths.

9:40The VNIs, a unique way to identify

9:44a specific tenant's VLANs so that each tenant

9:48can set their own VLAN with their own subnet

9:51even if they overlap another tenant's.

9:53That way we can keep our traffic segmented.

9:56Now we've got layer two gateways,

9:59which is really just what the VTEP does,

10:01and layer three gateways, which is how we can actually

10:04route traffic from one VNI to another.

10:07Also keeping in mind that we're using

10:09an anycast default gateway to service that traffic

10:13as it moves through the data center.

10:15So VXLAN, starting to get deeper into it.

10:18In the next set of videos, we'll start talking about EVPN.

10:21I hope this has been informative for you

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

0:00Let's take a few minutes to make sure we've got our head wrapped around VXLAN with some

0:05scenario questions. So a VTEP receives traffic from a locally connected host on VLAN 20.

0:14So if I'm thinking about this, I'm thinking about it like here's my VTEP, aka switch,

0:21and it receives the traffic from a host on VLAN 20. So we've got that. We've received the traffic

0:29from a host on VLAN 20. The traffic must be sent across the VXLAN overlay. So it's going

0:35over some channel to a remote VTEP. What information does the VTEP use to identify

0:43the correct VXLAN segment for encapsulation? Basically, how do we make sure this traffic

0:51is segmented so it doesn't spill over into another tenant's environment in their network?

1:01Is it the UDP destination port, VLAN to VNI mapping, the IP address of the destination host,

1:09or the source MAC address? The VNI mapping right here. This is the identifier to identify

1:17a specific tenant's networks. Policies are what enforces which VNIs are allowed to communicate

1:26to each other, but ultimately the segmentation comes down to the VNI itself. So that's the

1:33answer to our first question. A data center team wants to reduce unknown unicast flooding

1:40and improve scalability in their VXLAN fabric. They choose a control plane that advertises

1:48MAC address reachability before the traffic is sent. Which VXLAN control plane option

1:56best meets this requirement? So without a control plane, what ends up happening? The traffic ends

2:03up getting flooded anyways to find the correct MAC address destination, and that never really

2:10works out well. So we want to improve the scalability by advertising learned MAC addresses

2:17before we start flooding it out all of these interfaces. So which control plane best meets

2:23this requirement? Is it flood and learn? Well, no, that's what we're trying to stop.

2:27Is it statically setting our MAC address configuration? That's not scalable at all.

2:33Is it BGP EVPN as the VXLAN control plane? Or is it an ARP proxy without a control plane? Basically

2:43bouncing ARP requests all over the place. Obviously it's going to be the BGP EVPN

2:50as the VXLAN control plane. Now we did learn that there are other control planes that you can use

2:55like LISP or PIM. In fact, in MPLS and service provider environments, they use something like

3:01RSVP for traffic engineering, but that's because the traffic is more north south instead of east

3:07west. For data centers, EVPN is going to be the one. And we haven't really elaborated on why that

3:14is yet, but that's what the next set of videos is going to be all about. A VXLAN packet arrives

3:21at a leaf switch from the IP underlay network. So now we're looking at it from the other

3:27perspective. It's coming in from the underlay. The switch removes the VXLAN UDP and IP headers

3:36and forwards the original Ethernet frame to a local VLAN. Which VTEP function is being performed?

3:44So we've received a tunneled packet, which contains the frame. So what does it do then

3:51to strip it of this and shoot it down to the VLAN that it's destined for? Is this flooding it out

3:57the interfaces? Is this encapsulating it? Is it decapsulating it? Or are we learning the MAC

4:04address? The act of removing VXLAN UDP and IP headers from that is of course decapsulation.

4:13So this has been reinforcing what we've learned about VXLAN.