Understand the Components of MPLS L3VPN

0:00[MUSIC PLAYING]

0:05Look, I know, I know, I know you are excited about this.

0:08Because this is, the final exam.

0:11When we talk about MPLS VPNs, we're

0:14talking about the final exam.

0:16What do I really mean there?

0:17What I mean is you go through six months, a year,

0:20two years of studying many different topics

0:23in your service provider journey.

0:25And then you have a final exam, which

0:27is the culmination of everything that you study.

0:30Toss everything that you learned into a bucket,

0:32and that's what MPLS VPNs bring to the table.

0:35Now notice, I haven't said MPLS Layer 3 VPNs.

0:39That's because MPLS VPNs can allow you to do things

0:43at Layer 2 and Layer 3.

0:45It just so happens that most people begin their MPLS VPN

0:49journey with Layer 3 VPNs.

0:52It's not necessarily the easiest one to learn,

0:54but it does build the foundation of all

0:57of the different technologies that go into providing

1:00the service to customers.

1:02In MPLS VPNs-- not just Layer 3 VPNs again--

1:05you really bring everything to the table.

1:08You're going to have an IGP backbone.

1:10You're going to have MPLS, maybe even with traffic engineering.

1:14You're going to have Multiprotocol BGP,

1:16and understanding those BGP fundamentals.

1:19Then you're going to have things like routing instances

1:21and a lot of route policies.

1:23And it all is what crams into one thing

1:26to provide this incredibly useful and fun,

1:29and it's just-- it's just such cool technology.

1:32I'm just so excited about it, I can barely contain myself.

1:35But because there's so much going on in one technology,

1:39we're not going to try and cram it all into one skill.

1:42What we're really going to do is lay

1:44the foundation of how MPLS VPNs and MPLS Layer 3 VPN really

1:49works.

1:49What are all of the different moving parts

1:51that have to be coordinated?

1:53And we're going to take a little bit of a deep dive

1:55into some of those portions.

1:56How does this one particular type of tech really work?

2:00So we're going to talk about how MPLS Layer 3 VPNs really work.

2:04We're going to build the theory and talk about real-world use

2:07cases as we go along.

2:08Then in the next skill, we're going

2:10to talk about how to deploy an MPLS Layer 3 VPN from the Junos

2:15operating system.

2:16Now let me just go ahead and say right now,

2:18there are many, many, many, different variations,

2:20many different ways that you can deploy this.

2:22And that's why we're going to have additional content

2:25beyond that, when we talk about advanced MPLS Layer 3 VPNs.

2:29I guess what I'm trying to say here

2:30is understand now that, when it comes to deploying an MPLS

2:33VPN, even an MPLS Layer 3 VPN, this

2:36is something that's going to take

2:37some time, some repetition, some understanding.

2:40There's a lot going on here.

2:41And there are many different variations and styles

2:45that can be employed to actually deploying this.

2:47So it's going to take multiple skills and multiple sets

2:50of videos to actually understand how

2:52to deploy this incredible tech.

2:54So here we go.

2:55We're going to get started talking about what an MPLS

2:57VPN brings to the table and how we can get started deploying

3:01in MPLS Layer 3 VPN, all of the different tech

3:03that goes into it.

3:04Get ready as we start to design our MPLS Layer 3 VPN

3:08offering for our customers.

3:09Let's go.

0:05So what's the point of an MPLS VPN?

0:07How did they come to be?

0:08And why are they still employed today?

0:11What do they offer to the customer that's so nice?

0:14In this video, what we're going to talk about

0:16is why they exist, and why service providers offer them

0:19to their customers.

0:20Then we're going to talk about how we could

0:22start to see it in action.

0:24We're going to see it on a diagram,

0:25and see why MPLS VPNs are so special and so

0:29interesting to deploy.

0:30Let's get going talking about what MPLS VPNs bring

0:33to the table, and what you can expect to learn over

0:36the upcoming videos.

0:36Let's go.

0:37So when you talk about, what is the point of MPLS VPNs or MPLS

0:41layer 3 VPNs, it does beg the question,

0:43what is the point of a VPN in the first place?

0:46Why do customers want to use VPNs?

0:49Then we can transition a little bit

0:51into talking about why they would choose an MPLS

0:55VPN over something that they could deploy themselves,

0:58like an IPsec site-to-site VPN.

1:01So here's a topology that we're going

1:02to be working with over the next few sets of videos.

1:06This is going to be pretty much my MPLS VPN topology.

1:09We may add more prefixes to it.

1:11Sitting in the center of the white section, of course,

1:14we have our service provider.

1:16And then we've got two customers.

1:17We've color-coded these customers here.

1:20We've got a peachish, pinkish reddish customer,

1:23and then we've got a green customer.

1:25The whole idea here is that my customer, Customer 1--

1:28let's just pick on them--

1:29they want their users--

1:31let's just put like a little LAN here--

1:33to be able to securely talk over the internet

1:37or over a service provider's backbone to their other site

1:41here.

1:42So maybe they've got this customer here

1:43that's going to reach out to the internet,

1:45and this customer edge device here that's

1:47reaching out to the internet.

1:48But we want a server here to be able to serve

1:52our customer, or our end users, over here on this site.

1:56Not an uncommon scenario, is it, where we may have--

1:59Bob sits at his computer.

2:01He wants to access a file share that's located at HQ.

2:05This is a very common thing.

2:06But the kicker is now they have to do it in a secure manner.

2:10Would it be wise or advisable for us to just open port 445--

2:15that's SMB traffic-- to the public internet?

2:18That way, Bob could come along, and maybe

2:21he still has to authenticate or something, sure,

2:23with a username and password.

2:24But the point is Bob would be doing

2:26that over the public internet if we were just

2:29to open SMB up to the internet.

2:30No, we don't want to do this.

2:32This is bad.

2:33Of course, this is bad.

2:34The same for the big one.

2:35How many times have we seen RDP opened to the public internet,

2:39and a hacker just finds their way in?

2:41Maybe they fish out passwords, or they do some form

2:44of brute force attack.

2:45You get the idea.

2:47And now, they've RDPed into a terminal server, that's

2:50been opened to the internet.

2:51I personally have dealt with these scenarios with clients

2:55before.

2:55We tell them, don't do this, and this is the first thing

2:58they want to do.

2:58Oh, it'll never happen to us.

3:00Anyway, you get the point.

3:02The point is we need customers' traffic

3:05to be securely brought from one physical location to the other.

3:10This is the point of VPNs.

3:12We have this whole infrastructure here.

3:15This is a router here, and a router here, and a router here,

3:18and these prefixes have to get shared throughout.

3:20That way, our customer, one way or another,

3:23could reach the other site here, even if these

3:25are public IP addresses.

3:27So if I write V, P, and N here, let's explore the V.

3:31The V stands for Virtual.

3:34The idea here is that we are logically

3:37building a network on top of this physical backbone.

3:41Oftentimes, this is referred to as a fabric.

3:43So instead of the customer seeing this

3:45as they have to hop from here, to hop from here,

3:48to hop from here, to hop from here, to hop from here--

3:51no.

3:52Instead, the customer just wants to see it

3:54almost as if they have one direct subnet right here.

3:58This is sometimes referred to as a pseudo-wire, fake wire--

4:02so they believe that logically, they are directly

4:05connected by some sort of tunnel or some sort of direct subnet,

4:09because of the virtual nature of how this works.

4:13There are lots of technologies that

4:15can provide a virtual network from our customer to the other.

4:19But the P is where it starts to get tricky--

4:22Private.

4:23The idea here is that our customer

4:24wants to know that their traffic is perfectly isolated

4:28from other customers' traffic, that it's not

4:30using just the shared public infrastructure to do this.

4:34Sometimes, they can add their own privacy using

4:37encryption suites, like IPsec.

4:40But if they were to use something that's

4:41a little more plaintext, like layer 2 tunneling protocol,

4:44then they may be getting the virtual nature of their tunnel,

4:48but they're not getting the private nature of their tunnel.

4:50And this is where the private becomes a big deal.

4:53And then lastly, of course, this is a network.

4:55That one kind of goes without saying.

4:56So now we understand the use case for a VPN in general.

5:00The idea is I have traffic, like Bob's traffic here, that needs

5:04to reach my server over here.

5:06It needs to do this in a virtual, logical way.

5:10That way, we don't see the entire infrastructure

