Understanding VXLAN

0:01Welcome to the content on understanding VXLAN. Right here marks one of the biggest shifts from the old versions of Juniper certification exams to the new ones. Previously, in the last iterations of Juniper certification exams, you didn't even get a data center exam until you got to the professional level. The prerequisites were to go through JNCIA and then JNCIS Enterprise. So 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. So they're easing you into this very big topic. So 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. With JNCIA, we talk at a very high level about what EVPN VXLAN does.

1:03In JNCIS, we then start to break it apart. We talk about what EVPN is and what VXLAN is. But we still don't do any configurations because they're really, really big topics. And it's really important that we just understand what each of these protocols do and what the key terms are. So that's where we are now. In 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. It's not our control plane. It's our data plane. So we're going to introduce the key concepts to what VXLAN does, how it does it, and most importantly, what the key terms are. Of course, there's some alphabet soup in here that's specific to VXLAN. So it's really important that we understand things like the VTUPS and the VNI's. So 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 and answering some of the bigger questions that we have. So we know just from what we learned in the JNCIS DC a couple things about data centers. One of the big things is that it has a spine leaf architecture. This is very different from the enterprise environment, isn't it? Because the enterprise environment, you see core distribution access, three tiers of network infrastructure to move traffic across an enterprise. But in the data center, we only have two tiers, the spine and leaf architecture. We also know that there is something that makes the spine leaf architecture really special, and that is the EVPN VXLAN fabric. And you also know, just 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 answering in this video is why. Now, we already know a little bit again that a lot of traffic in a data center moves east to west. We talked again about this in the JNCIS DC. But let's start to answer some of the bigger questions of why. Why don't we use trunk ports across our switching infrastructure 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 up here, then it can go something like down here, then it can go up here, then it can make its way back down here. What do we have in this? That's a loop. Knowing that this, if these were layer two links, and this was trunk ports everywhere, and 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. What does spanning tree protocol do? It detects this loop, and importantly, it blocks one of these links. That's fine for an enterprise environment. We still have redundant paths. Spanning tree protocol converges relatively quickly. If a link goes down, it can reconverge and 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, we effectively cut off 50% of all of our links, effectively, roughly 50% of all of our links, potential links in a data center. That means we lose 50% of our possible throughput. The big thing about a data center is throughput. We have a huge amount of traffic, I mean, a massive amount of traffic moving east to west through our data center. We spend a lot of money on 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. Now, all of a sudden, it's not just our infrastructure servicing our apps, and we're losing 50% of our traffic. It is our customer's throughput that we lose when we use 50% of our traffic. That's a big deal. That's a big problem, and they have a certain expectation of having highly performant, also highly available resources with them. Think about this again. For every resource, like storage resource or platform as a service resource that a customer deploys, there's probably at least one copy of it living somewhere else within our infrastructure. So, it's not just they deploy one application that consumes one resource and a certain amount of bandwidth. It's actually more than that, because 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. Instead, we solve this problem by putting slash 31 prefixes for each one of these links, making them routable. Then, we begin building our fabric with an underlay, which is really just an IGP. Lots of times, it's OSPF. Sometimes, it's ISIS. Very rarely, will you see something like IBGP in the mix right there, because we're really going to use IBGP in our overlay. So, I'm going to tell you right now, you're pretty much always going to see OSPF, maybe 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 when we deploy slash 31s on each one of these links right here, and then we deploy OSPF, assuming all of these links are the same bandwidth, same fiber, or whatever, you will end up with equal cost multipathing, meaning that OSPF can safely send traffic over both links instead of just one. And then, we actually expand our potential bandwidth and throughput that way. That's kind of the beautiful thing about link state databases and link state protocols. They understand every possible link in every possible route to get from point A to point Z. And because they're routed interfaces instead of switched interfaces, there's really not a potential for a loop to occur here. Using things like bidirectional forwarding detection in conjunction 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, we've solved the problem of reducing our bandwidth by using spanning tree protocol. Now, every link is a possible path to use, and because these things have built in equal cost multipathing, we actually get load balancing across all possible links. Yay. But this sets up the next problem, which is what VXLAN and EVPN seek to solve. These servers right here are really, really powerful servers in the modern data center, right? And they're not just running, or they're typically, typically not just running one application. Usually, there's something like virtual machines that run here. Perhaps this is a cluster of web servers that has a load balancer in front of them. Well, across the data center, we'll have more servers right here. And maybe this one only has one little virtual machine running on it. So, when I look at this server right here, and it's got its five VMs, maybe, just maybe, it's pegged out. Maybe it has 95% CPU 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 constant communication about, you know, their current workloads and health to each other. So, this server right here says, hey, I'm kind of maxed out over here. You're sitting kind of idle. Can you take some of my workload? And these virtual machines, some of them make their way over 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 slash 24. Now that they've migrated over here, they expect to still be on the same VLAN, 192.168.10.whatever, so that they can communicate directly to each other. But that's the problem, isn't it? When this VM, let's say that's 192.168.10.11, wants to communicate to this VM over here, let's call it .9, what happens? Well, they think they're on the same VLAN, so it builds a frame, it sends a frame up here, and that's where it dies, right? Because these are Layer 3 interfaces. If this were a frame, you know, going over Layer 2 interfaces, over switched interfaces, we could just trunk it across the network. But again, that would reduce our 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 back down to this server. How do we do that? That is what VXLAN does. VXLAN is a data plane protocol. It's not a brains protocol, so to speak. It's not a thinking protocol. It doesn't know for sure, it can't figure out for sure how to get it over there, but it knows that it has a technology to get it over there. So what VXLAN will do, in conjunction with a control plane that we're going to talk about later, is it will say, okay, I've got this frame that needs to get over here to the server. So what I'm going to do is I'm going to build a logical tunnel between these endpoints like this, and we're going to take that frame from 192.168.10.11, and 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 this switch, and this endpoint will de-encapsulate it and then send the frame down to its destination. So because it's inside of a packet, the packet can be routed through the infrastructure from one tunnel endpoint to the other tunnel endpoint, and the VXLAN technology knows, oh, 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. Now, this is oversimplified yet again. We understand the why. Why do we need 31s in our data center? We also understand why we need spine leaf. Everything is two hops away in the entire data center. Two hops away. Not three, not four, not five. Goes up to the spine, down to the leaf. That's it. So we can tunnel a frame no more than two hops away from one endpoint to the other, and because we're using equal cost multipathing, we 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. We haven't talked about EVPN, which is the control plane, and we have a lot more to talk about VXLAN, but now hopefully that little light bulb is flickering, and we'll move on to the next video where we elaborate more on how VXLAN does what it does.

