Understand the Components of MPLS L3VPN

0:00[MUSIC PLAYING] Look, I know, I know, I know you are excited about this. Because this is, the final exam. When we talk about MPLS VPNs, we're talking about the final exam. What do I really mean there? What I mean is you go through six months, a year, two years of studying many different topics in your service provider journey. And then you have a final exam, which is the culmination of everything that you study.

0:30Toss everything that you learned into a bucket, and that's what MPLS VPNs bring to the table. Now notice, I haven't said MPLS Layer 3 VPNs. That's because MPLS VPNs can allow you to do things at Layer 2 and Layer 3. It just so happens that most people begin their MPLS VPN journey with Layer 3 VPNs. It's not necessarily the easiest one to learn, but it does build the foundation of all of the different technologies that go into providing the service to customers.

1:02In MPLS VPNs-- not just Layer 3 VPNs again-- you really bring everything to the table. You're going to have an IGP backbone. You're going to have MPLS, maybe even with traffic engineering. You're going to have Multiprotocol BGP, and understanding those BGP fundamentals. Then you're going to have things like routing instances and a lot of route policies. And it all is what crams into one thing to provide this incredibly useful and fun, and it's just-- it's just such cool technology. I'm just so excited about it, I can barely contain myself.

1:35But because there's so much going on in one technology, we're not going to try and cram it all into one skill. What we're really going to do is lay the foundation of how MPLS VPNs and MPLS Layer 3 VPN really works. What are all of the different moving parts that have to be coordinated? And we're going to take a little bit of a deep dive into some of those portions. How does this one particular type of tech really work? So we're going to talk about how MPLS Layer 3 VPNs really work. We're going to build the theory and talk about real-world use cases as we go along.

2:08Then in the next skill, we're going to talk about how to deploy an MPLS Layer 3 VPN from the Junos operating system. Now let me just go ahead and say right now, there are many, many, many, different variations, many different ways that you can deploy this. And that's why we're going to have additional content beyond that, when we talk about advanced MPLS Layer 3 VPNs. I guess what I'm trying to say here is understand now that, when it comes to deploying an MPLS VPN, even an MPLS Layer 3 VPN, this is something that's going to take some time, some repetition, some understanding.

2:40There's a lot going on here. And there are many different variations and styles that can be employed to actually deploying this. So it's going to take multiple skills and multiple sets of videos to actually understand how to deploy this incredible tech. So here we go. We're going to get started talking about what an MPLS VPN brings to the table and how we can get started deploying in MPLS Layer 3 VPN, all of the different tech that goes into it. Get ready as we start to design our MPLS Layer 3 VPN offering for our customers. Let's go.

0:05So what's the point of an MPLS VPN? How did they come to be? And why are they still employed today? What do they offer to the customer that's so nice? In this video, what we're going to talk about is why they exist, and why service providers offer them to their customers. Then we're going to talk about how we could start to see it in action. We're going to see it on a diagram, and see why MPLS VPNs are so special and so interesting to deploy. Let's get going talking about what MPLS VPNs bring to the table, and what you can expect to learn over the upcoming videos.

0:36Let's go. So when you talk about, what is the point of MPLS VPNs or MPLS layer 3 VPNs, it does beg the question, what is the point of a VPN in the first place? Why do customers want to use VPNs? Then we can transition a little bit into talking about why they would choose an MPLS VPN over something that they could deploy themselves, like an IPsec site-to-site VPN. So here's a topology that we're going to be working with over the next few sets of videos. This is going to be pretty much my MPLS VPN topology.

1:09We may add more prefixes to it. Sitting in the center of the white section, of course, we have our service provider. And then we've got two customers. We've color-coded these customers here. We've got a peachish, pinkish reddish customer, and then we've got a green customer. The whole idea here is that my customer, Customer 1-- let's just pick on them-- they want their users-- let's just put like a little LAN here-- to be able to securely talk over the internet or over a service provider's backbone to their other site here.

1:42So maybe they've got this customer here that's going to reach out to the internet, and this customer edge device here that's reaching out to the internet. But we want a server here to be able to serve our customer, or our end users, over here on this site. Not an uncommon scenario, is it, where we may have-- Bob sits at his computer. He wants to access a file share that's located at HQ. This is a very common thing. But the kicker is now they have to do it in a secure manner. Would it be wise or advisable for us to just open port 445-- that's SMB traffic-- to the public internet?

2:18That way, Bob could come along, and maybe he still has to authenticate or something, sure, with a username and password. But the point is Bob would be doing that over the public internet if we were just to open SMB up to the internet. No, we don't want to do this. This is bad. Of course, this is bad. The same for the big one. How many times have we seen RDP opened to the public internet, and a hacker just finds their way in? Maybe they fish out passwords, or they do some form of brute force attack. You get the idea. And now, they've RDPed into a terminal server, that's been opened to the internet.

2:51I personally have dealt with these scenarios with clients before. We tell them, don't do this, and this is the first thing they want to do. Oh, it'll never happen to us. Anyway, you get the point. The point is we need customers' traffic to be securely brought from one physical location to the other. This is the point of VPNs. We have this whole infrastructure here. This is a router here, and a router here, and a router here, and these prefixes have to get shared throughout. That way, our customer, one way or another, could reach the other site here, even if these are public IP addresses.

3:27So if I write V, P, and N here, let's explore the V. The V stands for Virtual. The idea here is that we are logically building a network on top of this physical backbone. Oftentimes, this is referred to as a fabric. So instead of the customer seeing this as they have to hop from here, to hop from here, to hop from here, to hop from here, to hop from here-- no. Instead, the customer just wants to see it almost as if they have one direct subnet right here.

3:58This is sometimes referred to as a pseudo-wire, fake wire-- so they believe that logically, they are directly connected by some sort of tunnel or some sort of direct subnet, because of the virtual nature of how this works. There are lots of technologies that can provide a virtual network from our customer to the other. But the P is where it starts to get tricky-- Private. The idea here is that our customer wants to know that their traffic is perfectly isolated from other customers' traffic, that it's not using just the shared public infrastructure to do this.

4:34Sometimes, they can add their own privacy using encryption suites, like IPsec. But if they were to use something that's a little more plaintext, like layer 2 tunneling protocol, then they may be getting the virtual nature of their tunnel, but they're not getting the private nature of their tunnel. And this is where the private becomes a big deal. And then lastly, of course, this is a network. That one kind of goes without saying. So now we understand the use case for a VPN in general. The idea is I have traffic, like Bob's traffic here, that needs to reach my server over here.