5:13of our service provider, or nay, the entire internet itself.

5:16We just want it to appear like we have a direct connection

5:19to our neighbor.

5:20But further, it has to be private.

5:22We want to be isolated from all of the other traffic that's

5:25out there on the internet.

5:27And further, if we can, we'd like

5:28to add encryption into the mix.

5:31And then, of course, this is a network.

5:32So a virtual private network isn't just

5:35seeing a logical tunnel from one end to the other.

5:38It's also keeping that privacy in play here.

5:41That's a very big deal.

5:42So customers, when they now realize

5:44that we need a virtual private network to reach--

5:47so that Bob can reach the server over here,

5:49they have a couple different options of creating a VPN.

5:54And I'm going to say this.

5:55I'm going to venture to say that the smaller the client,

5:58the more likely the client is to have

6:01a do-it-yourself deployment to virtual private networks.

6:05They may want to opt for a site-to-site IPsec VPN.

6:10This is where the customer deploys a firewall

6:13and just gets a public internet connection from the service

6:17provider.

6:17They deploy a firewall here, over on their own site here,

6:21and get a public internet connection

6:22from the same service provider or a different service

6:24provider.

6:25And then we point these firewalls towards each other,

6:29and they build a secure VPN tunnel.

6:33IPsec is just a phenomenal suite of technologies

6:37that go into play here.

6:38And of course, we're not going to get

6:40into building an IPsec tunnel.

6:42There are just a ton of different ways

6:43that you can learn about how to deploy IPsec tunnels here

6:46on CBT Nuggets.

6:47And yes, I am going to be working on the Juniper security

6:50track coming up, where you'll learn

6:52how to deploy IPsec tunnels on SRX-series firewalls.

6:55It's not here yet, but it will be on the way.

6:57That being said, if you're just curious about IPsec firewalls,

7:00you can learn about it in Network+, Security+,

7:04CCNP Security.

7:05You can learn about it in our Firepower content.

7:08You can learn about it in Palo Alto content.

7:09We've got IPsec content out the wazoo here at CBT Nuggets,

7:13and I'd encourage you to dig more into it.

7:15But this is the use case when the customer is looking

7:18for something maybe a little more affordable,

7:20and they want to do it themselves.

7:22That's what the IPsec site-to-site VPN is all about.

7:25What we, as a service provider, can do, though, is say, hey.

7:29Don't worry about handling all of that suite of protocols,

7:33buying new hardware, maintaining it yourself.

7:36You can just share to us the prefixes

7:40that you want to be sent from one site to the next,

7:43and we will handle tunneling it for you.

7:46This is where the MPLS layer 3 VPN, or the Layer 2 VPN,

7:53comes into play.

7:54With the MPLS layer 3 VPN, the customer

7:58will send us actual IPv4 prefixes

8:03that they want us to send across our topology

8:06towards their other site.

8:07So the customer here will just be able to look

8:09in their routing table, and they will see this other site's--

8:13all of the prefixes that they share, they'll see it there.

8:16And they know that the next hop is just punt it to the service

8:19provider, and they'll handle getting it the rest of the way

8:21there.

8:22The flip side of that is layer 2 VPN.

8:24With layer 2 VPN, the customer literally

8:26sees this as a layer 2 connection from one end

8:29to the other.

8:30If you're following along in your Juniper journey

8:33throughout CBT Nuggets, you've already

8:35seen a little bit of layer 2 VPN technology in action,

8:38haven't you, when you deployed q and q

8:40technologies as part of the JNCIS content

8:43here on CBT Nuggets.

8:44However, that didn't really use very much MPLS

8:46at the end of the day.

8:48What we're here to talk about now is MPLS technology.

8:51MPLS really flipped the script.

8:54It really changed how all of this stuff worked,

8:56and it enables us to do insanely cool things

9:00when you couple it with other technologies, like BGP.

9:04I don't want to get into this too much, because it will be

9:06overwhelming very, very fast.

9:08What I'm just trying to tell you right now

9:10is that MPLS solved problems for the service providers,

9:14especially in the late '90s and early 2000s.

9:17In the late '90s and the early 2000s,

9:19yeah, there was Ethernet and IPv4, but there was also ATM,

9:24and there was also frame relay.

9:26Those things-- you don't see ATM or frame relay much anymore.

9:31But what MPLS brought to the table

9:33was our ability to receive prefixes

9:36on one of these types of transports.

9:40And we were able to tunnel them across our entire network

9:44towards the other end.

9:46When we combine this with multiprotocol BGP,

9:49we were able to do this in such a way

9:52that it added a layer of segmentation.

9:54I don't want to say privacy, but it

9:57added a layer of segmentation that

9:59kept our customers' prefixes completely separate

10:03from our own prefixes or our other customers' prefixes.

10:07The end result by doing that was that we could use a subnet,

10:11like 10.1.1.0/24.

10:14Our customer could use a subnet, like 10.1.1.0/24.

10:19And then we could go get, or recruit,

10:21or sell to another customer, who also used 10.1.1.0/24.

10:26And it didn't matter if they used ATM, or frame relay,

10:29or Ethernet.

10:30We were able to handle all of it.

10:32MPLS layer 3 VPNs or layer 2 VPNs

10:36made us, as a service provider, super, super flexible.

10:40That's what it really brought to the table.

10:42And when we go to customers now, we can say,

10:45don't worry about building out your WAN infrastructure.

10:49We will do it for you.

10:50All you have to do is just peer to us,

10:53and we'll handle segmenting and sending your traffic

10:57from one end to the other.

10:58But beyond that, we can also add in SLAs into the mix.

11:01This is where we start to separate ourselves

11:03from a site-to-site VPN and just the public internet.

11:06Now we can also talk about things

11:08like bandwidth reservations.

11:09We can talk about things like uptime SLAs.

11:12We can make these guarantees that also add to our ability

11:15to provide unique services, and upsell ourselves

11:19a little bit to the customers.

11:20The customers love this type of thing.

11:22So they can have an internet connection,

11:24but they can also have a private connection to their other sites

11:27that are guaranteed with uptime and bandwidth reservations.

11:30Then we can do things like WAN traffic engineering,

11:33where we send our internet traffic outbound,

11:35or our site-destined traffic out towards the MPLS.

11:38This is where SD-WAN starts to come into play.

11:41So this has been understanding the point of VPNs,

11:44and how MPLS VPNs bring something unique to the table.

11:48It's all about offloading our customers' responsibilities

11:52onto us--

11:53that's pretty cool-- but keeping them segmented,

11:55and we remain flexible, regardless of the technologies

11:59that they want to tunnel.

12:00Let me say this now, too.

12:02We can tunnel basically anything that they

12:04want to do over MPLS now.

12:06We can tunnel things like IPv4 unicast, IPv4 multicast,

12:10IPv6 unicast, IPv6 multicast, and we can handle all of that

12:14through the magic of MPLS VPNs.

12:16Throughout this set of videos, we're

12:17going to talk fundamentally about how this works,

12:20how all of these things work.

12:21In the next set of videos, we're going

12:23to do a basic IPv4 unicast MPLS layer 3 VPN deployment.

12:28At that point, you'll be acclimated

12:30enough to how these technologies work to where you can start

12:33diving into the advanced MPLS VPN technologies

12:36and MPLS layer 2 VPN technologies.

12:38So this sets up what we're trying to do,

12:40what we're trying to bring to the table, what problem we're

12:43solving for our customer.

12:44Now it's time to talk about, how does it really work?

12:48That's been understanding the point of MPLS VPNs.

12:50I hope this has been informative for you,

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

0:05MPLS layer 3 VPNs all have to start somewhere,

0:09and this is where we start to, yeah, transition away from MPLS

0:12VPNs into MPLS layer 3 VPNs.

0:14So you're going to start somewhere.

0:15You're starting off from scratch.

0:17Maybe you're building a lab.

0:18Or maybe you're starting a brand new service provider

0:21up from scratch, and now you've offered MPLS layer 3 VPNs.

0:24What do you do first?

0:26The first thing that we have to do

0:27is we have to build our infrastructure backbone.

0:30This is going to be just our service provider transit

0:34network that's going to be carrying our customers'

0:36traffic.

0:37So this is going to be things like the IGP.

0:39This is going to be things like MPLS.

0:41And this is going to introduce multiprotocol BGP and how

