[MUSIC PLAYING]
So now it's time to look at Central Service VPNs.
These are designed to allow the service
provider to offer some form of service to the customers.
Again, the main key here is we want
customers to be able to contact the Central Service VPN.
The Central Service VPN, of course,
needs to be able to route back to the customers,
but we don't want the customers to be joined together
through the Central Service VPN.
They probably wouldn't be very happy about that.
So this is really going to come down to two things.
One, how we use our route targets.
And that's going to be the main point.
And number two, how we use our IP addresses.
So let's go ahead and jump in and take a look
at some of those details.
Service providers often have a need or a desire
to offer some sort of services to their customers.
Now, I put together a list here of just a few examples.
Something maybe like, managed edge services, voice gateways,
email relay services, load balancers, DNS caches,
and really anything else they want to offer their customer.
This, of course, could be a growing list.
These are just some examples.
The real key though to this is, as we mentioned
during the introduction, we have to have connectivity
between the central services and the customers,
but not allow traffic between the customers.
The customers don't want to be joined together.
Remember, this is not the internet.
This is their WAN service.
So this is effectively inside of their network.
We can't be leaking routes between customers here.
So how do we accomplish this?
Well, it's actually fairly straightforward.
What we need to do is use the route targets
in the appropriate way.
So what we do is we create route targets
that the customers can use, and the Central Service VPN
can use.
They're going to be different route targets.
And what happens is, the customers
import the route target for the services that they desire.
Now, when we say the customers import.
Understand, of course, the customers
are not configuring our network, right?
The customer presents the desire to be part of this service,
and then we configure our network appropriately.
And then, of course, we also configure our Central Services
VPN to import the route target for the interested customers,
the ones that sign up for the service.
And then we implement the appropriate route
filtering to ensure that customer routes are not
reflected out to other customers.
So this is just added to ensure that we
don't leak routes between customers, giving a gateway.
Now, another issue that's going to come up
is, of course, IP addresses.
What IP addresses is the customer
going to use to talk to the Central Service VPNs?
Because remember, the customers are
most likely using RFC 1918 addresses inside
of their network.
And they could definitely have address conflicts
or overlapping addresses.
So there's really two choices here.
One, we could have the customers use
NAT to hide their private addresses
behind a different address, and use that to deal
with the overlapping addresses.
I don't see this one done quite as commonly.
The more common one I see is that the service provider
gives dedicated addresses that get assigned to the customers,
for them to put on the devices that they're
going to use to talk to the central services.
So let's go ahead and jump over to our diagram,
and take a look at what this would
look like in our configuration.
So essentially, the way this is going to work
is, the Central Services VPNs are
going to be a separate VRF on our PEs.
So we would have a separate link out here
to the router that is the central service VPN router.
So we'll call this C for Central Services.
And then all we have to do is set up our route targets
appropriately.
So on our central services, maybe we
say to export 100 colon 1000.
And we import 100 colon 1001.
Then maybe Customer A's remote site
decides to sign up for this central service, whatever
it is.
Maybe it's managed edge services.
So Customer A simply says to export 100 colon
1001, import 100 colon 1000.
Now, understand.
We're not going to configure this
for all of their IP addresses.
We don't need all of their internal routing and everything
else.
This would just be for those addresses assigned
for the Central Service VPNs.
So we can see that using this method,
the customer is going to learn the routes from the Central
Service VPN.
And the central service VPN is going
to learn the routes from the customer.
But then what if Customer B's headquarters
wants to sign up for this central service?
Well, they would do the same thing
that Customer A remote did.
They would then sign up, and they
would export 100 colon 1001, and they
would import 100 colon 1000.
So just like customer A's remote site,
they will now get the routes from the central service VPN.
The central service VPN will now get the routes
from Customer B's headquarters--
again, just for the specific addresses.
But notice that between Customer B and Customer A,
they're not importing each other route targets.
So Customer B headquarters, for example, exports the 1001.
But nowhere over here is customer A importing 1001.
So the customers don't learn each other's routes.
All of the routes go to the Central Services.
All of the Central Services go back out to the customers.
But again, they don't learn each other's routes.
We can use NAT or dedicated addressing here.
And we do filtering on the Central Service VPN
so that the routes don't get reflected or leaked back out
to the other customers.
But in this way, we can offer services to our customers
without connecting the customers together.
And that was our main goal.
So in this video, we saw how to properly configure
a VRF to offer central services to our customers.
Remember the two main factors here.
First, we have to use our route targets appropriately
so that the Central Service VPN learns all the customer routes,
and the customers learn all the Central Service VPN routes,
but the customers don't learn each other's routes.
The way we do this, of course, is by using the two
different route targets.
The other thing is the IP addressing.
Again, that can either be done with NAT, or with the more
popular option, having dedicated IP address
space for the Central Service VPN
that we have the customer use on the devices
that they're going to use to talk to that Central Service
VPN.
So the next thing we have to do is configure our network
so that the CE devices can actually send
their routes to the PE routers.
And that's exactly what we get to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.