5:06It needs to do this in a virtual, logical way. That way, we don't see the entire infrastructure of our service provider, or nay, the entire internet itself. We just want it to appear like we have a direct connection to our neighbor. But further, it has to be private. We want to be isolated from all of the other traffic that's out there on the internet. And further, if we can, we'd like to add encryption into the mix. And then, of course, this is a network. So a virtual private network isn't just seeing a logical tunnel from one end to the other.

5:38It's also keeping that privacy in play here. That's a very big deal. So customers, when they now realize that we need a virtual private network to reach-- so that Bob can reach the server over here, they have a couple different options of creating a VPN. And I'm going to say this. I'm going to venture to say that the smaller the client, the more likely the client is to have a do-it-yourself deployment to virtual private networks. They may want to opt for a site-to-site IPsec VPN.

6:10This is where the customer deploys a firewall and just gets a public internet connection from the service provider. They deploy a firewall here, over on their own site here, and get a public internet connection from the same service provider or a different service provider. And then we point these firewalls towards each other, and they build a secure VPN tunnel. IPsec is just a phenomenal suite of technologies that go into play here. And of course, we're not going to get into building an IPsec tunnel.

6:42There are just a ton of different ways that you can learn about how to deploy IPsec tunnels here on CBT Nuggets. And yes, I am going to be working on the Juniper security track coming up, where you'll learn how to deploy IPsec tunnels on SRX-series firewalls. It's not here yet, but it will be on the way. That being said, if you're just curious about IPsec firewalls, you can learn about it in Network+, Security+, CCNP Security. You can learn about it in our Firepower content. You can learn about it in Palo Alto content. We've got IPsec content out the wazoo here at CBT Nuggets, and I'd encourage you to dig more into it.

7:15But this is the use case when the customer is looking for something maybe a little more affordable, and they want to do it themselves. That's what the IPsec site-to-site VPN is all about. What we, as a service provider, can do, though, is say, hey. Don't worry about handling all of that suite of protocols, buying new hardware, maintaining it yourself. You can just share to us the prefixes that you want to be sent from one site to the next, and we will handle tunneling it for you.

7:46This is where the MPLS layer 3 VPN, or the Layer 2 VPN, comes into play. With the MPLS layer 3 VPN, the customer will send us actual IPv4 prefixes that they want us to send across our topology towards their other site. So the customer here will just be able to look in their routing table, and they will see this other site's-- all of the prefixes that they share, they'll see it there. And they know that the next hop is just punt it to the service provider, and they'll handle getting it the rest of the way there.

8:22The flip side of that is layer 2 VPN. With layer 2 VPN, the customer literally sees this as a layer 2 connection from one end to the other. If you're following along in your Juniper journey throughout CBT Nuggets, you've already seen a little bit of layer 2 VPN technology in action, haven't you, when you deployed q and q technologies as part of the JNCIS content here on CBT Nuggets. However, that didn't really use very much MPLS at the end of the day. What we're here to talk about now is MPLS technology. MPLS really flipped the script.

8:54It really changed how all of this stuff worked, and it enables us to do insanely cool things when you couple it with other technologies, like BGP. I don't want to get into this too much, because it will be overwhelming very, very fast. What I'm just trying to tell you right now is that MPLS solved problems for the service providers, especially in the late '90s and early 2000s. In the late '90s and the early 2000s, yeah, there was Ethernet and IPv4, but there was also ATM, and there was also frame relay.

9:26Those things-- you don't see ATM or frame relay much anymore. But what MPLS brought to the table was our ability to receive prefixes on one of these types of transports. And we were able to tunnel them across our entire network towards the other end. When we combine this with multiprotocol BGP, we were able to do this in such a way that it added a layer of segmentation. I don't want to say privacy, but it added a layer of segmentation that kept our customers' prefixes completely separate from our own prefixes or our other customers' prefixes.

10:07The end result by doing that was that we could use a subnet, like 10.1.1.0/24. Our customer could use a subnet, like 10.1.1.0/24. And then we could go get, or recruit, or sell to another customer, who also used 10.1.1.0/24. And it didn't matter if they used ATM, or frame relay, or Ethernet. We were able to handle all of it. MPLS layer 3 VPNs or layer 2 VPNs made us, as a service provider, super, super flexible.

10:40That's what it really brought to the table. And when we go to customers now, we can say, don't worry about building out your WAN infrastructure. We will do it for you. All you have to do is just peer to us, and we'll handle segmenting and sending your traffic from one end to the other. But beyond that, we can also add in SLAs into the mix. This is where we start to separate ourselves from a site-to-site VPN and just the public internet. Now we can also talk about things like bandwidth reservations. We can talk about things like uptime SLAs.

11:12We can make these guarantees that also add to our ability to provide unique services, and upsell ourselves a little bit to the customers. The customers love this type of thing. So they can have an internet connection, but they can also have a private connection to their other sites that are guaranteed with uptime and bandwidth reservations. Then we can do things like WAN traffic engineering, where we send our internet traffic outbound, or our site-destined traffic out towards the MPLS. This is where SD-WAN starts to come into play. So this has been understanding the point of VPNs, and how MPLS VPNs bring something unique to the table.

11:48It's all about offloading our customers' responsibilities onto us-- that's pretty cool-- but keeping them segmented, and we remain flexible, regardless of the technologies that they want to tunnel. Let me say this now, too. We can tunnel basically anything that they want to do over MPLS now. We can tunnel things like IPv4 unicast, IPv4 multicast, IPv6 unicast, IPv6 multicast, and we can handle all of that through the magic of MPLS VPNs. Throughout this set of videos, we're going to talk fundamentally about how this works, how all of these things work.

12:21In the next set of videos, we're going to do a basic IPv4 unicast MPLS layer 3 VPN deployment. At that point, you'll be acclimated enough to how these technologies work to where you can start diving into the advanced MPLS VPN technologies and MPLS layer 2 VPN technologies. So this sets up what we're trying to do, what we're trying to bring to the table, what problem we're solving for our customer. Now it's time to talk about, how does it really work? That's been understanding the point of MPLS VPNs. I hope this has been informative for you, and I'd like to thank you for viewing.

0:05MPLS layer 3 VPNs all have to start somewhere, and this is where we start to, yeah, transition away from MPLS VPNs into MPLS layer 3 VPNs. So you're going to start somewhere. You're starting off from scratch. Maybe you're building a lab. Or maybe you're starting a brand new service provider up from scratch, and now you've offered MPLS layer 3 VPNs. What do you do first? The first thing that we have to do is we have to build our infrastructure backbone. This is going to be just our service provider transit network that's going to be carrying our customers' traffic.

