[MUSIC PLAYING]
So now that we've discussed all of the components
necessary to support these additional applications
on MPLS, let's go ahead and start talking about some
of those additional applications.
We'll begin by talking about VPNs.
Now, as we mentioned a little bit earlier,
we do, in fact, support both Layer 2 and Layer 3 VPNs.
And in this video, we're going to get an introduction to VPNs.
Now, keep in mind as we go through here,
this is just getting us familiar with the concept of how
these work, and a little bit of their attributes.
We have full skills coming up on both Layer 2 and Layer 3
VPNs in this domain.
So again, keep in mind as we jump in here,
that this is just an introduction
to the overall idea.
On that note, let's go ahead and jump in, and take a look
at that overview.
So let's begin our discussion of MPLS VPNs
by talking about the attributes of Layer 2 VPNs.
So the first is, these offer a more traditional type
WAN connection.
Essentially, what this is going to look like to the customer--
if they have two remote routers, and they're
connected with a Layer 2 VPN, that Layer 2 VPN
is ultimately just going to look like an Ethernet
connection between them.
So if they were running something, for example,
like OSPF, their routers would become neighbors
with each other.
The entire transport looks like one big Ethernet cable.
One of the main reasons this is advantageous
for the customer is, again, this is very, very similar
to traditional WAN services.
In other words, they're familiar with this.
Now, technically, this encapsulation
can either be the same or different on each end.
Now, the example I just drew is showing Ethernet on both sides.
What we're saying here is maybe one side could be Ethernet.
The other side could be something like frame relay.
It doesn't matter what the actual encapsulation is.
The point is, there's no routing in the middle.
The devices will look like they're directly connected.
Now, very commonly, this is going
to be used to carry Ethernet.
But as I just said, some of those legacy encapsulations,
like possibly frame relay, or even ATM,
can still be supported.
Now, one of the main defining characteristics
here of the Layer 2 VPN is we don't have any Layer
3 with the service provider.
All of the Layer 3 is happening between the customer devices.
The service provider in the middle
here is not involved in Layer 3 at all.
Now, this service, quite commonly referred
to as Ethernet over MPLS, can be implemented
in two different ways.
First is point-to-point, which is essentially what
I drew up here as our example.
The other option is multipoint, or Virtual Private LAN Service,
VPLS.
In this example, the customer has multiple routers.
These are all going to be connected
by the VPLS being offered by the service provider.
And in turn, this ends up looking like an Ethernet switch
to the customer.
So for example, if, again, the customer was running OSPF,
it would treat this as if you were running OSPF on Ethernet,
and all of these routers would become neighbors.
Now, this isn't really our discussion right now.
But realistically, what would happen, of course,
is one of these would become the DR. One of these
would become a BDR.
And we would become fully adjacent
with the DR and the BDR.
But we're not really talking about full neighborships
here with OSPF.
We're simply saying that they would
be able to communicate with each other
because they all see each other as being on the same segment.
So next, let's focus on our Layer 3 VPNs.
Layer 3 VPNs are quite commonly offered to act as a WAN service
for the customer.
But these are also used quite commonly
in the core of enterprise networks.
So this isn't just a service provider technology.
We can use it in large enterprises as well.
Now, the big difference here, of course, from Layer 2 VPN,
is, here, the customer routes are actually learned
from the Customer Edge routers.
This is already implying that the routes
are being learned by the service provider from the customer.
Now, any protocol can be used.
We're going to use this term very carefully, though.
Any protocol.
What we, of course, mean is any protocol
that the service provider chooses to support.
Technically, yes, we can support things
like RIP version 1, RIP version 2, EIGRP.
Those, however, are not very commonly
supported by the service provider, just because--
well that means that we have to have
technicians that understand those protocols, and so on.
It's more overhead for us to support
some legacy, or not-so-popular, maybe
proprietary routing protocols.
Quite commonly, the only one supported is BGP.
That's getting more and more popular.
I know some service providers do still offer OSPF as well.
But OSPF and BGP are the only two
I'm aware of that service providers are offering.
There always might be some that offer additional ones.
Now again, keep in mind, all of these protocols
have their own caveats that the service provider
would have to deal with.
And that's part of why we don't really
like to support these from the service provider's standpoint.
BGP, of course, like I said, is the most common implementation
here.
And just another interesting point,
this is all about what protocol the customer
wants to run with the provider for the Layer 3 VPN.
We usually call this the CE-PE routing protocol.
Now, if the customer doesn't know BGP,
which is quite commonly the pushback
that you'll get from customers.
Well, we're running OSPF.
We want to run Layer 3 VPN with you.
Can't we just run OSPF with you?
We don't really have anybody on staff who knows BGP.
This is actually an opportunity for a good upsell
to try to get them to do managed edge services.
We can simply say, oh, well, tell you what?
We can run the CE for you, for a nominal monthly fee.
And we can run the customer's router for them.
And we'll take care of redistributing
between the OSPF and the BGP, and do it on the CE router.
And besides just the upsell here,
it also allows us to scale our PE routers
much better because it's less work on the PE router.
Otherwise, if we support OSPF, not only
do we have to run OSPF with the customer
then, while we're still running BGP--
keep in mind, that means that that PE router is also
going to have to do the redistribution as well.
So it actually offloads a lot of work back to the customer
if we insist that they actually run
BGP, which is part of why it's a very popular choice.
Now, of course, it's incredibly important, if we're
going to be supporting multiple customers in this environment,
that their routes are kept isolated.
We cannot be mixing and matching traffic between our customers.
They're not going to be very happy.
Because again, this is supposed to be
acting as their WAN service.
If they wanted their traffic intermingled
with everybody else's, they would just use the internet.
This is supposed to be private circuits for the customer.
Now, again, we're going to talk about this in much more detail.
But just the short version is, on the PE,
we're going to do this using VRFs, or Virtual Routers
and Forwarders, in the core.
This is exactly what these VPN labels are for.
And that keeps the traffic isolated.
And since they're isolated, it means the customers
can use any addressing.
And more importantly, it means they can
use overlapping address space.
The reason this is important is, keep in mind, once again,
this is their WAN service, which means that it's inside
of their network, most likely inside of their NAT engine,
which means they're probably using private addressing.
Well, how many companies out there do you think
are all using RFC 1918 addresses inside their company?
That's literally the point of RFC 1918 addresses.
So do you have any idea how many enterprises are all using
10 dot inside of their network?
Or 172.16 to 172.31.
Well, not too many probably use 192.168.
Those are usually for home, or maybe small office use.
But the point is, there's going to be a ton of overlap here.
So we have to make sure that we can accommodate that.
And by keeping it isolated--
which, again, we'll hit more detail
on later-- but by keeping these isolated,
we allow that to happen.
Now, in case you've been looking at all this,
wondering what the big advantage is of having the service
provider involved in the routing,
as opposed to the Layer 2 VPN we talked about a moment ago--
well, it's really here.
It's that we can provide optimal traffic delivery because we
know the customers routes.
If we know the customer routes, we're
effectively providing a full mesh
of connectivity for that customer
because we will deliver their traffic
to the closest available site that has that destination.
So this is very efficient.
Now, this is one of those technologies
that's going to use two labels.
We're going to use an LDP-learned label, also known
as the forwarding label, to forward
that traffic to the egress PE.
So this is going to be used to forward the traffic
through the MPLS core.
Then we have a multi-protocol BGP-learned label that's used
to identify the egress VRF--
or route, or interface.
But most likely, it's going to be the egress VRF.
So in this video, we just got an introduction
to our two major types of VPNs.
That we can offer to our customers.
We have our Layer 2 VPN, which, again, can either
be point-to-point or multipoint, acting
like just a single circuit for the customer,
or essentially acting as an Ethernet switch.
That environment is completely uninvolved with the customer
routing.
In other words, the customer's just getting a Layer 2 handoff.
And from the perspective of things like routing protocols,
they're going to think they're actually
neighbors of each other.
Then we have the Layer 3 VPN.
The layer VPN, of course, the service provider
learns the routes.
And we're going to have to do things
like keep those routes separate, because we
can't be intermingling customer traffic
between multiple customers.
However, it has the advantage of being
able to deliver the traffic to the best
site for that destination, effectively
making this act like an incredibly efficient full mesh
connection.
Now, this is only one of the advanced services
that MPLS offers.
Traffic Engineering is another one.
And we're going to talk about that one from an introduction
standpoint next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.