0:00Now to be clear, this is not the content on EVPN. You've got a lot more content on EVPN coming up, but I feel strongly that you've really only been given half the picture. We kind of start to understand why VXLAN matters at this point. VXLAN is the technology that can build a tunnel from point A to point Z in our network and then tunnel frames through it. But what VXLAN can't do, what VXLAN doesn't do, is it doesn't learn MAC addresses.

0:35That's the weird part, right? Because when I think about this frame right here, trying to get to this VM over here, it's going to build a frame and send it into the switch. What does the switch do? When a frame arrives on a switch port, it builds a MAC address table. And it knows, okay, if I receive a frame destined to this MAC address, I need to send it out this switch port right there.

1:07And then, likewise, as frames come in on a certain interface, it says, oh, I saw this frame come in on a certain interface, so if I see a frame destined for that, I need to send it over here. Well, that's the problem because frames are not going to arrive from this VM over here to this switch naturally, right? So how would VXLAN know to tunnel a frame from here to over there? That's what EVPN does.

1:38EVPN is our control plane. Basically, it's the part that learns MAC addresses. It's what builds the MAC address table. Now, I know it seems scary because it says EVPN, but EVPN is really just IBGP. What happens under the hood is we'll run IBGP on our leaves and build neighbor relationships between our leaves like so. And what EVPN, which is really, again, IBGP does, is when a frame comes into this switch and it learns the frames, like, oh, it's off of this switch port right here, it then uses IBGP to advertise to its peers, hey, I now know this MAC address came in off of me.

2:33So if you need to send a frame to me, go ahead and send it. If you need to send a frame to this MAC address, go ahead and tunnel it to me. So now, because we're advertising all the learned MAC addresses throughout the data center, we can then use VXLAN to tunnel them from one point to the other. The cool thing about this then becomes is, let's hang on, let's draw this right here, a new server. This virtual machine right here can migrate over here, send in a new frame, and then this switch will say, hey, I've just received a new frame over here.

