Laying a VXLAN Foundation

0:05Now look, I know you are excited about this stuff, because this is the stuff-- when I'm looking at the exam blueprint, I point to that and say, ooh, that one's going to be fun. EVPN VXLAN-- that's a whole lot of letters, because it's a whole lot of technology. This is an absolutely massive topic that comes up in the JNCIP certification exams. You really have to learn EVPN VXLAN on the JNCIP Enterprise, as well as the JNCIP Data Center certification exams.

0:35There's a variant of EVPN on the service provider world, but it's EVPN MPLS. And you may be thinking to yourself, wait, EVPN VXLAN versus EVPN MPLS-- what's the difference here? Well, that's kind of what this set of videos is really going to be all about. What is the difference between VXLAN, EVPN, MPLS? How do they all come together to make an awesome layer 2 VPN solution? We're focusing on the variant that uses VXLAN. This is already kind of fuzzy and confusing, and that's why we're going to break this down as much as possible, because this is a really, really massive topic.

1:13So if you really want to learn how EVPN VXLAN works, we need to first talk about VXLAN itself. There's a couple reasons why I like to tackle VXLAN first. VXLAN, at the end of the day, is simpler than EVPN. VXLAN is, what it's all about, moving data from point A to point B. How it makes that decision is up to EVPN. So let's start by talking about VXLAN in this set of videos. By the end of this set of videos, you'll understand what VXLAN does, how it is decoupled, and how it works with VPN in order to actually carry data from point A to point B.

1:49Why is it used in enterprises and data centers? How are the different designs, and layouts, and implications all going to work together? And we're definitely going to have to master the key terms that you need to know in order to understand how to actually deploy a VXLAN deployment, because these are the configurations that you're going to be typing in the upcoming set of videos. That's going to cover one part, one piece of the puzzle of EVPN VXLAN. It's going to cover the VXLAN portion. Once we got that under our belt, then we're going to talk about the EVPN portion in the next set of videos.

2:20At that point, you'll understand how EVPN and VXLAN work together, and then it'll be time to actually configure it. So let's get going as we start to introduce the major topic of EVPN VXLANs. We're going to recap what's the point of VPNs? What's the point of layer 2 VPNs? And then how does EVPN VXLAN solve some of the problems that layer 2 brought to the table? I'll see you there.

0:00[MUSIC PLAYING] I have a feeling that if I were to take a poll in fact, that's what I would do is soon as I get done recording this video, I'm going to start a Twitter poll. If I were to take a poll, what is your most hated protocol? When I were to list a few options probably right up there at the hop is going to be spanning tree protocol and DNS. Now we're going to focus on spanning tree protocol and really the problem with layer 2. Why can't we just have layer 2 absolutely everywhere in a gigantic enterprise campus or a data center?

0:33Then we're going to start to talk about and introduce the concepts of VPN and Layer 2 VPN, just fundamentally understanding what they do and how they could start to solve the problems the spanning tree protocol brings to the table. Let's get talking. So as I like to do before we embark on any journey into a new technology, I'd like to introduce the topology that we're going to be working with first. So this is it. This is what we're going to be working with as we explore EVPN VXLAN. Now, it's a pretty basic topology. We have some Q effect switches that are deployed throughout the entire environment and these could be enterprize-- laid out in an enterprise style environment or it could be in a data center environment.

1:14The actual design about why they're laid out in the way that they're laid out we actually have a dedicated video coming up to that. Then we see that we've got some hosts right here we've got some hosts in the Peach or pinkish VLAN and then we've got some hosts in all of this are greenish VLAN as VLAN 512 and VLAN 1512. So now with all this set up, it's time to transition a little bit and start thinking fundamentally about what VPNs do at the end of the day and why spanning every protocol could actually be a problem.

1:45I mean, if you think about it right now if we're running spanning tree protocol in our environment maybe with an FHRP like VRRRP, somewhere along the way, we've got the potential for a loop don't we've going into a switch here and over to a switch here then over to a switch here and then back here and then over here and then back here then over here in the back here then over here the back on there and then it goes like this. There's loops everywhere in this topology. So immediately the first thing I know just by looking at this, somewhere there's going to be an interface that's blocking.

2:16I don't know where just yet. We're just hypothetically thinking about expanding tree protocol somewhere there's an interface that's blocking somewhere and when it comes to spanning tree protocol, unless you really know what you're doing which hopefully you do at the professional level. And if you're working in a large enterprise. There's going to be an interface that gets blocked. And almost always it's never just by default the interface that you want to get blocked, maybe it's going to end up the wrong switch maybe one of these switches down here, which would be like my access layer maybe this interface right here gets blocked and this switch over here ends up being the bridge and it's an access layer just thinking hypothetically how it can all happen.

3:00So what I know in this case is that, first of all, the root bridge or maybe the root bridge for a specific VLAN whatever the case may be, it might not be the preferred one that gets selected and secondly with interfaces being blocked I now and not having the optimal load sharing and bandwidth capabilities that are available in my environment. Even if I do things like bundle my interfaces together, we're still running spanning tree protocol on these bundled interfaces and somewhere even though there's a bundle here there's still a potential for a loop because if I look if I send a frame this way in a broadcast frame this way guess what, one of these interfaces in the middle is going to end up getting blocked right or the actual log itself could end up getting blocked depending on the environment.

3:43So the thing is was fading through protocol. It's just controlled chaos and it takes a lot of optimization and then the problem with it then is when we add new switches into the mix maybe at the access layer or the distribution layer, all of a sudden spanning tree protocols reconverging again and then all of these mechanisms that we put in place like root guard and BPDU guard, now all of those have to be considered before we just dump new switches into the mix and it just becomes an administrative nightmare to keep up with all of this thing.

4:14Look spanning trick protocol does what it says it's going to do and it does it well it stops switchboard's from enabling loops. So I don't want to rag on spanning protocol too much because it really is a protection mechanism that does exactly what it was designed to do, and it's done it well for decades. The problem is now our enterprises are gigantic and if we think about now today's modern campuses like a college campus, we've got dozens or hundreds of buildings spread out all over the place. And what happened now what am I going to do trunk VLANs from one building to the next to the next building to the next one and so on and so on.

4:49Now my gosh, just a nightmare to stretch our VLANs out that long. So what ends up happening, though, is well let's think for a minute why would we still want to do that? Well, let's say this is building A on a college campus and this is building C on a college campus and building A has accounting staff and building B also has accounting staff. Well guess what, these accounting staffs need to be on the same private network so that they can access the same resources.