0:46it is actually used in an MPLS layer 3 VPN environment.

0:49So let's keep going talking about the service provider

0:51backbone that's going to be used to actually carry

0:54the customers' transit traffic.

0:55Let's go.

0:56As a service provider, the thing that we want to do

0:58is provide excellent customer service.

1:01So we, oftentimes, are customer-first.

1:03However, in order to make an MPLS layer 3 VPN really work,

1:08we have to focus on ourselves first.

1:12None of this will work unless our backbone is actually

1:15deployed correctly.

1:16So we do have to focus on making sure these links

1:19and this design is formatted in just the way we want it to,

1:23and how it's going to behave the way we want it to,

1:25before we can start talking about how

1:27to get this router's traffic over to this router's traffic.

1:30So let's talk about the backbone components that make MPLS layer

1:343 VPN work.

1:35And this will be our first puzzle, our first building

1:38block into the entire deployment of MPLS layer 3 VPN.

1:42The first thing that you need to know about MPLS layer 3

1:44VPN, or really any MPLS VPN, is we

1:47deal with the concept of edges.

1:49Just like in Q-in-Q, or the stuff

1:51we covered in JNCIS service provider,

1:53we have provider edges and we have customer edges.

1:56So the real focusing point is we're

1:58trying to get traffic from this provider

2:00edge, our device, tunneled over to this provider edge.

2:05So what must happen-- what absolutely must happen

2:08is we must have end-to-end connectivity,

2:10and a suite of technologies work together to make this happen.

2:14So the first thing that has to happen

2:16is we have to have an IGP that is sharing all of our prefixes

2:22back and forth.

2:23And it's going to be absolutely critical that we make sure

2:25our loopback-- so I got to spell loopback correctly--

2:28L-O-P-- loopbacks are deployed throughout the IGP.

2:33Why?

2:33Because we're also going to be throwing MPLS into the mix

2:37so that it can support our multiprotocol BGP, or really,

2:42our IBGP neighborship adjacency.

2:46How does MPLS and MP-BGP play into the mix?

2:49Well, that's really what the rest of these sets of videos

2:52are all about.

2:53The point is, first things first, you

2:55have to deploy an IGP so that we see

2:58all of the possible routes within our topology.

3:02Then from there, we have to deploy

3:04some form of MPLS deployment.

3:08Of course, that leaves us with two options.

3:10We have LDP and RSVP.

3:13If you recall back in your studies, RSVP--

3:15we will have to manually create every single label switch

3:19path that would need to exist.

3:20In this case, what we're saying is

3:22we would need to create an LSP from every provider edge

3:26to every provider edge where a customer's traffic

3:30would need to traverse.

3:31So if I have Customer 1 here trying to reach Customer 1

3:35here, I would need to deploy an LSP from this PE to this PE.

3:40But also remember, with RSVP, we would

3:42need to make it bidirectional, or create a second LSP coming

3:47backwards.

3:48That's another part of RSVP.

3:49It's very deliberate.

3:50You have to tell it how to behave.

3:52Really, what I'm trying to say here

3:53is what oftentimes happens in a service provider's world is

3:56you end up deploying LDP no matter what.

3:59You may deploy RSVP to engineer specific subsets of traffic,

4:04and then deploy LDP on top of it,

4:06so that it could find a full mesh, so to speak,

4:09of how label switch paths would need to be created that way,

4:12because that really is the point of LDP, at the end of the day.

4:15It creates a full mesh of LSPs.

4:17Not necessarily neighbors, but LSPs.

4:20So basically, what I'm saying here is when it comes time

4:22to deploy MPLS layer 3 VPN, you're going to deploy in IGP.

4:27In my case, when it comes time to actually deploy this,

4:29I'm going to deploy IS-IS.

4:31I prefer IS-IS over OSPF for a few different reasons.

4:35First of all, I prefer LSP to use over LSAs.

4:38I also prefer the fact that IS-IS

4:40is built with the traffic engineering database enabled

4:43in carrying traffic by default.

4:45I also prefer the fact that it carries TLVs,

4:48instead of having to rely on the opaque LSAs.

4:50And I also like the fact that it's

4:52a very extensible and flexible protocol that

4:55doesn't have to have a backbone area in order

4:59to make this come to life.

5:00You could just deploy level 2 IS-IS everywhere,

5:02and it'd be just fine.

5:04Then in a small topology like this,

5:06I'm just going to deploy LDP.

5:08So with the IGP and with LDP to put in place,

5:12we now have the connectivity in place

5:15from our PE to PE to perform label

5:18switching through an LSP from loopback to loopback.

5:21The cool news then is it becomes very easy to deploy

5:25multiprotocol BGP.

5:28In basic demo environments, you may see this as something

5:31like a full mesh, like so, or you may just

5:34see this as this provider edge will have an IBGP connection

5:40directly to this provider edge.

5:42There's no reason not to do that,

5:44because the cool thing about MPLS

5:46is that none of these devices that sit in the path

5:49have to actually inspect the packet itself

5:51and make a forwarding decision, right?

5:53It can do that based on the label switch paths.

5:55However, it's not really a real world use case or real world

6:00scenario when it comes to actually deploying

6:03an MPLS layer 3 VPN, because it's never just

6:06as simple as one provider edge connecting to one provider

6:09edge.

6:10The customer may expand.

6:12And then we'll have a provider edge down here,

6:15and a provider edge down here, and then

6:17maybe a provider edge over here, and then

6:20maybe a provider edge over here, and then,

6:23oh, there's going to be a new site over here,

6:24and then you get the idea.

6:26There's provider edge, providers edge, provider edge.

6:28And then all of a sudden, what would

6:30have been just a simple connection from this provider

6:32edge to the next becomes a full mesh

6:35that looks something like this.

6:37And now we have to have this connectivity, like so.

6:40You get the idea this isn't scalable?

6:43So even though in many environments,

6:45you'll see a provider edge connected to a provider edge,

6:47like so, what really happens in the real world

6:50is your provider edges talk to route reflectors-- route

6:55reflectors.

6:56So that way, the routes can be reflected

6:59in every direction this way, and we

7:01don't have to maintain too many neighbor adjacencies.

7:05So kind of recapping how our backbone is going to look,

7:08we're going to have IS-IS, which allows

7:10us to have end-to-end IPv4 connectivity at layer 3.

7:14Then we have LDP, which allows us to perform label switching

7:19from one end to the other.

7:21Notice I didn't say this allows us to have neighbor adjacencies

7:24from one end to the other.

7:26This just allows us to send traffic from our provider edge

7:29to any other provider edge using label switching.

7:33That's kind of the idea here.

7:34Oh, I erased this.

7:36Let me undo.

7:36And then we deploy multiprotocol BGP on top of this.

7:41Why do we do multiprotocol BGP?

7:42We're going to talk a little bit more

7:44about that in the upcoming videos.

7:45It gets more interesting as we travel along.

7:49But the idea is that with multiprotocol BGP,

7:52now when we advertise prefixes into our environment

7:55and it gets reflected around, our Provider Edge 2 device

7:59can learn about routes through BGP,

8:02and it can see the next hop as the loopback of PE1

8:06using MPLS to reach that.

8:09And MPLS, of course, is supported by IS-IS.

8:12So the first thing that you need to know,

8:14before deploying MPLS layer 3 VPNs,

8:17is that your backbone is really going

8:19to consist of three tiers.

8:21There's going to be your underlying IGP, which is going

8:24to be used to facilitate MPLS.

8:27And MPLS is used to facilitate multiprotocol BGP.

8:32So prefixes that are shared by BGP

8:35will have a next hop address of the loopback address.

8:38That'll be label switched throughout the topology,

8:40and that label switching was really facilitated by your IGP.

8:44So this is understanding the construction

8:46of the backbone itself.

8:48Keep in mind it's going to go like a three-layered fabric--

8:51IGP, MPLS, multiprotocol BGP.

8:56How and why does that really work?

8:58It starts to get very interesting in the next video

9:00when we start to introduce the concept of VRFs,

9:03and how we actually tunnel our--

9:05traffic over that backbone.

9:07I'll see you there.

9:08I hope this has been informative for you,

9:09and I'd like to thank you for viewing.

0:05In the previous video, we talked a little bit

0:07about multiprotocol BGP.

0:09And this sets up the bigger conversation

0:12that there are many different components to making

0:15multiprotocol BGP work.