3:17So now this VM lives here. If you need to send a frame to this VM, you can now tunnel it to me. Then VXLAN will build a tunnel there and then ship frames over it that way. Hopefully this illustrates how EVPN is the control plane, where it advertises learned MAC addresses to IBGP peers. And then VXLAN is the piece that actually builds the tunnel from one peer to the next, and then tunnels frames over it.

3:47That's how the two work in conjunction. It is important to understand that these are separate protocols. In fact, in other environments, you don't even have to use IBGP. You can use LISP. You can use PIM. There's all sorts of control plane protocols that can track the locations of certain things. In the data center, we use EVPN, and we'll explain why we use EVPN and IBGP when we get to that content.

4:21Right now, I just want you to understand why control plane and data plane are separated, but 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 looking at the JNCIS DC exam outline, it's pretty much the thing that they want you to take away from this section are these two key terms, VTEPs and VNIs. What are they? That's what we're going to talk about right here. Let's start with VTEPs. That is Virtual Tunnel Endpoint. Now, what does that really do? This is really the tunnel IP address when we build a tunnel from one switch to the next. If we were building a tunnel like this, this would be the VTEP IP here and 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 and the loopback address here of 2222, these VTEP IP addresses, really the loopback addresses, are going to be advertised by the underlay, ISIS and OSPF. And that's how we get equal cost multipathing from one tunnel endpoint to the next. So, now we know when a frame comes in and 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 of tunnel endpoints. Like, so that's, got to miss my circle there. There we go. You almost always end up with a full mesh of VTEP endpoints. So, we're really talking about a full mesh of loopback to loopback communications. Now, these are usually dynamically created whenever the control plane says we need to establish communication for, you know, VXLAN tunneling, tunneling the frames back and forth. But like I said, you almost always end up with a full mesh of connectivity because at some point, you know, a tenant's virtual machine, you know, you might have green tenant and pink tenant down here. And you might have yellow tenant and green tenant over here. And then blue tenant and green tenant over here. Still, at some point, you're going to have VM to VM communication from one switch to the next. So, the first key term 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. This is where it gets a little more complicated, but you'll also probably walk away going, oh, that's how it works. Pretend for a moment you are AWS. AWS rents out virtual machines. They are EC2 instances is what they're called. Elastic Cloud Compute, that's what it's short for. It'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 tenant spins up their own EC2 instance, which means they spin up their own virtual network. In AWS, they call those VPCs. In Azure, they call them, you know, VNets or virtual networks. It's really just a VLAN from your perspective. And they say, you know, I want to use the subnet 192.168.10.0.24. And, you know, under the hood, we might call 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 account. They spin up their own EC2 instance, which then spins up its own VPC. And they say, I want to use 192.168.10.0.24. This is something that is possible right now. Many tenants have overlapping subnets. So, without understanding how this is actually working right now, what would happen if the pink tenant here sends in a frame, you know, 192.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, 192.168.10.0 location. And right now we're thinking, okay, that was VLAN 10, but, uh-oh, we've got overlapping subnets right here. How does it know to segment that traffic out to the blue tenant? Well, one of the cool things that happens, well, so let's solve this for a problem. When you're a network engineer right now, you're thinking, okay, well, we could stop them from using overlapping subnets. They would have to use a different subnet and a different VLAN. Well, the problem with that is there are 4,094 usable VLANs. Chances are you're going to use some of them for your own network, you know, behind the scenes. So, you know, scratch out some of those. That means, you know, let's just make up something. Let's say you use 10 VLANs. That would 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 center. At the end of the day, a VLAN is just a 12-bit, you know, array of numbers right there. And it severely limits the amount of customers and therefore subnets you can have. So what VXLAN did is it introduced the Virtual Network Identifier, or VNI. This is a 24-bit number that 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 a VNI, let's say 65,535 or something like that. So when it learns a MAC address in on the switch and advertises it to all of its peers, like so, it will say, I've learned this MAC address and it belongs to VNI 65,535. And since they've got a customer down here, they also know about VNI 65,535. So when a frame now comes in and goes over the tunnel to its peering switch, it will see, oh, I've got this frame that came in and belongs to VNI 65,535. I'll de-encapsulate that 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 you a VNI of 131,119. And when it advertises its MAC addresses, boop, boop, it says, I learned this MAC address in VNI 131,119. So now when frames get tunneled over the tunnel, the frame will be included with a VNI that it belongs to. So that when it gets de-encapsulated, it'll go straight out to that tenant's network instead of all the other networks. That way the tenant can use whatever subnet and VLAN they want because it's segmented by a VNI. The VTEP is what allows switch-to-switch communication over a tunnel. The VNI is what allows multi-tenancy, such 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 with VXLAN is gateways. When it comes to VXLAN, there are two gateways that exist. They are Layer 2 gateways and Layer 3 gateways. The first one, the Layer 2 gateway, probably the easiest to understand because it's really the entire point of VXLAN. Let's say this, we've got right down here, our Teal client is VLAN 20, which is VNI 4920. When this client plugs into the switch, we learn a MAC address.