5:21So the only way to do this by default is to truck VLAN 512 up this way and then send VLAN 512 back down this way trunked back and forth and now we're extending our VLANs throughout the entire topology all based on Layer 2. I mean we're just thinking about how broadcast domains in general work right? That's what we're trying to get to here is we need to have a broadcast domain that's allowed to move throughout the entire topology. So the issue now becomes is I can't change this and put a router right here actually don't let me use a better color for this.

5:56I can't put a router right here because at this point, if this is my Layer 3 gateway, this is where the broadcast domain stops and layer 2 wouldn't be able to make its way over to the other side because that's it that's is far a router stops a broadcast domain that's where the endpoint is. So this is the challenge that we come up with in an enterprise campus is we need to get our hosts that are on the same subnet geographically separated. I mean think about that basically our IP address at the end of the day identifies our location right?

6:30So if we're trying to be in the same location or access the same resources, typically, we had to be in the same building. But that's just not the case, especially now that we live in an era where everybody is mobile, I mean something I read statistics lately of something like 70% of all devices on a campus are wireless devices that means we're moving. So as we move through of campus, we need to maintain the same types of access wherever we go. And this is where VXLAN and really VPN in general start to solve the problem for us.

7:03For a moment let me just hang on let me do this, consider for a moment what a VPN does, I mean, if you're going for a professional level exam, it wouldn't be a stretch to think that conceptually you understand what a VPN does. You don't necessarily need to know how to deploy it just understanding fundamentally what a VPN does. I have two routers here that sit on the edge of my network. Let me make sure I'm not covering this diagram here. And these are separated geographically. Maybe this router is in New York City and this router is in New Orleans, Louisiana, which is why we say NOLA for short.

7:36So these are separated by the internet. But maybe in New Orleans, Louisiana, we have a server-- am I coverage no I'm not covering it yet. There are users in New York City need to access and they need to access it securely. So we're not going to send the traffic over the public internet. So what we do is we create a VPN tunnel over the public infrastructure of the internet. Now hosts on my private network of say 10.1.1.0/24 can directly access servers and hosts on my private network, let me move my head this way 192.168.1.0/24.

8:12Now these hosts can go over this private tunnel in order to directly reach this server here, that is in essence the point of a VPN. But this all took place at Layer 3 right? We're routing packets even private packets over this tunnel because that's what these routers do. Wouldn't it be nice if this switch right here could build a tunnel to this switch right here and we could send our users frames over this tunnel down that way? Well, that's exactly what EVPN VXLAN does and that's what really the rest of these sets of videos do.

8:47This in essence is called a Layer 2 VPN whereas this down here was a Layer 3 VPN. It was all about getting routed packets over a tunnel. So that it could be routed by a router onto its next stop. In this case, this is the default gateway in the Layer 3 VPN, this New York City router is the default gateway and it routes over the tunnel to the NOLA router as its next stop. The NOLA router knows how to forward packets on that way. Whereas this case in our enterprise what we're trying to talk about here is moving frames in the same broadcast domain over a Layer 3 infrastructure.

9:23So we're going to be moving a frame over a tunnel instead of a switchboard in order to get from one building to the next. Now, how does that really work? Don't worry because we're just trying to understand conceptually in this video why we're using a VPN. The VPN at the end of the day is replacing all of these Layer 2 links. All of these links that you see right here this link, this link, this link, this link, this link, this link, this link, this link, this link, we're replacing all of these Layer 2 links with Layer 3 links. This will now be a routed interface maybe /31.

9:55/31 everywhere that's right /31 /31s. So now QFX5 can route its way over to QFX6 build a tunnel and then send the frames that way. So this is what we're going to be unpacking throughout the rest of these sets of videos, we're getting away from spanning tree protocol because it becomes unscalable after a certain point, it becomes too difficult to add new infrastructure in or replace infrastructure in because of the security parameters involved with the ways that we need to prevent routing and switching loops but maintain our FHRP availability so that we're not accidentally blocking our upstream ports towards our master gateway in VRRP.

10:39You get the idea here is that Layer 2 we're just trying to get away from it to a more scalable solution that's based on Layer 3, and this is what EVPN and VXLAN brings to the table. At the end of the day, it is a Layer 2 VPN so that we can get frames over a layer 3 infrastructure. Now how we're doing that, that's what we're going to talk about in next problem with stretching our Layer 2 infrastructure absolutely everywhere. And now we're going to get focused in on how VXLAN fixes it. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Now, an astute observer would have noticed that what we're really trying to tackle here, is how to understand how to deploy EVPN - VXLAN and how it works. But you notice that those are separated, by a hyphen aren't they? EVPN is on one side and VXLAN is on the other side. And if you watch the intro video and paid close attention you know that, there's also a different variation that solves the same problem in the service provider world.

0:30EVPN MPLS. Wait, what's going on here? What's really happening is we are separating the control plane from the data plane. Now how does that fundamentally work? That's what this video is all about. Let's get going. Now, I feel pretty strongly about this topic right here the control plane verses the data plane. At the end of the day, we are breaking down the difference between EVPN and VXLAN. I mean that is what we're talking about here at the end of day is EVPN - VXLAN right. Think about this for a moment on Junos devices, how do Junos devices forward data?

1:04There's the data plane, which is the forwarding engine, right? The Packet Forwarding Engine. So over here, I'm going to put PFE. And how does the Packet Forwarding Engine make its forwarding decision. Well its forwarding decision is derived from the Forwarding Table. Now where is the Forwarding Table come from. Well, that comes from the Routing Engine. And the Routing Engine drives the routing table, which then creates the Forwarding Table. And how do routes get populated, in the routing table.

1:35Well it's all about whatever protocol you're using to learn routes. Basically if we were thinking about IPv6 unicast for a second. We could use something like OSPF. So the control plane, is all about how OSPF shares prefixes and determines what is the best and fastest or the shortest cost I should say-- the lowest cost to reach the next top or to reach the destination. Then it says, OK, well now that we know what is the preferred destination. I'm going to tell the forwarding table, your next hop or your exit address, you're at your Egress Interface should be this.

2:08So then it hands it down to the Packet Forwarding Engine, in the Packet Forwarding Engine can receive a packet in. It can look at the destination, and it knows what interface to point it out of. And it goes that simply. Well guess, what EVPN V X, if you think about that just for a second, there's a pretty clear separation between how a decision is derived. Basically this was the brains of the operation, and the data plane was just the order taker. It knew how to just do things because the control plane has handled all of the hard thinking for us up until that point, If you see that though, you see now there's a pretty clear separation, between the control plane and the data plane on Junos devices.