0:37So this is going to be things like the IGP. This is going to be things like MPLS. And this is going to introduce multiprotocol BGP and how it is actually used in an MPLS layer 3 VPN environment. So let's keep going talking about the service provider backbone that's going to be used to actually carry the customers' transit traffic. Let's go. As a service provider, the thing that we want to do is provide excellent customer service. So we, oftentimes, are customer-first. However, in order to make an MPLS layer 3 VPN really work, we have to focus on ourselves first.

1:12None of this will work unless our backbone is actually deployed correctly. So we do have to focus on making sure these links and this design is formatted in just the way we want it to, and how it's going to behave the way we want it to, before we can start talking about how to get this router's traffic over to this router's traffic. So let's talk about the backbone components that make MPLS layer 3 VPN work. And this will be our first puzzle, our first building block into the entire deployment of MPLS layer 3 VPN.

1:42The first thing that you need to know about MPLS layer 3 VPN, or really any MPLS VPN, is we deal with the concept of edges. Just like in Q-in-Q, or the stuff we covered in JNCIS service provider, we have provider edges and we have customer edges. So the real focusing point is we're trying to get traffic from this provider edge, our device, tunneled over to this provider edge. So what must happen-- what absolutely must happen is we must have end-to-end connectivity, and a suite of technologies work together to make this happen.

2:14So the first thing that has to happen is we have to have an IGP that is sharing all of our prefixes back and forth. And it's going to be absolutely critical that we make sure our loopback-- so I got to spell loopback correctly-- L-O-P-- loopbacks are deployed throughout the IGP. Why? Because we're also going to be throwing MPLS into the mix so that it can support our multiprotocol BGP, or really, our IBGP neighborship adjacency.

2:46How does MPLS and MP-BGP play into the mix? Well, that's really what the rest of these sets of videos are all about. The point is, first things first, you have to deploy an IGP so that we see all of the possible routes within our topology. Then from there, we have to deploy some form of MPLS deployment. Of course, that leaves us with two options. We have LDP and RSVP. If you recall back in your studies, RSVP-- we will have to manually create every single label switch path that would need to exist.

3:20In this case, what we're saying is we would need to create an LSP from every provider edge to every provider edge where a customer's traffic would need to traverse. So if I have Customer 1 here trying to reach Customer 1 here, I would need to deploy an LSP from this PE to this PE. But also remember, with RSVP, we would need to make it bidirectional, or create a second LSP coming backwards. That's another part of RSVP. It's very deliberate. You have to tell it how to behave.

3:52Really, what I'm trying to say here is what oftentimes happens in a service provider's world is you end up deploying LDP no matter what. You may deploy RSVP to engineer specific subsets of traffic, and then deploy LDP on top of it, so that it could find a full mesh, so to speak, of how label switch paths would need to be created that way, because that really is the point of LDP, at the end of the day. It creates a full mesh of LSPs. Not necessarily neighbors, but LSPs. So basically, what I'm saying here is when it comes time to deploy MPLS layer 3 VPN, you're going to deploy in IGP.

4:27In my case, when it comes time to actually deploy this, I'm going to deploy IS-IS. I prefer IS-IS over OSPF for a few different reasons. First of all, I prefer LSP to use over LSAs. I also prefer the fact that IS-IS is built with the traffic engineering database enabled in carrying traffic by default. I also prefer the fact that it carries TLVs, instead of having to rely on the opaque LSAs. And I also like the fact that it's a very extensible and flexible protocol that doesn't have to have a backbone area in order to make this come to life.

5:00You could just deploy level 2 IS-IS everywhere, and it'd be just fine. Then in a small topology like this, I'm just going to deploy LDP. So with the IGP and with LDP to put in place, we now have the connectivity in place from our PE to PE to perform label switching through an LSP from loopback to loopback. The cool news then is it becomes very easy to deploy multiprotocol BGP. In basic demo environments, you may see this as something like a full mesh, like so, or you may just see this as this provider edge will have an IBGP connection directly to this provider edge.

5:42There's no reason not to do that, because the cool thing about MPLS is that none of these devices that sit in the path have to actually inspect the packet itself and make a forwarding decision, right? It can do that based on the label switch paths. However, it's not really a real world use case or real world scenario when it comes to actually deploying an MPLS layer 3 VPN, because it's never just as simple as one provider edge connecting to one provider edge. The customer may expand.

6:12And then we'll have a provider edge down here, and a provider edge down here, and then maybe a provider edge over here, and then maybe a provider edge over here, and then, oh, there's going to be a new site over here, and then you get the idea. There's provider edge, providers edge, provider edge. And then all of a sudden, what would have been just a simple connection from this provider edge to the next becomes a full mesh that looks something like this. And now we have to have this connectivity, like so. You get the idea this isn't scalable?

6:43So even though in many environments, you'll see a provider edge connected to a provider edge, like so, what really happens in the real world is your provider edges talk to route reflectors-- route reflectors. So that way, the routes can be reflected in every direction this way, and we don't have to maintain too many neighbor adjacencies. So kind of recapping how our backbone is going to look, we're going to have IS-IS, which allows us to have end-to-end IPv4 connectivity at layer 3.

7:14Then we have LDP, which allows us to perform label switching from one end to the other. Notice I didn't say this allows us to have neighbor adjacencies from one end to the other. This just allows us to send traffic from our provider edge to any other provider edge using label switching. That's kind of the idea here. Oh, I erased this. Let me undo. And then we deploy multiprotocol BGP on top of this. Why do we do multiprotocol BGP? We're going to talk a little bit more about that in the upcoming videos.

7:45It gets more interesting as we travel along. But the idea is that with multiprotocol BGP, now when we advertise prefixes into our environment and it gets reflected around, our Provider Edge 2 device can learn about routes through BGP, and it can see the next hop as the loopback of PE1 using MPLS to reach that. And MPLS, of course, is supported by IS-IS. So the first thing that you need to know, before deploying MPLS layer 3 VPNs, is that your backbone is really going to consist of three tiers.

8:21There's going to be your underlying IGP, which is going to be used to facilitate MPLS. And MPLS is used to facilitate multiprotocol BGP. So prefixes that are shared by BGP will have a next hop address of the loopback address. That'll be label switched throughout the topology, and that label switching was really facilitated by your IGP. So this is understanding the construction of the backbone itself. Keep in mind it's going to go like a three-layered fabric-- IGP, MPLS, multiprotocol BGP.

8:56How and why does that really work? It starts to get very interesting in the next video when we start to introduce the concept of VRFs, and how we actually tunnel our-- traffic over that backbone. I'll see you there. I hope this has been informative for you, and I'd like to thank you for viewing.