0:32What does this switch do? We know just from our very cursory experience, EVPN is going to advertise that MAC address. Hang on, let me undo that line right there. It's gonna advertise that MAC address to its peers. Like we see over here, the Teal server has, the Teal client has a server over here. It'll say, I know about this MAC address right here that belongs to VNI 4920.

1:03So if you have any client or any traffic destined to that MAC address, you can send it to me. Likewise, if you learn about any MAC addresses on VNI 4920, I would like to know about it too. I would like to subscribe to your VNI 4920 updates. That you get. This makes it a layer two gateway because now we have the ability to tunnel frames from one end of the data center to the other end of the data center for traffic that belongs to VNI 4920.

1:42Now, the question then becomes, okay, that's great. We understand this concept with VXLAN. It's all about moving frames east to west over layer three links so that we can have layer two communication anywhere in the data center. Great, right? What happens when we're not having layer two communication? What happens when we're having layer three communication? Let me use red for this example right here. Let's say this particular host, this client right here, wants to talk to this one.

2:19Uh-oh, what do we do here? Well, we know we're gonna be tunneling a frame, probably. So let's go ahead and build a VXLAN tunnel here. But the question becomes, okay, this client is gonna send traffic outbound. We need to tunnel that traffic over here. How do we get the traffic to exit out to this? In a really simple example, let's say this is a Windows 11 client computer and this is the corporate file share.

2:49Very common traffic pattern, right? We've got clients and workers, desktops, connecting to the corporate file share. They are almost never on the same subnet. In fact, the file share is very regularly in a data center or something. So how do we make this traffic come to life? Well, what ends up happening in an EVP and VXLAN environment because this is in the data center. We're not talking about enterprise example. Let's say this is a Windows 11 VM that we rented from Azure and we're trying to get it to communicate to our file share which exists somewhere else, even on a different subnet.

3:25How does this traffic happen? Because importantly, remember, this file share can still live on a subnet that overlaps another customer subnet. We can't get around using VXLAN and just traditional routing because the whole idea is that we can use any subnet we want. So even though we've got, you know, a VLAN 20 here and a VLAN 30 here, we can't just route from teal to pink.

3:55It has to be separated by VXLAN because it's the potential for overlapping subnets elsewhere. So what we do is when this frame comes in, it builds a tunneled packet with a destination VNI of 4930. So that when it arrives, this switch goes, oh, that's destined for VNI 4930. Let's go ahead and de-encapsulate it and send it down here.

4:28Ultimately, there is going to be a policy that gets created where the tenant owns VNI 4920 and 4930. And perhaps this is something that even the tenant customizes which traffic they want to allow to communicate to each other. Maybe they don't want these two subnets to communicate or maybe they do. And when they say, I do want these two subnets to communicate, the policy then says these VNI's can be routed back and forth to each other.

5:04So when the Windows 11 client wants to talk to the file share, it will send the frame in, it will be encapsulated, and it will have a destination VNI of 4930. When the return traffic comes back, it will have a destination VNI of 4920. That makes this a layer three gateway. Specifically, the leaf will be the layer three gateway. Now here's where it gets a little trickier.

5:35Let me pause and clear the screen quite a bit. This routing, of course, was facilitated by a default gateway. So this client knows, okay, well, I'm trying to communicate to my file share. That file share is not on my subnet, so I have to send it to my default gateway. So let's say this VLAN right here, VLAN 20, VNI 4920 was 10.1.20.0. So it says, okay, well, I've got to get this routed. I'm going to send this in to my default gateway, which is 10.1.20.1.

6:12This default gateway is what says, oh, okay, this is destined for VNI 4930, so I'm going to encapsulate it and send it over with a destination VNI 4930. That's how that works. That's great. But the real question is what happens when this virtual machine migrates like this? Now it's over here. Well, when we think about default gateways and we think about traditional networks right here, do we then have to migrate the default gateway with it?