2:50Now this is a Junos specific technology. This is an open standard technology. EVPN is really at the end of the day, nothing more than BGP. And VXLAN has been open standard for a pretty long time now. So what we're talking about now is, what is the brains of the operation and what is the forwarding, or the order taker in the operation. EVPN because we know this is really just BGP at the end of the day, is the control plane. And VX LAN is the data plane. The data plane all it cares about, is trying to figure out, hey, where should I send this data out-- what interface should I send out.

3:27And it's just going to refer to the control plane to figure that out. In the Junos devices, there will be a VX LAN table, that the VXLAN protocol will just consult. So what, we need to do is we need to populate that VX LAN table with a control plane, to derive the forwarding table. And this is what EVPN does. Now what you're going to find out as we get to the end of this set of videos, is EVPN isn't the only option. We actually have different options to populate this VX LAN table.

3:57We don't have to use EVPN. However, you pretty much always use EVPN. But this kind of begs the question, what is it that we're actually trying to do here. So let's talk about this more, as a packet wall kind of example, on her diet. So we know based on this diagram, that we have this host here on PLAN 5 12. And we need to ping directly this hosts here, host 13 in VLAN 512, in a completely separate building. Seems straightforward so far, except that we've now completely replaced all of these links.

4:32Right here we got rid of layer 2 it's gone completely. And all of these links now, are / 3 1 routed interface. Well if this is 192. 1 6 8. 1. 0 / 24 here, and this is 192. 1 6 8. 1. 0 /24 here. But my default gateway is QGX 5 and this device's default gateway is QFX 6. How are we going to get a broadcast or a layer 2 frame from this building all the way over to this building.

5:08Well the first thing we need to do is, since these are routable we need these devices here to build a tunnel to each other. To send that frame over the tunnel to each other. Look at me, look at me for this part right here. This is what VX LAN does. This is the data plane, this is what VX LAN is bringing to the table. VXLAN is the part of the solution, that builds a tunnel from one default gateway to the next and sends a frame over that layer 3 infrastructure to that tunnel.

5:39The next question becomes, well, how did Q F X 5, know to build a tunnel to Q F X 6 and send the frame over to that tunnel. This is where EVPN steps into the mix. The cool thing about this, let me clear the screen here because this is so important. When host 11 sends it. When you define you to host 11 your default gateway is Q FX 5, what happens immediately when you do that host 11, then opts to find out. What the Mac Address of QFX 5 is. It needs to know what the Mac Address is, of its default gateway.

6:11So that it can get off the subnet. The moment the queue affects 5 learns the Mac Address of host 11. It then advertises that Mac Address over to QFX 6. The same thing happens over here. Host 13 opts for its default gateway. QFX 6 learns that Mac Address and sends it over Q FX 5. So now our table, our forwarding table has been populated. That says, hey, if host 11 is trying to reach host 13's Mac Address, you now know to forward that over the tunnel to QFX 6 because that's where we learn the Mac Address from.

6:53And it's so cool because EVPN at the end of the day, is nothing more than BGP. And BGP can advertise literally anything at this point in time. You can advertise IPv4 unicast, IPv4 multi cast, IPv6 unicast, IPv6 multi cast. It can do flow spec firewall policies. It can do Layer 2 VPN, layer 3 VPN which is called VPNv4. Now it can do EVPN signaling. Which is what we're going to be talking about in the next set of videos. We're just trying to understand conceptually, how the control plane and the data plane come together to build this amazing solution.

7:29VXLAN to recap, is the data plane. And it is what will build the tunnel from one device to the next and send the frames over the tunnel. But it doesn't know how to do that it doesn't know where the next hop destination is. Until we learn about other Mac Addresses and their sources via EVPN, which is really BGP first. The cool thing about it is it doesn't really care, about how it learns the next hop destination. You don't have to use EVPN you can use different technologies to learn the next hop destination.

8:02And look this is a pause, this is just an aside for a second. You don't have to use VX LAN service providers, don't. Service providers use a different tunneling technology you may have heard of this thing called MPLS. So EVPN can still be used to learn Mac Addresses from all of its clients. But instead of using a VX LAN tunnel to send the frames. It just literally label switches the tunnels over these links. It's wild, it's so cool, that now with these separations of the control plane from the data plane.

8:32We have a lot of flexibility and a lot of modularity. You could use E VPN and you can use VXLAN. Or you could use multi cast in VXLAN or you could use EVPN IN MPLS. It's wild how we can do. We can accomplish the same thing. But what you find out pretty quickly is VXLAN is what is used in enterprises in data centers, because of how the design is typically laid out. We're going to talk about the design and the spinely architecture more in an upcoming video-- Like two videos away from now. But now we understand that the control plane is truly separated from the data plane and they interact with each other.

9:08And this is why we're talking about VXLAN first. It's easier to understand fundamentally how data will be flowed before we start talking about how the forwarding decision is actually made. Also, just a spoiler alert: EV PN is significantly more complicated than VXLAN. So get ready for that as we start to dig into EVPN in the next set of videos. So that's been understanding why the control plane and the data plane are separated from each other and why we're tackling VXLAN first. I hope this has been informative for you and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] So what does VXLAN actually do? And how does it do it? That's actually the point of this video. In order to understand the key terms, we really have to start taking a closer look about what VXLAN does. How does it actually move frames throughout an entire topology? So in this video, we're going to introduce some of the key terms, and talk about how those terms or those words or those phrases or definitions actually go together to building out a basic VXLAN solution.

0:33Let's get going-- as we start to understand more about what VXLAN does. I'll see you there! So yeah, there's no escaping having to learn new terms and definitions when it comes to something like VXLAN. But let me put your mind at ease right now. The cool thing about VXLAN terms, is there's really only two terms that you need to know. And this is where you start to see VXLAN in action. The first thing I'm going to bring up is the VTEP-- the virtual tunnel endpoint. So in our diagram-- actually, let's just draw it out. If we had our computer here, and it was connecting in to its router or its switch, basically it could be a layer 3 gateway.

1:12That's what we've been looking at here. Then, it goes up into the distribution tier or the collapsed core tier. So we're going to have a couple links like this. Then, we have the other endpoint that we're trying to reach. This is the other device. Let's pretend our client here is trying to reach this server over here. That's the world's worst server. And my head is on top of it. Let's fix this. Let's just get rid of NOCs entirely. There we go. There, let's just redraw the server. So now, our client here, is trying to reach this server here.