0:17So now we're going to shift our focus

0:19a little bit towards the connection between the provider

0:22edge and the customer edge, and how we can actually

0:25isolate that customer's particular traffic from all

0:29of our other customers.

0:30This is a bigger design topic to talk about.

0:32What we're really talking about here

0:34is a special type of routing instance called a VRF.

0:38So let's get going talking about how VRFs work,

0:41and how they start to feed into the discussion of multiprotocol

0:44BGP, and something really special here,

0:47the address family called IPv4-VPN--

0:50sometimes called VPNv4.

0:52Let's get going talking about how we isolate customers

0:54traffic with VRFs first.

0:56In our JNCIS service provider journey, and even

0:59a little bit in the JNCIA, we talked about something

1:02called routing instances.

1:04And the idea with routing instances

1:06was that we could take an interface, or an IP address,

1:09or a route and isolate it in its own route table.

1:13That way, it would not be impacted in the global unicast

1:16route table.

1:17If a route came in destined for it, then

1:20it would never be looking up in the global unicast

1:22routing table.

1:23It was a nice way to keep our traffic privately separated

1:27from other types of traffic that we wanted to support.

1:30But one of the things that we didn't really talk about

1:32was VRFs, Virtual Routing Forwarding instances.

1:37VRFs are a type of technology that

1:40are used in MPLS layer 3 VPNs.

1:43They're a type of routing instance.

1:45The idea is like so.

1:47When we have this customer--

1:50we're going to look at Customer 1 - Site 1.

1:51He's got a CE1-R1 router.

1:54And they want to connect over to Customer 1 - Site 2.

1:57And they want to do this in such a way

1:58that we will be able to privately and securely send

2:02their traffic over our backbone.

2:04But it will never accidentally get sent out towards Site 2

2:07or into our own network backbone 2.

2:10It needs to exist in its own route table.

2:14So your head instantly should go to routing instances.

2:17But one of the tricky things about this

2:19is, how do we actually get their routes--

2:22like they've got a bunch of different routes and prefixes

2:24over here--

2:25shared over to this customer over here?

2:29This is where we start to use multiprotocol BGP.

2:33Specifically, there is a type of IPv4 NLRI--

2:39Network Layer Reachability Information.

2:41It is a type of IPv4 address that

2:44carries additional information about that prefix itself.

2:48And the VRF instance type is where

2:52we set that additional info so that it can be carried

2:57from one end to the other.

2:58So when we create a VRF on this link right here,

3:03there are a couple different items

3:05that we set on this instance that

3:09help BGP understand who this traffic is really built for.

3:14So let's pretend for a moment that one of the LANs

3:16that my customer has is this 192.168.1.0.

3:20We have a customer, Bob, who needs to ping a server

3:24or reach a server on 192.168.1.0.

3:27So the first thing we do is we create a VRF specifically

3:31for that interface.

3:33This is the customer's own route table.

3:36On provider edge, this customer will get its own route table.

3:39And we want that customer to populate our route table.

3:43So we run an IGP, like OSPF, or we may even

3:48run EBGB between the customer and ourself,

3:51so they can send all of their prefixes to us.

3:54And in our route table-- let's just call this our C1 route

3:58table for Customer 1--

3:59their prefixes populate that route table.

4:02But the VRF has some extra capabilities,

4:05something called a Route Distinguisher,

4:08very frequently abbreviated RD, and a route target,

4:13very frequently abbreviated RT, that help our VRF

4:17work with multiprotocol BGP.

4:19So if I draw in pink multiprotocol BGP,

4:22when it comes time for PE1 to share that prefix over

4:27to PE2 so that they can share that prefix to CE1,

4:32we're going to let multiprotocol BGP be the one who

4:36carries that prefix.

4:38So multiprotocol BGP is going to be carrying 192.168.1.0/24 out

4:45of PE1 over to PE2.

4:47PE2 is going to receive 192.168.1,

4:50and then it has a decision to make.

4:52It has to figure out, well, wait a minute.

4:54Which customer is this for?

4:55Which prefix is this for?

4:57How do I know this is different from another 192.168.1

5:01that I may have received over a different VRF?

5:04The route distinguisher is the first thing

5:06that happens to make sure that 192.168.1

5:11is perfectly unique or distinguished

5:13from any other prefixes that may be coming in.

5:16For instance, maybe Customer 2 sends us a 192.168.1.0/24

5:23prefix, and it comes in over multiprotocol BGP, as well.

5:27So when we create our VRF, we tell this VRF,

5:30you are going to have a route distinguisher that--

5:32guess what--

5:33distinguishes the route as it arrives on our other provider

5:37edge devices.

5:38For simplicity's sake, let's just say I call this

5:42101:192.168.1.0/24.

5:50No, this is not how a route distinguisher is actually

5:53written.

5:54This is just to familiarize yourself

5:57with understanding how a prefix may look, or feel,

6:01as it's distinguished as it goes across the environment.

6:03Then, when this 192.168.1 comes in from customer 2,

6:08we may call this 202:192.168.1.0/24.

6:16Again, the whole point of the route

6:18distinguish-- it's just to distinguish a prefix

6:21from any other overlapping prefix that may come in

6:26over multiprotocol BGP.

6:28That's it.

6:29It doesn't tie this prefix to a customer.

6:31It doesn't tie this prefix to a specific VRF.

6:35All it does is distinguish the prefix

6:38as it flows across multiprotocol BGP.

6:41So now we've got two prefixes that arrive on PE2.

6:45We can see that they are the overlapping subnet,

6:48but they are distinguished from each other.

6:50We know that they are not the exact same prefix.

6:52How do we then know which VRF they belong to?

6:56This is what the route target does.

6:58The route target is almost like a route

7:01policy that identifies explicitly

7:04which VRF they belong to.

7:06Route targets are kind of a big topic,

7:08and they come in many different shapes and sizes on the Junos

7:12platform.

7:13You will see this much more in the next set of videos.

7:16Let's just say for this particular customer,

7:19we gave them a route target of 1111,

7:23and for this particular customer,

7:25we gave them a target of 2222.

7:28When the prefix arrives on PE2, it's

7:31VRF will have to also be configured with the same route

7:36targets of 1111 and 2222.

7:39And this sets up the conversation,

7:41kind of like a recap, of how this is all really

7:43going to work.

7:44Oh, let me bring it back.

7:45Yeah.

7:46So our customers are going to send us a prefix,

7:49192.168.1.0/24.

7:52Multiprotocol BGP is going to be what's

7:55used to advertise that prefix from one provider

7:59edge to the next provider edge.

8:01We use multiprotocol BGP, because multiprotocol BGP

8:06can carry the route distinguisher and the route

8:10target.

8:10Now I can officially say, this is not just IPv4.

8:15This is specifically an address family called IPv4-VPN.

8:21It is a type of IPv4 that is explicitly

8:24defined to use a route distinguisher and a route

8:27target.

8:27So as the same prefixes flows across multiprotocol BGP,

8:32the route distinguisher keeps them separate.

8:35Once they arrive on the provider edge,

8:37the provider edge determines which

8:40route table-- which VRF table it's

8:42allowed to be imported into, based on the route target.

8:46The matching route targets have to exist

8:48on both sides of the topology so that we

8:50know which routes can be exported

8:52and which routes can be imported.

8:54Again, I can't stress this enough.

8:56We were just highlighting a very basic way

8:59of how route distinguishers and route targets look and feel.

9:03This isn't how they are explicitly typed out,

9:06and this isn't how the prefix is actually mapped and sent

9:09across the entire topology.

9:10In the next video, we're going to dig

9:12deeper into how IPv4-VPNs really work

9:15and what the actual packet headers contain.

9:18This introduces how MPLS layer 3 VPNs really

9:22work after our backbone is established,

9:24and it's time to start building VRFs and carrying traffic

9:28throughout the topology.

9:29I hope this has been informative for you,

9:31and I'd like to thank you for viewing.

0:05So now we start to understand that VRFs

0:07are all about isolating, but also

0:10kind of like tagging our customers' traffic.

0:13And then multiprotocol BGP is truly multiprotocol.

0:17It carries VPN-style routes, VPN-style prefixes

0:22across the backbone to our other provider edges.

0:25Now we need to take a closer look at IPv4 VPN,

0:30or a lot of other vendors call this VPNv4.

0:33Let's take a closer look about how this address formatting