0:05In the previous video, we talked a little bit about multiprotocol BGP. And this sets up the bigger conversation that there are many different components to making multiprotocol BGP work. So now we're going to shift our focus a little bit towards the connection between the provider edge and the customer edge, and how we can actually isolate that customer's particular traffic from all of our other customers. This is a bigger design topic to talk about. What we're really talking about here is a special type of routing instance called a VRF.

0:38So let's get going talking about how VRFs work, and how they start to feed into the discussion of multiprotocol BGP, and something really special here, the address family called IPv4-VPN-- sometimes called VPNv4. Let's get going talking about how we isolate customers traffic with VRFs first. In our JNCIS service provider journey, and even a little bit in the JNCIA, we talked about something called routing instances. And the idea with routing instances was that we could take an interface, or an IP address, or a route and isolate it in its own route table.

1:13That way, it would not be impacted in the global unicast route table. If a route came in destined for it, then it would never be looking up in the global unicast routing table. It was a nice way to keep our traffic privately separated from other types of traffic that we wanted to support. But one of the things that we didn't really talk about was VRFs, Virtual Routing Forwarding instances. VRFs are a type of technology that are used in MPLS layer 3 VPNs.

1:43They're a type of routing instance. The idea is like so. When we have this customer-- we're going to look at Customer 1 - Site 1. He's got a CE1-R1 router. And they want to connect over to Customer 1 - Site 2. And they want to do this in such a way that we will be able to privately and securely send their traffic over our backbone. But it will never accidentally get sent out towards Site 2 or into our own network backbone 2. It needs to exist in its own route table.

2:14So your head instantly should go to routing instances. But one of the tricky things about this is, how do we actually get their routes-- like they've got a bunch of different routes and prefixes over here-- shared over to this customer over here? This is where we start to use multiprotocol BGP. Specifically, there is a type of IPv4 NLRI-- Network Layer Reachability Information. It is a type of IPv4 address that carries additional information about that prefix itself.

2:48And the VRF instance type is where we set that additional info so that it can be carried from one end to the other. So when we create a VRF on this link right here, there are a couple different items that we set on this instance that help BGP understand who this traffic is really built for. So let's pretend for a moment that one of the LANs that my customer has is this 192.168.1.0.

3:20We have a customer, Bob, who needs to ping a server or reach a server on 192.168.1.0. So the first thing we do is we create a VRF specifically for that interface. This is the customer's own route table. On provider edge, this customer will get its own route table. And we want that customer to populate our route table. So we run an IGP, like OSPF, or we may even run EBGB between the customer and ourself, so they can send all of their prefixes to us.

3:54And in our route table-- let's just call this our C1 route table for Customer 1-- their prefixes populate that route table. But the VRF has some extra capabilities, something called a Route Distinguisher, very frequently abbreviated RD, and a route target, very frequently abbreviated RT, that help our VRF work with multiprotocol BGP. So if I draw in pink multiprotocol BGP, when it comes time for PE1 to share that prefix over to PE2 so that they can share that prefix to CE1, we're going to let multiprotocol BGP be the one who carries that prefix.

4:38So multiprotocol BGP is going to be carrying 192.168.1.0/24 out of PE1 over to PE2. PE2 is going to receive 192.168.1, and then it has a decision to make. It has to figure out, well, wait a minute. Which customer is this for? Which prefix is this for? How do I know this is different from another 192.168.1 that I may have received over a different VRF? The route distinguisher is the first thing that happens to make sure that 192.168.1 is perfectly unique or distinguished from any other prefixes that may be coming in.

5:16For instance, maybe Customer 2 sends us a 192.168.1.0/24 prefix, and it comes in over multiprotocol BGP, as well. So when we create our VRF, we tell this VRF, you are going to have a route distinguisher that-- guess what-- distinguishes the route as it arrives on our other provider edge devices. For simplicity's sake, let's just say I call this 101:192.168.1.0/24.

5:50No, this is not how a route distinguisher is actually written. This is just to familiarize yourself with understanding how a prefix may look, or feel, as it's distinguished as it goes across the environment. Then, when this 192.168.1 comes in from customer 2, we may call this 202:192.168.1.0/24. Again, the whole point of the route distinguish-- it's just to distinguish a prefix from any other overlapping prefix that may come in over multiprotocol BGP.

6:28That's it. It doesn't tie this prefix to a customer. It doesn't tie this prefix to a specific VRF. All it does is distinguish the prefix as it flows across multiprotocol BGP. So now we've got two prefixes that arrive on PE2. We can see that they are the overlapping subnet, but they are distinguished from each other. We know that they are not the exact same prefix. How do we then know which VRF they belong to? This is what the route target does.

6:58The route target is almost like a route policy that identifies explicitly which VRF they belong to. Route targets are kind of a big topic, and they come in many different shapes and sizes on the Junos platform. You will see this much more in the next set of videos. Let's just say for this particular customer, we gave them a route target of 1111, and for this particular customer, we gave them a target of 2222. When the prefix arrives on PE2, it's VRF will have to also be configured with the same route targets of 1111 and 2222.

7:39And this sets up the conversation, kind of like a recap, of how this is all really going to work. Oh, let me bring it back. Yeah. So our customers are going to send us a prefix, 192.168.1.0/24. Multiprotocol BGP is going to be what's used to advertise that prefix from one provider edge to the next provider edge. We use multiprotocol BGP, because multiprotocol BGP can carry the route distinguisher and the route target.

8:10Now I can officially say, this is not just IPv4. This is specifically an address family called IPv4-VPN. It is a type of IPv4 that is explicitly defined to use a route distinguisher and a route target. So as the same prefixes flows across multiprotocol BGP, the route distinguisher keeps them separate. Once they arrive on the provider edge, the provider edge determines which route table-- which VRF table it's allowed to be imported into, based on the route target.

8:46The matching route targets have to exist on both sides of the topology so that we know which routes can be exported and which routes can be imported. Again, I can't stress this enough. We were just highlighting a very basic way of how route distinguishers and route targets look and feel. This isn't how they are explicitly typed out, and this isn't how the prefix is actually mapped and sent across the entire topology. In the next video, we're going to dig deeper into how IPv4-VPNs really work and what the actual packet headers contain.

9:18This introduces how MPLS layer 3 VPNs really work after our backbone is established, and it's time to start building VRFs and carrying traffic throughout the topology. I hope this has been informative for you, and I'd like to thank you for viewing.

0:05So now we start to understand that VRFs are all about isolating, but also kind of like tagging our customers' traffic. And then multiprotocol BGP is truly multiprotocol. It carries VPN-style routes, VPN-style prefixes across the backbone to our other provider edges. Now we need to take a closer look at IPv4 VPN, or a lot of other vendors call this VPNv4. Let's take a closer look about how this address formatting really works and how route targeting really works at the end of the day.