1:43But this client is in building A, and this client is in building B. We know that what we're trying to do-- since this is all layer three routed infrastructure-- maybe with slash 31s, or slash 30s all over the place-- whatever you want to deploy-- that we can't just send in a broadcast frame, can we? Because this is where the broadcast domain ends right here for our customer. In fact, I'm changing the color up right here. So that when we see blue, we're talking about the traffic itself.

2:16So the customer's going to send in a broadcast frame, trying to figure out, hey, what's your Mac address over here Mr. Server? I need to reach you, because I know your IP address. Well, that's where it ends in a layer three infrastructure, because this is the default gateway. And that's where it goes. So we know that our default gateway device here is going to try and build a tunnel to get the frame over the infrastructure. And this device right here is called a VTEP-- a virtual tunnel endpoint.

2:47This is where a tunnel can start and stop. And we can have as many different tunnels as we want. This gets into the design talk that we're going to come up to next. So I'm not going to get too far into it. But the idea is that routers that could serve as an ingress or an egress for any broadcast domain is a VTEP. And I keep saying routers-- this is routers or switches. The Juniper platforms, the QFX series, the EX series, and the EMEK series, those are switches and routers.

3:17They all support VXLAN as a data plane technology. You can even run it on the VMX series or VQFX series devices-- got to write that x there. Right up. There we go. The VQFX series devices in your virtual lab, which is what you're going to see me do in an upcoming set of videos. So the VTEP is the endpoint that's going to be building the tunnel from one VTEP to the next. Now, the VTEPs come in different flavors. And we're going to talk-- we're not going to overwhelm you with information about the VTEPs at this point.

3:49We now need to start talking about how the data flows from one to the other. Because this is where it gets tricky. The customer sends in a frame-- or the end user sends in a frame-- and it's received on this interface. This interface is configured with a standard VLAN. What do we know about VLANs? Well, VLANs are 12 bits in length, which means they could be any number from 0 through 4,096 except for some VLANs are reserved. So we really only get 4,094 VLANs that we can work with.

4:21Well, let me go back to me for a second. In this day and age, they're simply not enough VLANs, especially in a data center. So one of the hugest benefits that VXLAN brings to the table, is the fact that VXLAN maps a VLAN to what they call a virtual network identifier, or a VNI. This is the second key term. We've got VTEPs and VNIs. And this is 24 bits in length, which means they can be 16-- it's actually closer to 17 million, but it's 16 million unique addresses.

4:56So now, we could have kind of overlapping VLANs if we want to, and just map it to a VNI. Now, this gets a little more complicated. So we're just going to focus right now on a basic VNI example. Let me go back to the full screen here. Since we now understand that a frame will come in on this interface, right here, which we've configured with VLAN 10, and we now know that that is mapped to VNI 16,010, which tells us who our peering tunnels interfaces are-- like so. It's now time for us to get this frame over to that customer.

5:30How does this work? What ends up happening is, we take the frame-- like the original-- we take the original frame, and we literally just encapsulate it inside of a new IP packet. VXLAN operates in layer four using UDP. We then determine that our next hop is this VTEP over here. So the destination will be the IP address-- really a loopback address-- of the VTEP. We'll just call this VTEP B-- and a source address of-- let's call this VTEP a.

6:06And we'll also shimmy a little header in here that identifies the VNI that this is operating on. So when we route the packet up to this device here, it's just looking at the destination IP address and making a forwarding decision to make its way down to VTEP B. When it arrives on VTEP B, it's going to arrive on the UDP port that VXLAN is listening to. So it knows, OK, well, I need to look in the VNI header to determine which VLAN this is really associated with. When it sees that there is a VNI of 16,010, it goes, oh, well, that's my VLAN 10 over here.

6:42So let me strip off all of this unnecessary . Stuff I've now got my original frame. And I know how to punt it out, because I've already learned about the Mac addresses of the server right here. This is how VXLAN works. And this is why we're introducing the key terms in this way. Really, at the end of the day, all you really need to know about VXLAN is that the two key terms are VTEPs and VNIs. But we also introduce some cool little tidbits-- some benefits-- about VXLAN that you may or may not have known.

7:13It uses UDP to transport traffic and over the layer three infrastructure. It also uses a 24-bit VNI to allow us to accept even more VLANs than we were originally configured for. So if I'm cleaning up the screen just a little bit, you're thinking to yourself, well, wait a minute, how does that really work? Well, if you think about cloud providers, like AWS or Azure for a moment, think about this. You go into Azure, and you spin up a new virtual machine.

7:44You're going to be the pink client here. And you want to use the private subnet of 10.0.0.0/24. Well, guess what? So does this customer over here-- 10.0.0.0/24. And maybe you even want to use the same VLAN. I mean, this may not be the best example ever, because you don't really have a lot of control over VLANs on a data center, or in a cloud data center. But this is the gist of it. On these interfaces here, you can create a virtual switch, which is like a VRF.

8:18And the same thing goes over here. We can create a virtual switch, which is like a VRF. So if I want to use this subnet and call this VLAN 10 in the pink, and we call this one VLAN 10 in the yellow, well, guess what? We have an overlapping VLAN and an overlapping subnet. And the real mess here is that we absolutely positively do not want our core to have to keep up with any of this.

8:49We just want a packet to come in, and we want it to get routed out. We don't want to have multiple routing tables and multiple switching tables for every single client that exists in the infrastructure on every single networking device. So the cool thing is, is now we can just assign this a VNI-- of make something up, like 16,011-- and the pink can get a VNI of something like 16,010. And now, our core devices can forward them the same way that they've always forwarded them from one destination to the next. And as long as the remote VTEP also supports 16,010 in addition to VNI of 16,011, boom.

9:27Guess what? We've now found a way to have overlapping VLANs and overlapping subnets. So this is the real benefit that VXLAN brings to the table, and this is why you see it in data centers, especially public cloud or private cloud data centers in today's environments. That way, the end users-- the customers who are renting the data center compute or the data center network-- they now have the flexibility and control over what subnets and VLANs they actually use in their infrastructure.

9:59So this has been the VXLAN key terms. I hope this has been informative for you, and I'd like to thank you for viewing.