0:35really works and how route targeting really

0:38works at the end of the day.

0:40So let's take a closer look at these NLRIs,

0:42or Network Layer Reachability Indexes,

0:45and how the formatting really works to carry unique prefixes

0:49across the MPLS backbone.

0:51I'll see you there.

0:51So in the previous video, we introduced the concept

0:54that multiprotocol BGP wasn't just advertising IPv4 unicast

1:00prefixes throughout our topology.

1:03When we advertise a route that we received from the VRF,

1:08we're actually advertising an IPv4 VPN prefix

1:13throughout the topology.

1:14And one of the big things about it

1:16is that it carries additional information

1:19about how this actually works.

1:20So think about multiprotocol BGP, just by itself,

1:23before we even talk about VPNv4.

1:26When we talk about multiprotocol BGP,

1:28what is it advertising from one into the other?

1:31It's advertising IPv4 prefixes, is it not?

1:35And what do we know about those IPv4 prefixes?

1:38They are 32 bits long.

1:40It's just a subnet address, something like 192.168.1.0/24.

1:47But what do we also know about BGP advertisements?

1:50They advertise an NLRI--

1:53Network Layer Reachability Information.

1:55And this is a fancy way of saying

1:57there are additional attributes, and communities, and fun

2:02stuff attached to it that make this prefix somehow

2:05unique or distinguishable from other advertisements.

2:09Now what we're trying to do our objective

2:11is to use this idea, this technology that BGP

2:16brought to the table, but tweak it to do a little bit more.

2:20We want it to work specifically for our VRFs.

2:23And there's really a couple of things that happen here.

2:26We introduce a new protocol family.

2:28Just like how IPv4 unicast was a protocol family, now

2:32we introduce a protocol family called IPv4 VPN.

2:36And it really focuses in on the NLRI here for a second.

2:40It's all about carrying additional information.

2:44With IPv4 VPN, we can carry prefixes

2:48with additional information attached to it

2:51so that we know that it's part of a VRF,

2:53or so that we know that it's part of an MPLS VPN.

2:57So now what we do is we turn our attention

2:59a little bit to the header, and more specifically,

3:02the prefixes that are advertised in an NLRI.

3:05When we look at an IPv4 NLRI, we are

3:08going to look at the IPv4 prefix and the additional info

3:12about it.

3:13An NLRI in IPv4 VPN--

3:16basically, saying the IPv4 VPN prefix--

3:19is 96 bits long.

3:22At the end of the NLRI, we have our 32-bit prefix, just

3:27like this.

3:29But the first 64 bits are consumed by something

3:33called the route distinguisher.

3:36The route distinguisher is made up

3:37of three different pieces that are very important to know.

3:41And we're going to talk about the formats of these route

3:44distinguishers and what they do in the next video.

3:47The first piece of the 64 bits is the type field.

3:51This consumes 16 bits.

3:53And the remaining bits that go in here, it really depends

3:58on which type is selected.

3:59So it's not really fair to say what goes where.

4:02And you'll see why when we get to the next video.

4:05For now, know that there are two pieces that work here.

4:07The first piece is called the administrator,

4:10and the second piece is called the assigned number.

4:14So I'm going to put a little number sign here.

4:16And this is how you would actually read an IPv4 VPN NLRI.

4:21It would read something like this.

4:23There would be the type field, which

4:24would either be a 0 or a 1, so maybe something like a 1.

4:29Then you would have the administrator.

4:31This could be something like your autonomous system, 65530.

4:36Then you would have an assigned number, basically an arbitrary

4:39number that you could assign to a specific VRF

4:41or a specific customer.

4:42Maybe I'll say this is customer 1, so I'll put a 1 right here.

4:45Then the prefix that customer 1 is

4:48trying to advertise over to their other site, so

4:51something like 192.168--

4:54oh, got to write that dor there-- .1.0.

4:57Pretty nasty and hairy, right?

4:58We're going to get into more about the route distinguisher

5:00in the next video.

5:01I know I keep saying that, but it's

5:02important to understand what the real purpose of the route

5:06distinguisher is.

5:07It does nothing more than distinguishes

5:10a route as it travels through the multiprotocol BGP.

5:14The interesting thing about it is it doesn't necessarily

5:17attach it to a customer.

5:19When PE2 receives this advertisement,

5:22this route distinguisher doesn't automatically tell it

5:25which VRF it belongs to.

5:28Let me further illustrate why we need the route distinguisher,

5:30even though we're going to cover this in a lot

5:31more detail in the next video.

5:33Pretend for a moment we have our green customer,

5:35and they also want to advertise as same prefix.

5:39We're talking about an internal customer here.

5:41At the end of the day, they can run however

5:43many subnets they want.

5:45There's nothing to stop a red customer in Buffalo, New York,

5:49from running 192.168.1, and a green customer in New

5:53Orleans, Louisiana, from running 192.168.1

5:55in their internal networks.

5:57But they may want to contract with us for a VPN,

6:00and they want to send that network over our service

6:03provider backbone to get to their other site.

6:05Well, at some point, we're exporting our prefixes

6:08into BGP.

6:10So BGP needs a way to keep them separated as they

6:13travel through the network.

6:14And that's what the route distinguisher does.

6:16So perhaps here, the route distinguisher

6:19may look something like 1:65530:2,

6:23for customer 2, colon 192.168.1.0.

6:28And then PE2 would be able to receive both of these prefixes,

6:31knowing that they aren't the exact same prefix

6:34and that it needs to take further steps to figure out

6:37what VRF they belong in.

6:38Let me also go ahead and say this, too.

6:41The IPv4 VPN-- we've only talked about the NLRI,

6:44the advertised prefix, up until this point.

6:46But of course, there's more information

6:49carried in the header and the contents of the NLRI

6:52itself, too.

6:53There are communities.

6:54We even have the MPLS label.

6:56That's going to play a very important factor

6:58when it comes time to actually follow the packet flow through.

7:00There's a mask field set with it, as well.

7:03So the NLRI is just the advertised prefix,

7:05and it really consists of the route distinguisher

7:08and the prefix itself.

7:10The route distinguisher is made up

7:11of three important parts-- the type,

7:14the administrator, and the assigned numbers.

7:16But let's talk about what the route target is all about,

7:19now that we've got the route distinguisher settled.

7:21And the route target is an extended community

7:25carried by BGP.

7:26That's right.

7:27The route target is a community.

7:29Pretty interesting thing to differentiate between the route

7:32distinguisher and the route target,

7:34because when you jump onto the command line,

7:35they're going to look pretty similar to each other.

7:38However, the route distinguisher was

7:40used to actually build the header of the prefix itself.

7:44This is a way to differentiate the prefix itself

7:47as it flows across the traffic.

7:49The route target is what says, this is the community

7:53that we belong to.

7:54Therefore, this is the VRF that we belong to.

7:57So PE2 will be able to receive the prefix

8:01and look at it in a unique way, thanks

8:03to the route distinguisher.

8:04But it's not able to actually put that in a VRF

8:07until it examines the route target community.

8:10So this is how multiprotocol BGP really behaves,

8:14and where the VRF really starts to add additional functionality

8:19into multiprotocol BGP and extending

8:22what we already know about a prefix that we're learning.

8:24So now what we need to do is we need

8:26to actually look at a route distinguisher

8:28and actually look at a route target,

8:31and how those really behave when it comes time to configure it.

8:34Is your brain turning into mush yet?

8:35There's a lot of stuff going on-- some MPLS layer 3 VPN.

8:39And now you may see why we're not jumping onto the command

8:41line just yet.

8:43So this has been identifying what IPv4 VPN really is.

8:48It is a unique address family that

8:50extends a prefix that we already know

8:53by adding a route distinguisher into the header,

8:56and also carrying extended communities

8:58in multiprotocol BGP.

9:00I hope this has been informative for you,

9:02and I'd like to thank you for viewing.

0:05Now we understand how VRFs and IPv4

0:09VPN can be used to actually carry traffic

0:12across the backbone.

0:13We need to explore now how the route distinguisher

0:16format actually looks.

0:18This is something you need to know when it comes time

0:21to actually start configuring routes distinguishers

0:23on your command line.

0:25There's two different styles of formatting

0:27for route distinguishers, so let's

0:28explore how we can actually write our route distinguisher

0:31and how that will impact how prefixes are