0:40So let's take a closer look at these NLRIs, or Network Layer Reachability Indexes, and how the formatting really works to carry unique prefixes across the MPLS backbone. I'll see you there. So in the previous video, we introduced the concept that multiprotocol BGP wasn't just advertising IPv4 unicast prefixes throughout our topology. When we advertise a route that we received from the VRF, we're actually advertising an IPv4 VPN prefix throughout the topology.

1:14And one of the big things about it is that it carries additional information about how this actually works. So think about multiprotocol BGP, just by itself, before we even talk about VPNv4. When we talk about multiprotocol BGP, what is it advertising from one into the other? It's advertising IPv4 prefixes, is it not? And what do we know about those IPv4 prefixes? They are 32 bits long. It's just a subnet address, something like 192.168.1.0/24.

1:47But what do we also know about BGP advertisements? They advertise an NLRI-- Network Layer Reachability Information. And this is a fancy way of saying there are additional attributes, and communities, and fun stuff attached to it that make this prefix somehow unique or distinguishable from other advertisements. Now what we're trying to do our objective is to use this idea, this technology that BGP brought to the table, but tweak it to do a little bit more.

2:20We want it to work specifically for our VRFs. And there's really a couple of things that happen here. We introduce a new protocol family. Just like how IPv4 unicast was a protocol family, now we introduce a protocol family called IPv4 VPN. And it really focuses in on the NLRI here for a second. It's all about carrying additional information. With IPv4 VPN, we can carry prefixes with additional information attached to it so that we know that it's part of a VRF, or so that we know that it's part of an MPLS VPN.

2:57So now what we do is we turn our attention a little bit to the header, and more specifically, the prefixes that are advertised in an NLRI. When we look at an IPv4 NLRI, we are going to look at the IPv4 prefix and the additional info about it. An NLRI in IPv4 VPN-- basically, saying the IPv4 VPN prefix-- is 96 bits long. At the end of the NLRI, we have our 32-bit prefix, just like this.

3:29But the first 64 bits are consumed by something called the route distinguisher. The route distinguisher is made up of three different pieces that are very important to know. And we're going to talk about the formats of these route distinguishers and what they do in the next video. The first piece of the 64 bits is the type field. This consumes 16 bits. And the remaining bits that go in here, it really depends on which type is selected.

3:59So it's not really fair to say what goes where. And you'll see why when we get to the next video. For now, know that there are two pieces that work here. The first piece is called the administrator, and the second piece is called the assigned number. So I'm going to put a little number sign here. And this is how you would actually read an IPv4 VPN NLRI. It would read something like this. There would be the type field, which would either be a 0 or a 1, so maybe something like a 1. Then you would have the administrator.

4:31This could be something like your autonomous system, 65530. Then you would have an assigned number, basically an arbitrary number that you could assign to a specific VRF or a specific customer. Maybe I'll say this is customer 1, so I'll put a 1 right here. Then the prefix that customer 1 is trying to advertise over to their other site, so something like 192.168-- oh, got to write that dor there-- .1.0. Pretty nasty and hairy, right? We're going to get into more about the route distinguisher in the next video.

5:01I know I keep saying that, but it's important to understand what the real purpose of the route distinguisher is. It does nothing more than distinguishes a route as it travels through the multiprotocol BGP. The interesting thing about it is it doesn't necessarily attach it to a customer. When PE2 receives this advertisement, this route distinguisher doesn't automatically tell it which VRF it belongs to. Let me further illustrate why we need the route distinguisher, even though we're going to cover this in a lot more detail in the next video.

5:33Pretend for a moment we have our green customer, and they also want to advertise as same prefix. We're talking about an internal customer here. At the end of the day, they can run however many subnets they want. There's nothing to stop a red customer in Buffalo, New York, from running 192.168.1, and a green customer in New Orleans, Louisiana, from running 192.168.1 in their internal networks. But they may want to contract with us for a VPN, and they want to send that network over our service provider backbone to get to their other site.

6:05Well, at some point, we're exporting our prefixes into BGP. So BGP needs a way to keep them separated as they travel through the network. And that's what the route distinguisher does. So perhaps here, the route distinguisher may look something like 1:65530:2, for customer 2, colon 192.168.1.0. And then PE2 would be able to receive both of these prefixes, knowing that they aren't the exact same prefix and that it needs to take further steps to figure out what VRF they belong in.

6:38Let me also go ahead and say this, too. The IPv4 VPN-- we've only talked about the NLRI, the advertised prefix, up until this point. But of course, there's more information carried in the header and the contents of the NLRI itself, too. There are communities. We even have the MPLS label. That's going to play a very important factor when it comes time to actually follow the packet flow through. There's a mask field set with it, as well. So the NLRI is just the advertised prefix, and it really consists of the route distinguisher and the prefix itself.

7:10The route distinguisher is made up of three important parts-- the type, the administrator, and the assigned numbers. But let's talk about what the route target is all about, now that we've got the route distinguisher settled. And the route target is an extended community carried by BGP. That's right. The route target is a community. Pretty interesting thing to differentiate between the route distinguisher and the route target, because when you jump onto the command line, they're going to look pretty similar to each other. However, the route distinguisher was used to actually build the header of the prefix itself.

7:44This is a way to differentiate the prefix itself as it flows across the traffic. The route target is what says, this is the community that we belong to. Therefore, this is the VRF that we belong to. So PE2 will be able to receive the prefix and look at it in a unique way, thanks to the route distinguisher. But it's not able to actually put that in a VRF until it examines the route target community. So this is how multiprotocol BGP really behaves, and where the VRF really starts to add additional functionality into multiprotocol BGP and extending what we already know about a prefix that we're learning.

8:24So now what we need to do is we need to actually look at a route distinguisher and actually look at a route target, and how those really behave when it comes time to configure it. Is your brain turning into mush yet? There's a lot of stuff going on-- some MPLS layer 3 VPN. And now you may see why we're not jumping onto the command line just yet. So this has been identifying what IPv4 VPN really is. It is a unique address family that extends a prefix that we already know by adding a route distinguisher into the header, and also carrying extended communities in multiprotocol BGP.

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

0:05Now we understand how VRFs and IPv4 VPN can be used to actually carry traffic across the backbone. We need to explore now how the route distinguisher format actually looks. This is something you need to know when it comes time to actually start configuring routes distinguishers on your command line. There's two different styles of formatting for route distinguishers, so let's explore how we can actually write our route distinguisher and how that will impact how prefixes are carried across our topology.