0:06VXLAN is interesting, because it's almost always deployed the same way, whether it's deployed in an enterprise or a data center environment. What we're really starting to introduce now is the spine-leaf architecture, which you find out pretty quickly, in the enterprise terms, this looks almost identical to a collapsed core architecture. But now how does the traffic actually flow? How does the traffic enter the fabric? And how does it leave the fabric? What even is a fabric? That's what we're talking about in this video. Let's get going talking about how a spine-leaf architecture, and therefore VXLAN enterprise environments, would be laid out.

0:39I'll see you there. This is honestly the fun part, because this is where the rubber starts to meet the road. Oh, I forgot to put switch ports on these. So this is where you actually get to start seeing how VXLAN would actually get implemented in a real world topology, and why I laid my topology out in that lab environment in the way that I did. You notice I didn't draw the cabling here yet, because this is actually an important thing to how VXLAN works. And it depends on the style of VXLAN that you want to implement. Let me get rid of Knox for a second so we can focus on the screen.

1:11When we talk about VXLAN, you see I've written spine-leaf architecture on the screen. Doesn't it look an awful lot like collapsed core? Yeah, it kind of does. In collapsed core, when we're talking about we just moved the core down to our distribution layer. But an interesting thing is how the redundant connections take place in spine-leaf architecture. It looks like this. Our leaves are down here on the bottom tier. So I'll call this LEAF1, LEAF2, and LEAF3.

1:41And our spines are up here. So I'll call this SPINE1 and SPINE2. So our leaves connect to spines, like so. But leaves never connect to other leaves, and spines never connect to other spines. Whoa. This just kind of blew my mind a little bit. [INAUDIBLE] Alexa, stop. Sorry, Alexa interrupted me there for a second. So this is how it's going to look. And one of the cool things about this-- if I now start to draw hosts and servers in the mix here, one of the cool things about this is now to get anywhere at all in the data center-- if I write this in a different color, I am one hop, two hops away.

2:27The response traffic is one hop and two hops away. If there's a host over here, and they're trying to reach this blue server over here, they're one hop here and one hop here away. That's right. The cool thing about this spine-leaf architecture is, no matter what, everything is laid out as either a spine or a leaf. Therefore, we can get to anywhere with two hops away. So you may be thinking to yourself, well, wait a minute.

2:59What happens if I run out of switch ports on the leaves? Well, guess what you can do? You could just add more leaves, and just draw them up like so, just to connect them into your spines. And you're like, well, wait a minute. What if I run out of switch ports on my spines? Well, just addd more spines, just like that. And then you start even getting into aggregation or high availability configurations, where you can actually do virtual chassis, and bundle these spines together, or the same thing with the leaves. So that way, you've got these massive chassis that have hundreds upon hundreds of switch ports available to you.

3:33And now you can just keep just adding more, and more, and more, and more, and more, all you want. And everything still remains two hops away. Look, I haven't even been using this space. I could do it like this, right? Look, it kind of throws you off when you see a leaf tier added up here. But look, I'm still only two hops away from every destination in the data center. That's wild, right? Well, that's the cool thing about the spine-leaf architecture, is how scalable it is. If we just need to add more leaves, we just add more leaves. If we need to add more spines, we just add more spines.

4:05And everything still remains only two hops away. But in the typical deployment-- here, let me clean up the screen, because I just drew a whole lot there. Let me just get rid of a lot of this mess here for a second. I'll put these links back, like so. The thing about this is how the actual traffic typically flows in a data center. Typically, what we do is we configure each one of these leaves to be the VTEP-- oh, got to write better, VTEP. But the spines also know about VXLAN and can also help serving with VTEP technologies.

4:39And why? We're going to get to that in an upcoming video. That gets its own dedicated thing. The interesting thing about this is our spines are really only focused on switching. They just want to get traffic in and out as much as possible. They don't necessarily focus on the forwarding table. And we want a tunnel to exist, like so, and another tunnel to exist, like so. Kind of a full mesh of VTEPs, so to speak. So when a frame comes in on this VTEP, LEAF1, it's going to have to consult its forwarding table and look at the destination MAC address, and determine, oh, that needs to go over here to LEAF3.

5:20So let me encapsulate it in a packet so that my spine layer can get rid of it as quickly as possible. The interesting thing about this design is the brains of the operation really belongs on the leaf tier, which you kind of associate with the access tier typically, don't you? It's true. That's kind of how we want a spine-leaf architecture to typically be deployed, like so. So in this case, our core devices or our distribution tier-- really, our spine tier,-- is just moving. It's just moving data. It's just moving data as quickly as it can, without actually having to focus on, well, what tunnel does that belong in? and how does it-- does it need to go to that VTEP? and which VNI-- nope, it's just, what's the destination IP?

5:58I'm punting it in that direction. That's the idea with the spine-leaf architecture, is we move the brains down to these leaves. We move the brains down to these leaves in such a way that-- pretend for a moment that we are a large campus, and this whole design right here is our enterprise, is our data center. And the rest of the enterprise, like the campus, connects in through our leaves. Yeah, that's right. Where people are roaming around connecting to Wi-Fi, and doing all of those things, yeah, they're connecting into our leaves.

6:30And maybe we have our network services, like our DHCP, and our NTP, or DNS-- maybe that's on a leaf up here. So our network services can still get out of the data center by being switched through two hops only. They know that, OK, well, if I need to get out, I need to get to this VTEP right here who can send me out to the rest of the campus. So in this architecture, this design is actually called the spine-leaf architecture. There is an alternative design-- one that you will actually cover first when it comes time to configure VXLAN-- and that is a spine-only architecture.

7:07Here, let me draw the switches back and clean up the screen just a little bit. In a spine-only architecture, what's going on here is these devices, our leaves, are literally just trunking their data up to our spine layer. And the spine layer serves as a VTEP. In this situation, we actually do link our two spines together. This is the exception to the rule in the spine leaf architecture, is here, when we want our spines to be the VTEPs and only the VTEPs, then in this case, we link these two together, and they will share MAC addresses back and forth.

7:43Now what's the reason for this? This Is when we start to get into the difference between a layer 2 gateway and a layer 3 gateway. And that's why we have a dedicated video coming up, and we'll talk about why the spine-only architecture may work in that particular scenario. Know right now that the most common deployment is the spine-leaf design, where these leaves are the VTEPs that are doing the brains of the operation. They're the ones who are building the tunnels in between each other and then sending the data throughout two hops away only. So this has been understanding the design of the spine-leaf architecture, and how VTEPs and VNIs will now all of a sudden start to work when we actually deploy it this way.

8:20I hope this has been informative for you, and I'd like to thank you for viewing.