0:34carried across our topology.

0:36I'll see you there.

0:36In the previous video, we introduced

0:38the route distinguisher component of a total IPv4 VPN

0:45header.

0:46Again, like I say, many other vendors call this VPNv4.

0:49But I'm going to call it IPv4 VPN for the most

0:51part, because that's what you're actually

0:53going to see on a command line.

0:54So we had mask.

0:56We had the MPLS label.

0:58Then we had the route distinguisher.

1:00And then we have the prefix itself.

1:02What we're going to do is we're going

1:03to focus in on the route distinguisher

1:05now, because there are two types of formats

1:09that you can use to write your route distinguisher.

1:11And there's no real wrong or right way to do it.

1:15However, there is kind of a best practices

1:17or what you're most likely to run into in the real world.

1:20I'm going to write it out like this.

1:21We have the type field.

1:23And I'm going to tell you right now,

1:25type determines the actual format

1:28that you're going to write for your administrator field

1:31and your assigned number field.

1:34There are two options for type.

1:36There is type 0 and there is type 1.

1:39Let's talk about type 0.

1:41The format for the type 0 field is written like so.

1:44In the admin field, you write the BGP autonomous system

1:50number.

1:50Then there's a colon.

1:52Then you just assign an arbitrary number

1:55for your customer.

1:56Maybe you want to use a customer ID that's in a database,

2:00or you just come up with a number.

2:02So in this case, for customer 1, I'll simply put 1.

2:05So if I were using type 0, my route distinguisher field--

2:09actually, my entire prefix--

2:11could look something like this.

2:12I'm erasing things.

2:15It could look something like a mask of--

2:18put 00 just to fill up some space.

2:21Then the MPLS label, which could be something like 23358.

2:24The type field would be 0.

2:29The admin field would be 65530, if I'm looking right here

2:34at my service provider drawing.

2:36Then colon 1, then it would read like this--

2:41colon then my prefix that is being advertised.

2:46The cool part about this is when it comes time

2:48to actually configure a route distinguisher on your VRF,

2:52you only have to type in this part right here.

2:55It'll automatically be able to--

2:57that it's type 0, because of the format that you typed it in.

3:00MPLS will be doing its own MPLS label switch thing.

3:03And the mask is going to be set automatically.

3:05The prefix is going to be handled

3:07based on the VRF advertisement, when we talk about how

3:10to handle route targets.

3:12For the most part, what we're focused in on right

3:14now is the format of the route distinguisher, which

3:17was this block right here.

3:19So if you choose to do a type 0 formatting,

3:22you will specify the ASN, followed by an arbitrary

3:26number, and Junos will automatically able to tell

3:29that that is a type 0 format.

3:31However, this is not what's deployed most often,

3:34or at least that's not been my experience.

3:36What's deployed more often is the type 1 prefix.

3:40If I clear the screen, let's do this.

3:42The type 1 prefix is written like so.

3:45The admin number is actually the router ID

3:49for the device itself.

3:51So this could be 1.1.1.1.

3:54Then the assigned number-- it's going

3:56to go colon and then the assigned number, which

3:58is going to be, again, just an arbitrary number that you

4:02assign for the customer.

4:03Then it would go colon prefix at this point.

4:06So the interesting thing about this

4:08is it's really just about keeping prefixes unique as they

4:12come in from an environment.

4:14So consider this hypothetically for a moment.

4:16Customer 1 advertises 192.168.1 inbound.

4:19We create a VRF, and we give it the route distinguisher

4:23of 1.1.1.1 colon 1.

4:26Then we create a VRF for Customer 2.

4:29We give it the droute distinguisher

4:31of 1.1.1.1 colon 2.

4:34If both of these customers advertise 192.168.1.0/24

4:41inbound, we can immediately see how these routes would be

4:45distinguished as they flow across BGP.

4:48PE2 would be able to receive two NLRIs--

4:52one that would look like 1.1.

4:53I've got to write a better one than that--

4:551.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,

5:14I have received two unique prefixes

5:17that we could examine further inbound.

5:20With these two prefixes now installed

5:22in a special BGP table just for MPLS layer 3 VPN,

5:26it can examine the extended communities, looking

5:29for the route target to determine which

5:31VRFs it needs to belong to, and then advertise those out

5:35to the customer that way.

5:37The flip side is when traffic is coming

5:39to return inbound from PE2.

5:41We can use a route distinguisher here

5:43of 2.2.2.2:1 and 2.2.2.2:2.

5:51The route distinguisher does not need

5:53to match on both sides for each customer.

5:57The route target is what determines which customers VRF

6:01gets the traffic.

6:02And that's what's important, and that's

6:03what we're going to talk about more in the next video.

6:06The route distinguishers simply exist

6:09to keep a prefix unique as it traverses the backbone from one

6:13provider edge to the next.

6:15So this has been understanding the formats of the route

6:18distinguisher.

6:18There's two formats, type 0 and type 1.

6:21In my examples, we're going to be using the type 1

6:24format as we progress forward.

6:26That is the router ID followed by an arbitrary number.

6:29So that's been understanding the route distinguisher.

6:31I hope this has-- informative for you,

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

0:00[MUSIC PLAYING]

0:05Route targets are what are used by the devices

0:08to actually determine which VRF they're allowed to export

0:12or import prefixes into.

0:14This is going to be a huge one.

0:16This is really what makes MPLS layer 3 VPNs work

0:19at the end of the day.

0:20Now, there's a couple different implementation styles

0:23that you can take when it comes to VRF targets, or VRF route

0:27targets.

0:28So let's talk about how VRF targets

0:30work on the Junos command line.

0:32And then when it comes time, we'll

0:33be able to implement this much smoother.

0:35I'll see you there.

0:36So now its time to explore the route target, because this

0:39is where we really got to start tying in how the VRFs really

0:44work and how prefixes actually make their way from one

0:48customer router all the way to the other customer router.

0:51That is the goal at the end of the day is for this customer

0:55to advertise their LAN side prefixes to us,

0:59and this router over here sees those LAN side prefixes.

1:03So that way they know, oh, if I want to reach a device over

1:06here, my next hop is just into my provider,

1:08and then it just gets handled that way.

1:10So we see now that the idea is we

1:12create a VRF that the customer can then use, like OSPF,

1:15to advertise prefixes to us.

1:18We then build a BGP-style tunnel,

1:21where we take that prefix and turn it into an IPv4 VPN prefix

1:28based on the fanciness of the route distinguisher.

1:31But this is still BGP at the end of the day.

1:33And BGP has the ability to carry all sorts of additional info

1:39about prefixes that we really need.

1:42The route distinguisher was not sufficient enough

1:45to tell us which VRF that this belongs to.

1:47All it did was just make sure that this prefix

1:51that the customer advertised in was unique.

1:54So that way, if another customer advertised a prefix into us,

1:58BGP would just see it as a unique prefix.

2:01There was no data involved with that

2:03that said this belong to customer 1 or this belonged

2:05to customer 2.

2:06So we had to create an extended community

2:09as part of MPLS layer 3 VPN that actually carried

2:13the specific information that tells our devices what customer

2:18and which VRF they belong to.

2:21This was called the route target.

2:23And this was pretty important to understand.

2:25Route targets behave in a couple different ways.

2:28I'm first going to talk about the simplest form of a route

2:31target.

2:32We have a customer called customer 1.

2:34Let's just call them customer 1 at least for simplicity's sake.

2:37When we create a VRF here on this particular interface

2:41and we start receiving prefixes in,

2:43we need to make sure that those routes are identified

2:47specifically for customer 1.

2:48So as they make their way across the backbone,

2:51yeah, they're distinguished from other prefixes,

2:54but they're not distinguished to the point

2:55to where we know they're customer 1.

2:57So we create a route target.

2:59I'm going to, for simplicity's sake,

3:01call this C1 for customer 1 right now.

3:05So you can imagine in the extended community,

3:07we're carrying a value of C1.

3:10That's not exactly what's happening here.

3:12This is just to show you how it works.

3:14Then on PE2, on this VRF, I'm also

3:18going to create a route target also called C1.

3:22So that way, when multiprotocol BGP sends a prefix over here

3:26to PE2, it can look at the extended community.

3:29And it can say like, oh, I see, there's a C1 here.

3:32Therefore, it must belong to my VRF

3:36where I've assigned a route target of C1.