0:36I'll see you there. In the previous video, we introduced the route distinguisher component of a total IPv4 VPN header. Again, like I say, many other vendors call this VPNv4. But I'm going to call it IPv4 VPN for the most part, because that's what you're actually going to see on a command line. So we had mask. We had the MPLS label. Then we had the route distinguisher. And then we have the prefix itself. What we're going to do is we're going to focus in on the route distinguisher now, because there are two types of formats that you can use to write your route distinguisher.

1:11And there's no real wrong or right way to do it. However, there is kind of a best practices or what you're most likely to run into in the real world. I'm going to write it out like this. We have the type field. And I'm going to tell you right now, type determines the actual format that you're going to write for your administrator field and your assigned number field. There are two options for type. There is type 0 and there is type 1. Let's talk about type 0. The format for the type 0 field is written like so.

1:44In the admin field, you write the BGP autonomous system number. Then there's a colon. Then you just assign an arbitrary number for your customer. Maybe you want to use a customer ID that's in a database, or you just come up with a number. So in this case, for customer 1, I'll simply put 1. So if I were using type 0, my route distinguisher field-- actually, my entire prefix-- could look something like this. I'm erasing things.

2:15It could look something like a mask of-- put 00 just to fill up some space. Then the MPLS label, which could be something like 23358. The type field would be 0. The admin field would be 65530, if I'm looking right here at my service provider drawing. Then colon 1, then it would read like this-- colon then my prefix that is being advertised.

2:46The cool part about this is when it comes time to actually configure a route distinguisher on your VRF, you only have to type in this part right here. It'll automatically be able to-- that it's type 0, because of the format that you typed it in. MPLS will be doing its own MPLS label switch thing. And the mask is going to be set automatically. The prefix is going to be handled based on the VRF advertisement, when we talk about how to handle route targets. For the most part, what we're focused in on right now is the format of the route distinguisher, which was this block right here.

3:19So if you choose to do a type 0 formatting, you will specify the ASN, followed by an arbitrary number, and Junos will automatically able to tell that that is a type 0 format. However, this is not what's deployed most often, or at least that's not been my experience. What's deployed more often is the type 1 prefix. If I clear the screen, let's do this. The type 1 prefix is written like so. The admin number is actually the router ID for the device itself.

3:51So this could be 1.1.1.1. Then the assigned number-- it's going to go colon and then the assigned number, which is going to be, again, just an arbitrary number that you assign for the customer. Then it would go colon prefix at this point. So the interesting thing about this is it's really just about keeping prefixes unique as they come in from an environment. So consider this hypothetically for a moment. Customer 1 advertises 192.168.1 inbound. We create a VRF, and we give it the route distinguisher of 1.1.1.1 colon 1.

4:26Then we create a VRF for Customer 2. We give it the droute distinguisher of 1.1.1.1 colon 2. If both of these customers advertise 192.168.1.0/24 inbound, we can immediately see how these routes would be distinguished as they flow across BGP. PE2 would be able to receive two NLRIs-- one that would look like 1.1. I've got to write a better one than that-- 1.1.1.1:1:192.168.1.0/24 and 1.1.1.1:2:192.168.1.0/24.

5:12And it will know in its BGP table, I have received two unique prefixes that we could examine further inbound. With these two prefixes now installed in a special BGP table just for MPLS layer 3 VPN, it can examine the extended communities, looking for the route target to determine which VRFs it needs to belong to, and then advertise those out to the customer that way. The flip side is when traffic is coming to return inbound from PE2. We can use a route distinguisher here of 2.2.2.2:1 and 2.2.2.2:2.

5:51The route distinguisher does not need to match on both sides for each customer. The route target is what determines which customers VRF gets the traffic. And that's what's important, and that's what we're going to talk about more in the next video. The route distinguishers simply exist to keep a prefix unique as it traverses the backbone from one provider edge to the next. So this has been understanding the formats of the route distinguisher. There's two formats, type 0 and type 1.

6:21In my examples, we're going to be using the type 1 format as we progress forward. That is the router ID followed by an arbitrary number. So that's been understanding the route distinguisher. I hope this has-- informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Route targets are what are used by the devices to actually determine which VRF they're allowed to export or import prefixes into. This is going to be a huge one. This is really what makes MPLS layer 3 VPNs work at the end of the day. Now, there's a couple different implementation styles that you can take when it comes to VRF targets, or VRF route targets. So let's talk about how VRF targets work on the Junos command line.

0:32And then when it comes time, we'll be able to implement this much smoother. I'll see you there. So now its time to explore the route target, because this is where we really got to start tying in how the VRFs really work and how prefixes actually make their way from one customer router all the way to the other customer router. That is the goal at the end of the day is for this customer to advertise their LAN side prefixes to us, and this router over here sees those LAN side prefixes.

1:03So that way they know, oh, if I want to reach a device over here, my next hop is just into my provider, and then it just gets handled that way. So we see now that the idea is we create a VRF that the customer can then use, like OSPF, to advertise prefixes to us. We then build a BGP-style tunnel, where we take that prefix and turn it into an IPv4 VPN prefix based on the fanciness of the route distinguisher. But this is still BGP at the end of the day.

1:33And BGP has the ability to carry all sorts of additional info about prefixes that we really need. The route distinguisher was not sufficient enough to tell us which VRF that this belongs to. All it did was just make sure that this prefix that the customer advertised in was unique. So that way, if another customer advertised a prefix into us, BGP would just see it as a unique prefix. There was no data involved with that that said this belong to customer 1 or this belonged to customer 2.

2:06So we had to create an extended community as part of MPLS layer 3 VPN that actually carried the specific information that tells our devices what customer and which VRF they belong to. This was called the route target. And this was pretty important to understand. Route targets behave in a couple different ways. I'm first going to talk about the simplest form of a route target. We have a customer called customer 1. Let's just call them customer 1 at least for simplicity's sake.

2:37When we create a VRF here on this particular interface and we start receiving prefixes in, we need to make sure that those routes are identified specifically for customer 1. So as they make their way across the backbone, yeah, they're distinguished from other prefixes, but they're not distinguished to the point to where we know they're customer 1. So we create a route target. I'm going to, for simplicity's sake, call this C1 for customer 1 right now. So you can imagine in the extended community, we're carrying a value of C1.

3:10That's not exactly what's happening here. This is just to show you how it works. Then on PE2, on this VRF, I'm also going to create a route target also called C1. So that way, when multiprotocol BGP sends a prefix over here to PE2, it can look at the extended community. And it can say like, oh, I see, there's a C1 here. Therefore, it must belong to my VRF where I've assigned a route target of C1. You can see how now this really is a target.