0:06So now comes the part where, honestly, when I was first studying networking, when I was getting into it, this is the part that I used to dread, when I actually had to look at what a packet contained, what was in the header. What we're going to do in this video is we're actually going to take a closer look at what happens actually with VXLAN. Let's actually look at what one of the packets looks like. Let's inspect it. And trust me, the more you get into these advanced technologies, the more that this information will benefit you. This is where you start to truly master what a protocol does and how traffic is supposed to flow throughout the topology.

0:40So let's take a closer look at a VXLAN packet. So sometimes, it helps to actually see it in action. So let's talk about how a frame could go from my customer piece of equipment here, their computer, destined remotely to this server over here. Of course, we see that they're separated by a layer 3 domain. There are /31s everywhere. So how does this work? So at this point, what we're going to do is we're going to say that this computer right here and this server right here, their default gateways are these switches.

1:11And more so, these are VTEPs. So we're going to say that this is VLAN 10, for simplicity's sake over here. VLAN 10. Write a better V. There we go, VLAN 10. And we're trying to get VLAN 10 traffic to come in on one of these interfaces and go out one of these interfaces and reverse the same scenario. We got to have return traffic coming back, too. So we enable VXLAN, and we're going to use EVPN as our control plane. So when we turn on EVPN, and we configure that this computer, its default gateway is going to be this VTEP.

1:46Let's call this leaf-1 and let's call this leaf-2. When our computer right here sees that its default gateway is leaf-1 for VLAN 10, it's going to ARP to find out its default gateway's MAC address, right? That's what it's going to do. And upon receiving that MAC address, leaf-1 is going to learn-- it's going to behave just like a switch has always done. When a new MAC address comes in on an interface, we're going to inspect that source MAC address, and install it into our Ethernet switching table, just like we've always done. But this also triggers EVPN to do what EVPN does.

2:20We've now learned about a MAC address on a specific VLAN. We need to let the other devices know what that MAC address is. The interesting thing is we've got the exact same configuration and thing taking place over here. When our server ARPs for its default gateway, leaf-2, leaf-2 is going to learn about that MAC address and advertise it back over to leaf-1. So now comes the time for our customer to ping the server. Let's skip a step. I know that the first ping, we're going to ARP for the MAC address of these server.

2:51Let's take BUM traffic out of the mix right now. We don't need to worry about Broadcast, Unknown Unicast, or Multicast address. Let's just pretend that since these leaves now know each other's remote MAC addresses, as well as their local MAC addresses, now let's say our customer goes to reach the server. And it sees, OK, well, this is on my local subnet, because my original packet is going to be sourced from 10.0.0.5. Write the source IP a little bit more like this. And it's going to be destined for 10.0.0.10.

3:24So since we know that we're on the same subnet, we're going to build a frame. So the computer builds a frame with a source MAC of, let's just write, A:A:A for simplicity's sake. And a destination MAC of B:B:B. And it's time to just send it up our switch port the way we've always done for VLAN 10. The frame arrives on the switch port, and leaf-1 goes, hold up. This is destined for B:B:B, and my switching table tells me that this is actually destined for the remote VTEP of leaf-2.

3:59And because I learned that remote MAC address over EVPN, I know that this is associated with a VNI. Maybe that VNI is something like 16010. Let's just reuse the same one. So what we're going to do is we're going to take this original frame right here, and we're going to encapsulate it inside of our own VXLAN packet. So we're going to have some layer 4 info. We know that this is going to be destined to a remote UDP port. The destination IP address is going to be leaf-2's loopback.

4:31Here, let me clean up this space right here, since we know the MAC addresses at this point. The source IP address is going to be leaf-1's loopback. We're going to shimmy in our VNI info. And then we're going to send this through the data-- we're going to send this through the architecture, through the fabric, like we've always done. So the next hop for this destination IP address will be our next hop, which may be this spine switch here or this spine switch here. So we set the destination MAC address now to be whatever the spine is, and the source MAC will be our MAC address.

5:04So the packet gets routed over to a spine, which then routes it down towards this VTEP. We're going to receive this info, this data, on our UDP port that VXLAN listens to. So that triggers us to take a look at the VNI that says 16010. And we now know that this belongs-- 16010, the VNI, maps directly to this VLAN that this server is on. So at that point, that VTEP removes all of the outer information and is left with the original frame, which it can then send outbound, like so.

5:40At the end of the day, it's not that complicated. It's really just taking a frame and encapsulating a packet. Then the packet gets routed the way it always does until it reaches its final destination, which then de-encapsulates-- just strips off that outer packet, and now we're left with the inner packet or the original frame that we can send out to the original broadcast domain that it was destined to reach. So this is the packet walk. This is understanding how data is going to flow throughout a VXLAN topology when we're using the spine architecture.

6:12I hope this has been informative for you, and I'd like to thank you for viewing.

0:05So we know that this entire set of videos, the ones that we're about to go through, are called EVPN VXLAN, and I've hinted at it a little bit up till this point, that the control plane in an EVPN VXLAN is EVPN. And really under the hood, that's just BGP. But that begs the question, is EV-- since EVPN and VXLAN are truly decoupled from each other-- VXLAN is just depending on a control plane-- does EVPN have to be the control plane for VXLAN? No, it doesn't. There are other options that you can use.

0:37In fact, the original RFC doesn't specify anything about EVPN at all. What does it specify? PIM. It specifies multicast. Now, when we dig into some of these other options, you'll find out pretty quick, EVPN is definitely the way to go, albeit, it is very complicated, and that's why it gets its own set of videos. So let's going talking about the other control plane options that are available to you when you deploy VXLAN. So there's no getting away from talking about the control plane options with VXLAN, even though we know we're pretty much going to stick to EVPN.

1:08But let's take a moment to just recap some of our options when it comes to choosing how VXLAN will be smart enough to determine what the next hop is, where it can find MAC addresses that live off of remote devices separated by a Layer 3 domain. We already know the benefits, but now we're talking about the hows. So our first up, yeah, we're going to talk about EVPN. Here's the real thing that you may not have realized about BGP. BGP can share really all sorts of information.

1:38It can share, of course, routes and prefixes at the IP level at Layer 3. But it can also share other information. It can carry basically any info. It can carry info for multicast. It can carry info for OSPF. It can carry info for EIGRP, even though this is a Juniper course. It can carry firewall policies. That's what BGP flowspec is. And in this case, BGP can actually advertise MAC address info and some interesting ways that I'm just going to say this on a high level. It can advertise the topology design.