3:39You can see how now this really is a target.

3:42We're saying, I want you to target

3:45the VRF that's been named C1.

3:48That's how we're going to call this.

3:50Now, on the Junos devices, there are a couple different ways

3:54to implement route targets.

3:55The easiest one is to actually use the command vrf-target.

4:01And it does exactly what we just described it did.

4:04For instance, if I create this VRF,

4:06and I use the command vrf-target--

4:09and just for simplicity's sake, again, this

4:11is not how its really going to look.

4:13I'm going to call this C1--

4:14this will automatically, and I can't stress this enough,

4:18this will automatically take all of the prefixes that

4:22are in this VRF whether they're locally attached, because we're

4:26directly connected, or we learn them from something like OSPF,

4:30and it will automatically send them into multiprotocol BGP.

4:36And it will automatically have the extended community

4:40of C1 attached to it.

4:42Again, there's no export policy here.

4:45There is no import policy here.

4:47There's no telling it export specific prefixes.

4:50There's no telling it add this extended community.

4:52It just automatically does it.

4:54And as long as over here on customer 2

4:57we created a VRF with the command, vrf-target C1,

5:02it will automatically import those prefixes

5:06with the same vrf-target, into the VRF.

5:09And then the flip side would happen too.

5:11Any directly connected prefixes here,

5:14and any learned prefixes via OSPF,

5:17as long as we have this vrf-target set,

5:20it's going to send it into multiprotocol BGP.

5:23This is by far the easiest way to implement MPLS layer 3 VPN.

5:28But just know, that it is a catch all, send all situation.

5:33It says, anything that's in this route table, send it that way.

5:36And if you receive anything with the same target,

5:39import it into the route table.

5:41So this is the first type of route target.

5:43And that's using the vrf-target command.

5:45Now, the second type of route target

5:47is explicitly using an import or an export policy.

5:53In the import and export policy, you will tell it specifically

5:57which prefixes to match on and specifically which

6:01extended community to add.

6:04So maybe we only want to send 192.168.1.0.

6:09So we create a route policy with a route filter

6:13that matches that prefix.

6:14And in our then statement, we use community add.

6:20Again, we're talking about culminating all of the things

6:24that we learned until this point.

6:25So if you haven't watched the BGP content

6:27on how to actually add communities and match prefixes,

6:31you'll want to go back and watch that BGP content,

6:33because this is the other way that you

6:35would use route targets.

6:37You would explicitly match the prefixes

6:39and explicitly add the extended community onto that.

6:42Now, the format of the actual route target

6:44itself, this is interesting.

6:46In the Junos CLI, because we're talking

6:49about extended communities, the target

6:52has a pretty unique syntax.

6:54It's a little bit different from other vendors.

6:56It has the syntax with the word target.

7:00It literally starts out with target.

7:02You write target, and then the name will start with target.

7:05This tells the Junos CLI and the Junos operating system

7:10that this extended community belongs in the route target.

7:14Then, the best practice here is to use the autonomous system

7:18number.

7:19So here we would put something like 65530

7:22and then lastly would be the assigned number.

7:25This is just something arbitrary to match on your customers,

7:28like customer 1.

7:29So here, the community would have to be target:65530:1.

7:37And the same community, target:65530:1,

7:43would have to exist on the other side.

7:45So you can see there's a little bit of complicated--

7:47it gets tricky, right?

7:48There's a lot going on with MPLS layer 3 VPN.

7:52But this is how the traffic would be redistributed

7:54from one end to the other.

7:56The cool thing about the vrf-target command

7:58is we don't actually have to create export or import

8:01policies.

8:02We just simply say what the real target should be,

8:05and it does the rest for us.

8:07However, we still have that granular ability

8:10to only export specific prefixes,

8:12only import specific prefixes, and only

8:15match based on specific communities

8:17or add specific communities to it,

8:19if that's how we want to do it.

8:21So this wraps up how the route targets work.

8:23Now, it's time to start seeing the actual flow of traffic

8:26from one end to the next.

8:27In the next video, we're going to talk

8:29about how a prefix can be learned

8:30and sent across the topology, just to bring it all together.

8:34I hope this has been informative for you,

8:35and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:05So there's a lot that's gone into making an MPLS layer 3 VPN

0:09work.

0:10Now it's really time to talk about,

0:11how does traffic actually flow through an MPLS layer 3 VPN?

0:17There's two phases to this, if you ask me,

0:19so I'm breaking this down into basically two sets of videos.

0:23The first phase is how routes are actually

0:26shared from one provider edge to the others.

0:29This is the propagation of prefixes

0:31throughout the entire environment.

0:33We're not talking about how traffic flows at this point.

0:35We're just talking about how a prefix gets advertised from one

0:38PE all the way to the other.

0:40So let's talk about how routes are

0:41exchanged throughout our MPLS layer 3 VPN.

0:44So how does Customer 1 get its learned prefixes

0:48or shared prefixes all the way over to customer 2?

0:52How does it really work, end-to-end?

0:54Here's how we're going to go through it.

0:56We have IS-IS running in our core.

0:59We have LDP running on top of that.

1:02And then we have established multiprotocol BGP

1:04configurations and sessions between all of our neighbors.

1:07This looks and feels just like an IBGP relationship.

1:11But keep in mind, right now, at this point,

1:13PE1 can ping the loopback of PE2 using a label switch path.

1:20And therefore, my BGP relationship

1:23can be used, like so.

1:24So if I advertise any prefix to PE2 with next-hop-self

1:31and saying that my local address--

1:33myself, at the end of the day-- is my loopback address,

1:37like 1.1.1.1, PE2 will see, in order

1:40to reach whatever that hop is, I need to reach 1.1.1.1.

1:45Therefore, I can label-switch it across the way.

1:48So think about it, like so.

1:50It's time to get 192.168.1 into the routing table over here

1:56on Site 2.

1:57We establish a VRF with a route distinguisher.

2:01I'm going to put 1.1.1.1:1.

2:05And a route target--

2:07I'm just going to put T, for Target, 65530:1.

2:13We then establish an OSPF neighbor adjacency,

2:16and PE1 learns about 192.168.1.0 in its routing table.

2:22So it's going to have 192.168.1.0

2:26in its routing table.

2:27Because we use route target, we used the VRF target command--

2:31this is very important-- it will automatically

2:33take that route table and create a VPNv4 or IPv4-VPN,

2:40however you want to call it, and advertise it

2:42into multiprotocol BGP to its peer.

2:45This peer was a route reflector.

2:47So it reflects the route to this peer

2:49here, which is a route reflector.

2:51So it advertises that route towards PE2.

2:54But beyond that, I'm going to add a little mix into it.

2:57We also set next-hop-self.

2:59So PE2 now sees that it has learned

3:02about a VPNv4 prefix that can be reached from 1.1.1.1.

3:08With a tiny amount of extra configuration, which

3:11we're going to cover in more detail in the later videos,

3:13we can redistribute just the IPv4 prefix out

3:18towards Customer 1, who will then see the next hop as PE2.

3:22So this is how a prefix makes its way

3:25from one end to the next.

3:27The cool thing about it is how all of these different--

3:29oh, I dropped my pen-- how all of these different technologies

3:32can work together to make this happen.

3:34We've got a VRF created to where we can privately

3:38exchange prefixes, or at least in a segmented way,

3:42between the customer and ourself.

3:44Multiprotocol BGP uses a route distinguisher

3:48to separate that prefix from all other prefixes that

3:52are traversing through the backbone.

3:53The extended community helps our receiving nodes

3:57to pull that prefix into the correct route table,

4:00into the correct VRF.

4:02And then we can share any of those prefixes

4:05out to the customer from there.

4:06When the customer's ready to send data back to us--

4:09well, actually, you know what?

4:09That's what we're going to talk about in the next video,

4:12about how the MPLS and next-hop-selves really work.

4:15The idea is that we were now able to send

4:17the prefix across the backbone from one end to the next.

4:21So that's phase 1, getting a prefix

4:24from one customer to the other customer site.

4:26I should say from one customer site

4:28to the other customer site.

4:29Now when it's time for CE1-R2 to ping CE1-R1,

4:35how is that going to work?

4:36That's what the next video's all about.

4:38So this has been how the prefixes get exchanged

4:41from one end to the other.

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

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

0:00[AUDIO LOGO]

0:05Now that prefixes have been sent from one end to the other,