3:42We're saying, I want you to target the VRF that's been named C1. That's how we're going to call this. Now, on the Junos devices, there are a couple different ways to implement route targets. The easiest one is to actually use the command vrf-target. And it does exactly what we just described it did. For instance, if I create this VRF, and I use the command vrf-target-- and just for simplicity's sake, again, this is not how its really going to look.

4:13I'm going to call this C1-- this will automatically, and I can't stress this enough, this will automatically take all of the prefixes that are in this VRF whether they're locally attached, because we're directly connected, or we learn them from something like OSPF, and it will automatically send them into multiprotocol BGP. And it will automatically have the extended community of C1 attached to it. Again, there's no export policy here.

4:45There is no import policy here. There's no telling it export specific prefixes. There's no telling it add this extended community. It just automatically does it. And as long as over here on customer 2 we created a VRF with the command, vrf-target C1, it will automatically import those prefixes with the same vrf-target, into the VRF. And then the flip side would happen too. Any directly connected prefixes here, and any learned prefixes via OSPF, as long as we have this vrf-target set, it's going to send it into multiprotocol BGP.

5:23This is by far the easiest way to implement MPLS layer 3 VPN. But just know, that it is a catch all, send all situation. It says, anything that's in this route table, send it that way. And if you receive anything with the same target, import it into the route table. So this is the first type of route target. And that's using the vrf-target command. Now, the second type of route target is explicitly using an import or an export policy.

5:53In the import and export policy, you will tell it specifically which prefixes to match on and specifically which extended community to add. So maybe we only want to send 192.168.1.0. So we create a route policy with a route filter that matches that prefix. And in our then statement, we use community add. Again, we're talking about culminating all of the things that we learned until this point.

6:25So if you haven't watched the BGP content on how to actually add communities and match prefixes, you'll want to go back and watch that BGP content, because this is the other way that you would use route targets. You would explicitly match the prefixes and explicitly add the extended community onto that. Now, the format of the actual route target itself, this is interesting. In the Junos CLI, because we're talking about extended communities, the target has a pretty unique syntax. It's a little bit different from other vendors.

6:56It has the syntax with the word target. It literally starts out with target. You write target, and then the name will start with target. This tells the Junos CLI and the Junos operating system that this extended community belongs in the route target. Then, the best practice here is to use the autonomous system number. So here we would put something like 65530 and then lastly would be the assigned number. This is just something arbitrary to match on your customers, like customer 1.

7:29So here, the community would have to be target:65530:1. And the same community, target:65530:1, would have to exist on the other side. So you can see there's a little bit of complicated-- it gets tricky, right? There's a lot going on with MPLS layer 3 VPN. But this is how the traffic would be redistributed from one end to the other. The cool thing about the vrf-target command is we don't actually have to create export or import policies.

8:02We just simply say what the real target should be, and it does the rest for us. However, we still have that granular ability to only export specific prefixes, only import specific prefixes, and only match based on specific communities or add specific communities to it, if that's how we want to do it. So this wraps up how the route targets work. Now, it's time to start seeing the actual flow of traffic from one end to the next. In the next video, we're going to talk about how a prefix can be learned and sent across the topology, just to bring it all together.

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

0:00[AUDIO LOGO] So there's a lot that's gone into making an MPLS layer 3 VPN work. Now it's really time to talk about, how does traffic actually flow through an MPLS layer 3 VPN? There's two phases to this, if you ask me, so I'm breaking this down into basically two sets of videos. The first phase is how routes are actually shared from one provider edge to the others. This is the propagation of prefixes throughout the entire environment.

0:33We're not talking about how traffic flows at this point. We're just talking about how a prefix gets advertised from one PE all the way to the other. So let's talk about how routes are exchanged throughout our MPLS layer 3 VPN. So how does Customer 1 get its learned prefixes or shared prefixes all the way over to customer 2? How does it really work, end-to-end? Here's how we're going to go through it. We have IS-IS running in our core. We have LDP running on top of that. And then we have established multiprotocol BGP configurations and sessions between all of our neighbors.

1:07This looks and feels just like an IBGP relationship. But keep in mind, right now, at this point, PE1 can ping the loopback of PE2 using a label switch path. And therefore, my BGP relationship can be used, like so. So if I advertise any prefix to PE2 with next-hop-self and saying that my local address-- myself, at the end of the day-- is my loopback address, like 1.1.1.1, PE2 will see, in order to reach whatever that hop is, I need to reach 1.1.1.1.

1:45Therefore, I can label-switch it across the way. So think about it, like so. It's time to get 192.168.1 into the routing table over here on Site 2. We establish a VRF with a route distinguisher. I'm going to put 1.1.1.1:1. And a route target-- I'm just going to put T, for Target, 65530:1. We then establish an OSPF neighbor adjacency, and PE1 learns about 192.168.1.0 in its routing table.

2:22So it's going to have 192.168.1.0 in its routing table. Because we use route target, we used the VRF target command-- this is very important-- it will automatically take that route table and create a VPNv4 or IPv4-VPN, however you want to call it, and advertise it into multiprotocol BGP to its peer. This peer was a route reflector. So it reflects the route to this peer here, which is a route reflector. So it advertises that route towards PE2.

2:54But beyond that, I'm going to add a little mix into it. We also set next-hop-self. So PE2 now sees that it has learned about a VPNv4 prefix that can be reached from 1.1.1.1. With a tiny amount of extra configuration, which we're going to cover in more detail in the later videos, we can redistribute just the IPv4 prefix out towards Customer 1, who will then see the next hop as PE2. So this is how a prefix makes its way from one end to the next.

3:27The cool thing about it is how all of these different-- oh, I dropped my pen-- how all of these different technologies can work together to make this happen. We've got a VRF created to where we can privately exchange prefixes, or at least in a segmented way, between the customer and ourself. Multiprotocol BGP uses a route distinguisher to separate that prefix from all other prefixes that are traversing through the backbone. The extended community helps our receiving nodes to pull that prefix into the correct route table, into the correct VRF.

4:02And then we can share any of those prefixes out to the customer from there. When the customer's ready to send data back to us-- well, actually, you know what? That's what we're going to talk about in the next video, about how the MPLS and next-hop-selves really work. The idea is that we were now able to send the prefix across the backbone from one end to the next. So that's phase 1, getting a prefix from one customer to the other customer site. I should say from one customer site to the other customer site. Now when it's time for CE1-R2 to ping CE1-R1, how is that going to work?