2:11That way you can actually help and prevent things like route loops or switch loops when we have an environment like this. I mean if there were no spanning tree in this environment, look, we could go here, here, here, here, here, here, here, here, here, here, here, here. See how there's a switch loop that's possible here? And this is all one direction. If a broadcast starts heading in this direction, it would switch around-- it would loop around, just like we just did. But if a broadcast started in the opposite direction, it could go like this. And if two broadcasts started on either side, you can [INAUDIBLE] in a whole bunch.

2:42It could-- we could have two loops going in two different directions. And the cool thing about EVPN is even though these are all Layer 3 links, it's still going to behave a lot like a Layer 2 topology. The core, as far as our customer's going to see it, as far as these devices down here and the server that lives over here, as far as they're going to see it, they're just going to see this is one gigantic switch. That's how they're going to see all of these core networks that they're communicating to. So when it's just one gigantic switch and it kind of behaves like one gigantic switch, the whole idea, now BGP can actually carry attributes and advertisements that help to prevent routing loops, which is so fascinating.

3:23But the other thing to keep in mind about EVPN was what I just said, is it behaves like a Layer 2 switch. As frames come inbound on this particular device, this device is going to learn the source MAC address and build a MAC forwarding table. Then it forwards that info to the rest of the devices in the topology. So the MAC address and the bridge ID learning behavior is exactly the same, which I think is so, so cool, even though that this is all routers. This is all Layer 3 topology. Now, of course, in data centers and enterprises, it's going to be switches.

3:56But when you get into the service provider world these are MX Series routers. At the end of the day, VXLAN is VXLAN, irregardless of which platform you're working on. So you need to know that first of all, EVPN is going to be the preferred way that gets deployed here. And really at the end of the day is, the question becomes, why? And it's because BGP is so scalable and so flexible. With BGP, we can use things like route reflectors. That way, when we learn a MAC address, we can send it to a route reflector who then bounces it to all of the other VTEPs in our entire environment.

4:29And we can carry additional attributes. One of the other cool things that comes up in EVPN, especially in the service provider world, is you not only can run a Layer 2 VPN like this on this infrastructure, you can also run a Layer 3 VPN at the same time using the same protocols in infrastructure. This makes it super, super scalable, because if we add a switch into the mix up here, a new leaf off of this joint, but it doesn't have the capabilities of running VXLAN, we can still send it /32 addresses using Layer 3 VPN.

5:04So when we learn about our locally connected device's MAC address, at the same time, we also ARP for it and learn about their IP address too. And if we run a Layer 3 VPN alongside our Layer 2 VPN with VXLAN, we can actually share the /32 learn prefixes throughout the entire Layer 3 VPN so that each one of our leaves, even if they don't use VXLAN, they still know exactly which VTEP they need to get to in order to send the traffic outbound. So VXLAN, because it's using BGP, can really do everything whenever we couple it with an EVPN control plane.

5:40So that's the first type of one that you should know about. And that's really-- I don't know many VXLAN environments that don't run EVPN now. But the thing is, is it wasn't originally-- VXLAN wasn't originally designed to use EVPN. No, it was designed to use-- uh-oh, got rid of one of my links. It was designed to use PIM, and it didn't really need a massive control plane in order to do that. So when we learned about our customer device and we learned their MAC address, what we ended up doing is we used PIM to send a multicast packet out into the environment that's specifically consumed by VXLAN.

6:19And as long as all of these VTEPs were participating in the same PIM tree, then they would receive the same multicast advertisement of a new MAC address. And this is how the RFC originally defined it to be. However, this is not as scalable, because it now has to use multicast in order to reach all of the potential destinations in a spine-leaf environment. And with the spine leaf topology, it's pretty much going to go everywhere, because that's how a data center's going to work anyway. BGP at least gives us the option to use things like route reflectors, or even some advanced BGP properties, like inspecting the advertisements and who would be interested in receiving an advertisement by inspecting things like the VRF targets.

6:58That's that target inspection, which is so, so cool. Now of course, there's one other option that you should know about, and I don't know why anybody would ever use it. But this is an actual static mapping. This is where we explicitly say, if you receive a frame that has a destination MAC address that looks like this, then you must send it over to this VTEP using this specific VNI. This is where you have to manually configure every single MAC address to every single VNI to every single VTEP. And the big problem with this is not so much that it's the manual configuration, it's the fact that we lose mobility.

7:31This is another huge perk to VXLAN that we haven't talked about up till this point. Whenever we have-- well, let's just start and let's redraw it. Whenever we have this computer here-- let's say this is host A, and let's say host A is actually a laptop. If I were to be sitting at host A and I unplug the computer and I migrate my way all the way over to a new building and I sit down and I plug into the wall, well, guess what? I just plugged into this computer. What's going on here? When we use something like EVPN-- oh, I'm writing on top of writing here.

8:01When we use something like EVPN, BGP will automatically handle the advertising of the MAC address from a new host, and the previously known host will also send out a withdrawal message. Now, this is getting into the EVPN behaviors, and that's what we're going to talk about a lot more in the next set of videos. But right now, I'm just highlighting the benefits of using a protocol like EVPN as opposed to manually setting these configurations, which now when we do things like static, we lose the ability to have MAC mobility, meaning MAC addresses are mobile throughout the topology, and we don't have to worry about updating tables, because they'll just discover it and repopulate new tables all the time.

8:39If you think about this in the concept of a data center, one of the biggest things about a data center is a virtual machine that lives on a server and is tied to a specific VLAN can migrate throughout the data center all day long. It's the idea of a data center is to evenly distribute our load by migrating VM. But when we do that, we're going to be moving those MAC addresses at the same time. And thanks to EVPN, we can now advertise whenever the MAC address moves, and that way, all of my devices maintain connectivity that way.

9:10So these are your control plane options when it comes to VXLAN. Clearly, EVPN is the winner, but you should know that PIM has been used, and was used, and [INAUDIBLE] RFC as a perfectly reasonable option for you whenever you want to deploy PIM as your control plane for VXLAN. That being said, we're highly focused on EVPN VXLAN, because this was the most modern deployment, the most scalable, and the most stable. So that's been understanding your VXLAN control plane options. I hope this has been informative for you, and I'd like to thank you for viewing.

0:05When you deploy your VTEPs in a VXLAN environment, you kind of have an option. They're either going to be a layer 2 gateway, or they can be a layer 2 and layer 3 gateway. What is this all about? This basically works the exact same way that routing used to work before. But now our layer 3 gateway, serving as a default gateway to any of our hosts, can act basically as a router. However, the interesting thing about it is it can route traffic outside of the network, or outside of the fabric, or it can route traffic within the fabric itself.