0:08and all of my provider edges know about all the possible

0:11ingress and egress points throughout the topology, it's

0:14time to talk about how a customer edge's packet--

0:17when a customer sends a ping from one site to the other--

0:20actually makes its way throughout the entire topology.

0:22So what we're going to do in this video

0:24is talk about how traffic will actually

0:26flow throughout the topology.

0:28Let's get going talking about how our MPLS layer 3

0:31VPN will work from the perspective of our customers.

0:34So the routing tables of our customers are now populated.

0:37We've got prefixes going in one direction, carried

0:40by multiprotocol BGP, and now it's coming back.

0:42How does that ping look?

0:44Let's pretend for a moment that Customer 1 shared its 192.168.1

0:48prefix, and let's pretend Customer 2 shared return

0:52traffic prefixes back in the same destination.

0:55So the prefixes have been exchanged,

0:58because multiprotocol BGP kept them distinguished.

1:01The route targets helped us import it

1:03into the correct routing table.

1:05And then, through a little bit of extra work,

1:07we were able to send those BGP-learned prefixes out

1:12to our customers, so they now have

1:13the route tables populated.

1:15This is pretty important to understand

1:17how a packet will actually flow from one end to the other.

1:20So let's pretend for a moment we've got a server over here

1:24on Site 2, and we've got Bob--

1:27Bob still exists in Site 1.

1:29Bob is going to send traffic to the server,

1:31and the server's going to send responses back, correct?

1:33So the way this is going to look is

1:36Bob is going to send the traffic to his default gateway, which

1:39is Customer 1, R1.

1:41This traffic is destined for 192.168.2.

1:44So Customer 1, R1, is going to have to look up its route

1:47table for customer 192.168.2.0, which we learned,

1:52over MPLS layer 3 VPN.

1:54The default nature of OSPF is to change the next hop, is it not?

1:58So the next hop is going to say, hey,

2:00if you want to reach 192.168.2, send it to PE1.

2:04PE1 says, cool.

2:05I've got this packet now that I need to send to 192.168.2.

2:09But how did PE1 learn about that prefix?

2:12It learned about it from PE2 over multiprotocol BGP.

2:16And multiprotocol BGP-- there's a policy

2:19that updates next hop self.

2:21So PE1 sees the next hop as 2.2.2.2.

2:25And thanks to LDP, the packet can make its way there.

2:29Notice we're not performing any network address translation

2:32at this point.

2:33The source is still 192.168.1--

2:37make up something like 10.

2:38The destination is still 192.168.2--

2:42make up something like 10.

2:43But PE1 knows that its next hop to reach that,

2:47based on the BGP-learned prefix, was 2.2.2.2.

2:51And therefore, it's got a label push operation of-- make up

2:55something like 25530.

2:57That's a bad-looking 3.

2:58Let me fix that 3.

2:59There we go.

3:00So it goes through the MPLS process,

3:03where there's going to be a push of a label.

3:06There's going to be a swap of a label.

3:08Then there's going to be the penultimate hop pop of a label.

3:13And then it receives the naked packet,

3:15sourced from 192.168.1.0 destined for 192.168.2.0.

3:24But then that begs the question.

3:25You may be wondering, well, how does it know which

3:27VRF this should look up in?

3:29Very cool thing about multiprotocol BGP, route

3:34targets, and MPLS.

3:36Upon the creation of new routes and prefixes

3:39that get installed into a VRF, these devices

3:43create and advertise new--

3:46There is some special magic that's

3:48happening here on P2 that we've kind of brushed over

3:51or glanced over, and that's how MPLS is really

3:54functioning under the hood.

3:55What's really happening is something

3:57called label stacking.

3:58Check this out.

3:59I've cleared the screen for just a moment

4:01so that we could focus in on the actual label switching path

4:04that's going from PE1 to PE2.

4:07Here's the real kicker.

4:08When PE2 receives a packet that's destined for its VRF,

4:13that packet's going to have a label in it

4:15specifically for that VRF.

4:18But that begs the question, PE2--

4:20if they're running a VRF here, and a VRF here,

4:23and pretend I got another customer down here that's

4:25running a VRF, they're going to generate a label

4:28for each one of these VRFs.

4:30However, does P2 need to know about every single one

4:35of these labels in order to reach PE2?

4:39No, they actually don't.

4:40And this is why something special actually happens.

4:43What actually happens is label stacking.

4:46You see, when PE1 starts to generate its packet that it

4:50wants to send to P1 in the direction of PE2,

4:53it's actually going to perform a push-push operation.

4:58Do you remember that from your JNCIS studies?

5:01This is where we actually push two labels

5:04onto the actual packet that we're forwarding

5:06on behalf of customer 1.

5:08So if I were to draw it up, we would have an outer label--

5:11let's make up something like 100--

5:14here on the packet.

5:15And then it would have an inner label.

5:17Let's call this, I don't know, 3000, just

5:20to make something up again.

5:21Then it would have the rest of our data packet

5:23that goes on that way.

5:24So when PE1 sends the packet towards P1,

5:27P1 is going to look at 100 and say, ah, I

5:30know that I need to send that to the core.

5:32So it may perform a swap operation

5:34on the outer label not touching the inner label.

5:37You see, the inner label, this is what's destined for the VRF.

5:40So the core device here may perform another swap operation

5:44as it sends it onto PE2, and then this

5:46is where it gets pretty fancy.

5:48PE2 will be a penultimate hop pop,

5:51but only for the outer label.

5:54At this point, PE2 then sends the packet up towards PE2,

5:59still labeled with the inner label.

6:01And upon receipt of that, PE2 will go, oh, I see.

6:05This is for my VRF that is attached to the label 3000.

6:09And in this case, that one's going to be Customer 1's VRF.

6:12So what's really going to happen here

6:14is PE2 is going to signal towards its core devices

6:17what it wants to receive, or what it can advertise,

6:20potentially, as an outer label.

6:22And using multiprotocol BGP, it's

6:25going to signal what the inner label should

6:27be for the specific NLRIs that it's advertising.

6:30And PE1 will be aware that when it's

6:33trying to send a packet towards a specific VRF

6:37on a specific provider edge, it's

6:39going to need to add that VRF label.

6:42And then on the outside, it's going

6:43to need to add that provider edge label.

6:46So that way, these core devices can do the label switch path

6:49or label switching all the way to the provider edge,

6:52and then perform the penultimate hop pop.

6:54That way, the provider edge can look at it and go, oh, I see.

6:57This is for that specific VRF.

6:59So it's very important to understand,

7:00because this is used in multiple technologies.

7:03Not just layer 3 VPN, but also in certain types of layer 2

7:07VPNs, as well.

7:08So now we see how MPLS and multiprotocol BGP

7:12can actually create a segmented VPN solution for our customers.

7:17They will see it as if they're just one hop away

7:20to reach their customer sites.

7:21And that's kind of the magic about it,

7:23is they don't have to implement nearly as much hardware

7:27or labor, and incur all of those additional costs

7:30in actually deploying a VPN.

7:32Now they can just contract with us, the service provider,

7:35and we can handle giving all of their traffic,

7:37in a segmented way, through our backbone

7:40in a private and virtual nature.

7:42So that's been the foundations of MPLS layer

7:443 VPNs, and how traffic actually flows from one end to the next.

7:48I hope this has been informative for you,

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

0:05So now we've kind of brought it all together.

0:07We've talked about the different components that will

0:10make an MPLS Layer 3 VPN work.

0:12And then we talked about, through a couple

0:14different phases and a couple different examples,

0:16how it will actually work.

0:18We covered how the actual prefixes themselves,

0:21these IPv4-VPN prefixes, will be transmitted

0:25across the topology.

0:26And then we talked about how traffic will actually

0:28flow from customer edge to customer edge,

0:31from site to site, throughout our MPLS Layer 3 VPNs.

0:34In the next set of videos, we are going to make it work.

0:36We're going to jump on the command line,

0:38and actually deploy an MPLS Layer 3 VPN.

0:40Now spoiler-- we're going to repeat a lot of the things

0:43that we talked about throughout this set of videos,

0:45because again, these are big topics,

0:47and we need to make sure that we're on the same page.

0:49But now that we've laid a foundation,

0:50it's time to actually jump in, and make it come to life.

0:53So that's been understanding the MPLS Layer 3 VPN foundations.

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

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