4:36That's what the next video's all about. So this has been how the prefixes get exchanged from one end to the other. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Now that prefixes have been sent from one end to the other, and all of my provider edges know about all the possible ingress and egress points throughout the topology, it's time to talk about how a customer edge's packet-- when a customer sends a ping from one site to the other-- actually makes its way throughout the entire topology. So what we're going to do in this video is talk about how traffic will actually flow throughout the topology. Let's get going talking about how our MPLS layer 3 VPN will work from the perspective of our customers.

0:34So the routing tables of our customers are now populated. We've got prefixes going in one direction, carried by multiprotocol BGP, and now it's coming back. How does that ping look? Let's pretend for a moment that Customer 1 shared its 192.168.1 prefix, and let's pretend Customer 2 shared return traffic prefixes back in the same destination. So the prefixes have been exchanged, because multiprotocol BGP kept them distinguished. The route targets helped us import it into the correct routing table.

1:05And then, through a little bit of extra work, we were able to send those BGP-learned prefixes out to our customers, so they now have the route tables populated. This is pretty important to understand how a packet will actually flow from one end to the other. So let's pretend for a moment we've got a server over here on Site 2, and we've got Bob-- Bob still exists in Site 1. Bob is going to send traffic to the server, and the server's going to send responses back, correct? So the way this is going to look is Bob is going to send the traffic to his default gateway, which is Customer 1, R1.

1:41This traffic is destined for 192.168.2. So Customer 1, R1, is going to have to look up its route table for customer 192.168.2.0, which we learned, over MPLS layer 3 VPN. The default nature of OSPF is to change the next hop, is it not? So the next hop is going to say, hey, if you want to reach 192.168.2, send it to PE1. PE1 says, cool. I've got this packet now that I need to send to 192.168.2. But how did PE1 learn about that prefix?

2:12It learned about it from PE2 over multiprotocol BGP. And multiprotocol BGP-- there's a policy that updates next hop self. So PE1 sees the next hop as 2.2.2.2. And thanks to LDP, the packet can make its way there. Notice we're not performing any network address translation at this point. The source is still 192.168.1-- make up something like 10. The destination is still 192.168.2-- make up something like 10.

2:43But PE1 knows that its next hop to reach that, based on the BGP-learned prefix, was 2.2.2.2. And therefore, it's got a label push operation of-- make up something like 25530. That's a bad-looking 3. Let me fix that 3. There we go. So it goes through the MPLS process, where there's going to be a push of a label. There's going to be a swap of a label. Then there's going to be the penultimate hop pop of a label. And then it receives the naked packet, sourced from 192.168.1.0 destined for 192.168.2.0.

3:24But then that begs the question. You may be wondering, well, how does it know which VRF this should look up in? Very cool thing about multiprotocol BGP, route targets, and MPLS. Upon the creation of new routes and prefixes that get installed into a VRF, these devices create and advertise new-- There is some special magic that's happening here on P2 that we've kind of brushed over or glanced over, and that's how MPLS is really functioning under the hood.

3:55What's really happening is something called label stacking. Check this out. I've cleared the screen for just a moment so that we could focus in on the actual label switching path that's going from PE1 to PE2. Here's the real kicker. When PE2 receives a packet that's destined for its VRF, that packet's going to have a label in it specifically for that VRF. But that begs the question, PE2-- if they're running a VRF here, and a VRF here, and pretend I got another customer down here that's running a VRF, they're going to generate a label for each one of these VRFs.

4:30However, does P2 need to know about every single one of these labels in order to reach PE2? No, they actually don't. And this is why something special actually happens. What actually happens is label stacking. You see, when PE1 starts to generate its packet that it wants to send to P1 in the direction of PE2, it's actually going to perform a push-push operation. Do you remember that from your JNCIS studies?

5:01This is where we actually push two labels onto the actual packet that we're forwarding on behalf of customer 1. So if I were to draw it up, we would have an outer label-- let's make up something like 100-- here on the packet. And then it would have an inner label. Let's call this, I don't know, 3000, just to make something up again. Then it would have the rest of our data packet that goes on that way. So when PE1 sends the packet towards P1, P1 is going to look at 100 and say, ah, I know that I need to send that to the core.

5:32So it may perform a swap operation on the outer label not touching the inner label. You see, the inner label, this is what's destined for the VRF. So the core device here may perform another swap operation as it sends it onto PE2, and then this is where it gets pretty fancy. PE2 will be a penultimate hop pop, but only for the outer label. At this point, PE2 then sends the packet up towards PE2, still labeled with the inner label. And upon receipt of that, PE2 will go, oh, I see.

6:05This is for my VRF that is attached to the label 3000. And in this case, that one's going to be Customer 1's VRF. So what's really going to happen here is PE2 is going to signal towards its core devices what it wants to receive, or what it can advertise, potentially, as an outer label. And using multiprotocol BGP, it's going to signal what the inner label should be for the specific NLRIs that it's advertising. And PE1 will be aware that when it's trying to send a packet towards a specific VRF on a specific provider edge, it's going to need to add that VRF label.

6:42And then on the outside, it's going to need to add that provider edge label. So that way, these core devices can do the label switch path or label switching all the way to the provider edge, and then perform the penultimate hop pop. That way, the provider edge can look at it and go, oh, I see. This is for that specific VRF. So it's very important to understand, because this is used in multiple technologies. Not just layer 3 VPN, but also in certain types of layer 2 VPNs, as well. So now we see how MPLS and multiprotocol BGP can actually create a segmented VPN solution for our customers.

7:17They will see it as if they're just one hop away to reach their customer sites. And that's kind of the magic about it, is they don't have to implement nearly as much hardware or labor, and incur all of those additional costs in actually deploying a VPN. Now they can just contract with us, the service provider, and we can handle giving all of their traffic, in a segmented way, through our backbone in a private and virtual nature. So that's been the foundations of MPLS layer 3 VPNs, and how traffic actually flows from one end to the next.

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

0:05So now we've kind of brought it all together. We've talked about the different components that will make an MPLS Layer 3 VPN work. And then we talked about, through a couple different phases and a couple different examples, how it will actually work. We covered how the actual prefixes themselves, these IPv4-VPN prefixes, will be transmitted across the topology. And then we talked about how traffic will actually flow from customer edge to customer edge, from site to site, throughout our MPLS Layer 3 VPNs. In the next set of videos, we are going to make it work.

0:36We're going to jump on the command line, and actually deploy an MPLS Layer 3 VPN. Now spoiler-- we're going to repeat a lot of the things that we talked about throughout this set of videos, because again, these are big topics, and we need to make sure that we're on the same page. But now that we've laid a foundation, it's time to actually jump in, and make it come to life. So that's been understanding the MPLS Layer 3 VPN foundations. I hope this has been informative for you, and I'd like to thank you for viewing.