0:36Another way to put it is we can route traffic that goes from one VNI to a separate VNI. Let's get going taking a closer look about how this really works with layer 2 and layer 3 gateways. I'll see you there. I love, love, love, this topic, because you're oftentimes so focused on VXLAN that you forget about the basics. Think about it. Up until this point, we've talked a lot about how a frame coming from this device-- let me clear my head-- from this device here can make its way over this layer 3 "backbrone"-- backbone, I should say.

1:07Excuse me-- over to this server, and they can have direct communication. It was all about building that tunnel between our VTEPs, and then how each EVPN can exchange MAC address prefixes. But here's the kicker. We know that this is all made really possible because this host here sees this router as its default gateway. And this server here sees this router as its default gateway. And they want to communicate directly. When that computer wants to communicate directly to the server, these routers will look at the frame as it comes inbound, and then make a forwarding decision, oh, that this needs to go over the VTEP tunnel.

1:42Well, that's great and all. But what happens when this computer, say, pings 8.8.8.8? Well, hang on a second, that's a different scenario. This device down here is still behaving like this router down here is a default gateway at the end of the day. And this is where it gets kind of interesting. These devices have a switched virtual interface, kind of like you always see on switches, where you configure a VLAN, then you configure an IP address on that VLAN so that the switch can service that particular VLAN.

2:15And specifically in Juniper devices, this is the internal routing and bridging interface. And then, of course, you have subunits, like 0, 512, whatever you want. And then you can configure it to have IP addresses, like so. The interesting thing about this is this is still operating in the context of VXLAN. We're still making forwarding decisions of VXLAN. So the next question becomes, well, is this frame destined to a different VNI, or is it destined to kind of a default route?

2:48In the case of 8.8.8.8, we know that this is going to be destined to a default route. So we need to get it off of our fabric, out of our VXLAN fabric, and over towards something like a firewall that's probably going to perform NAT or at least inspect the traffic before it goes outbound. So up here, we may have a VTEP that's connected towards a firewall out towards the internet. So we may still encapsulate this frame and send it over towards the next hop, which is going to be this VTEP, who de-encapsulates it, and then decides, ah, I need to forward this on towards the internet, like so.

3:25Or I think the more interesting use case is when we actually want to communicate to a different VNI. For instance, maybe we have a server over here. Very often, you may see something like a DNS server that's not on the same subnet as our clients, right? So if the host is trying to perform a DNS lookup, it will have its source IP address and a destination IP of the DNS server. And of course, the source MAC will be its MAC, and the destination MAC will be the MAC address of the IRB interface.

3:57So when this switch or router receives the frame on its IRB interface, and it sees, oh, I need to get this over to a DNS server-- make up something like 10.1.1.99. I don't know. It now knows that this is going to be destined towards a different subnet or a different VLAN. Therefore, we need to look up a new VNI that this needs to communicate in. So it takes the original frame, but changes the VNI. Instead of this local VNI, we're going to put in the new VNI that's going to be destined for this DNS server over here.

4:31That VNI says we're going to send it over towards this VTEP, but this VTEP knows that when it de-encapsulates it, that it's going to exist on the blue subnet. So the DNS server can respond to this query like it always has, sending it back to its default gateway, where the return process takes place. And this is what's pretty cool about it. When VXLAN behaves the way it always behaves, when we're just allowing communication within the same VNI, these devices, these VTEPs, are considered layer 2 gateways. They're all considered layer 2 gateway. However, when there's routing involved, these are configured as layer 3 gateways.

5:05There's really not a lot of extra configuration. We just tell it where the IRB interface lives, and what VNI and VLAN it's associated with. The question then becomes in an enterprise environment-- and this is getting a little outside the scope of this course. But we're just going to talk about it for a quick second. The question then becomes, well, do you really want to use the spine-leaf architecture, where each one of these devices becomes a layer 3 gateway? Or would you rather use the spine-only architecture, where we trunk everything up to these core devices, and they serve as the layer 3 gateway?

5:39And I think one of the other cool things that you need to consider about this is when you've got MAC mobility. Remember the scenario where this device can migrate to a different site. Well, what happens when it does, and this device didn't have the exact same IP address? That means it was actually configured incorrectly. What you want to do is you want to make sure all of your IRB interfaces for the same VLAN-- say VLAN 512, which is going to be servicing VNI 16512-- you want to make sure they all have the same IP address, and if you can pull it off, they all have the same MAC address, too.

6:15That way, when my computer migrates, it's got the exact same default gateway that it had before, the same IP address, and the same MAC address, so it doesn't even have to ARP for the new MAC address when we migrate. It's a beautiful thing, and that's what makes virtual machine mobility so powerful in a data center environment, is the fact that it doesn't actually have to waste any frames at all when it migrates just to find out who its default gateway is. So that's why we configure an anycast gateway on all of our VTEPs, and we also configure it to have the same MAC address, too.

6:46So consider for a moment that the layer 2 gateway does basic VXLAN functionality of tunneling a frame from one end to the other within the same VNI. But then we also talk about configuring the layer 3 gateway. That way, we can also route our customers' or end users' traffic outside of the VNI, which is going to be a very common thing to do. When we need to reach network services, or specified servers, or the internet, or any other parts of the campus. We're going to have to have these layer 3 gateways done in time. So yeah, you can absolutely go through the configuration and configure VXLAN without layer 3, and you would have communication on the same subnet.

7:22But you really want to do a layer 3 gateway, too. That way, these devices can still have routeability outside of their own subnet and outside of their own VNI. So this is how gateways work within VXLAN. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] So now, we fundamentally understand what VXLAN brings to the table. It is a tunneling technology that is just a data plane. It relies on a separate control plane, which we have options for, but it's most likely going to be EVPN, in order to make forwarding decisions. We now understand the key terms like VNIs and VTEPs. And when we see it in action, when we actually just think about it conceptually, it's not that bad. We just encapsulate a frame inside of a packet, look up in the routing table where it's supposed to go, we send it there.

0:33That's it. That's how VXLAN works. So now that we understand the simpler part of an EVPN VXLAN deployment, it's time to roll up our sleeves and dig deep into how EVPN actually transmits forwarding decisions and populates routing tables full of MAC addresses. In the next set of videos, I'll see you there as we talk about EVPN. In the meantime, that's been VXLAN. I hope this has been informative for you, and I'd like to thank you for viewing.