6:49Because I don't want to have to log in. Every time this virtual machine migrates in the data center, that could happen automatically without me as a customer, without my, let's say I'm the customer here, I'm the tenant. That virtual machine might migrate without my control. If I'm renting the VM from AWS and AWS's servers decide it's overloaded, it could just migrate my VM without it. So if I migrate, if this VM gets migrated without my control do I then lose my default gateway and therefore lose my layer three connectivity?

7:23No, what we actually end up doing is we use an any cast gateway. Meaning every switch that supports VNI 4920 will listen on 10.1.20.1 with the same Mac address. I'm going to put AAAAAA to abbreviate this. So that when this machine migrates over here, there's already, because there's already a VNI 4920 over here, there's already a 10.1.20.1 listening on AAAAAAAA, or whatever it was.

8:07I don't know how many times I just said AA. There's already an any cast gateway waiting over here on the other side, ready to serve default gateway traffic. So that's how the layer three gateway works. The default gateway will exist on every switch that supports or serves this VNI. It will be an any cast gateway with the same Mac address. So that this VM can move anywhere in the data center that it wants and maintain the same default gateway connectivity and routability to its other assets and other VNIs that are managed by some policy, probably configured by the customer themselves.

8:53So VXLAN, we haven't even talked about really EVPN outside of the fact that it is the control plane and it advertises Mac addresses and their association to the VNI back and forth, right? But VXLAN, the big takeaways for you to understand here, first of all, still using Spineleaf architecture, separated by slash 31s everywhere so that we can maximize our bandwidth in our high-performance data center and therefore offer that to our customers via equal cost multipathing.

9:25Big things to understand next, VTEPs and VNIs. VTEPs are the switches, the virtual tunnel endpoints that they build tunnels back and forth to each other for encapsulating those frames and sending it over our equal cost multipath paths. The VNIs, a unique way to identify a specific tenant's VLANs so that each tenant can set their own VLAN with their own subnet even if they overlap another tenant's. That way we can keep our traffic segmented.

9:56Now we've got layer two gateways, which is really just what the VTEP does, and layer three gateways, which is how we can actually route traffic from one VNI to another. Also keeping in mind that we're using an anycast default gateway to service that traffic as it moves through the data center. So VXLAN, starting to get deeper into it. In the next set of videos, we'll start talking about EVPN. I hope this has been informative for you and 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 scenario questions. So a VTEP receives traffic from a locally connected host on VLAN 20. So if I'm thinking about this, I'm thinking about it like here's my VTEP, aka switch, and it receives the traffic from a host on VLAN 20. So we've got that. We've received the traffic from a host on VLAN 20. The traffic must be sent across the VXLAN overlay. So it's going over some channel to a remote VTEP. What information does the VTEP use to identify the correct VXLAN segment for encapsulation? Basically, how do we make sure this traffic is 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, or the source MAC address? The VNI mapping right here. This is the identifier to identify a specific tenant's networks. Policies are what enforces which VNIs are allowed to communicate to each other, but ultimately the segmentation comes down to the VNI itself. So that's the answer to our first question. A data center team wants to reduce unknown unicast flooding and improve scalability in their VXLAN fabric. They choose a control plane that advertises MAC address reachability before the traffic is sent. Which VXLAN control plane option best meets this requirement? So without a control plane, what ends up happening? The traffic ends up getting flooded anyways to find the correct MAC address destination, and that never really works 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 this requirement? Is it flood and learn? Well, no, that's what we're trying to stop. Is it statically setting our MAC address configuration? That's not scalable at all. Is it BGP EVPN as the VXLAN control plane? Or is it an ARP proxy without a control plane? Basically bouncing ARP requests all over the place. Obviously it's going to be the BGP EVPN as the VXLAN control plane. Now we did learn that there are other control planes that you can use like LISP or PIM. In fact, in MPLS and service provider environments, they use something like RSVP for traffic engineering, but that's because the traffic is more north south instead of east west. For data centers, EVPN is going to be the one. And we haven't really elaborated on why that is yet, but that's what the next set of videos is going to be all about. A VXLAN packet arrives at a leaf switch from the IP underlay network. So now we're looking at it from the other perspective. 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? So we've received a tunneled packet, which contains the frame. So what does it do then to strip it of this and shoot it down to the VLAN that it's destined for? Is this flooding it out the interfaces? Is this encapsulating it? Is it decapsulating it? Or are we learning the MAC address? 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.