1
00:00:00,000 --> 00:00:02,982
[MUSIC PLAYING]

2
00:00:02,982 --> 00:00:07,960

3
00:00:07,960 --> 00:00:12,070
So now it's time to look
at Central Service VPNs.

4
00:00:12,070 --> 00:00:14,020
These are designed
to allow the service

5
00:00:14,020 --> 00:00:18,550
provider to offer some form
of service to the customers.

6
00:00:18,550 --> 00:00:21,460
Again, the main
key here is we want

7
00:00:21,460 --> 00:00:25,270
customers to be able to contact
the Central Service VPN.

8
00:00:25,270 --> 00:00:27,370
The Central Service
VPN, of course,

9
00:00:27,370 --> 00:00:30,550
needs to be able to route
back to the customers,

10
00:00:30,550 --> 00:00:34,210
but we don't want the
customers to be joined together

11
00:00:34,210 --> 00:00:36,370
through the Central Service VPN.

12
00:00:36,370 --> 00:00:39,230
They probably wouldn't
be very happy about that.

13
00:00:39,230 --> 00:00:42,440
So this is really going to
come down to two things.

14
00:00:42,440 --> 00:00:45,280
One, how we use
our route targets.

15
00:00:45,280 --> 00:00:47,240
And that's going to
be the main point.

16
00:00:47,240 --> 00:00:50,450
And number two, how we
use our IP addresses.

17
00:00:50,450 --> 00:00:53,050
So let's go ahead and
jump in and take a look

18
00:00:53,050 --> 00:00:56,440
at some of those details.

19
00:00:56,440 --> 00:01:00,730
Service providers often
have a need or a desire

20
00:01:00,730 --> 00:01:05,390
to offer some sort of
services to their customers.

21
00:01:05,390 --> 00:01:08,470
Now, I put together a list
here of just a few examples.

22
00:01:08,470 --> 00:01:14,020
Something maybe like, managed
edge services, voice gateways,

23
00:01:14,020 --> 00:01:20,080
email relay services, load
balancers, DNS caches,

24
00:01:20,080 --> 00:01:23,170
and really anything else they
want to offer their customer.

25
00:01:23,170 --> 00:01:25,430
This, of course, could
be a growing list.

26
00:01:25,430 --> 00:01:27,200
These are just some examples.

27
00:01:27,200 --> 00:01:30,520
The real key though to
this is, as we mentioned

28
00:01:30,520 --> 00:01:33,460
during the introduction, we
have to have connectivity

29
00:01:33,460 --> 00:01:36,580
between the central
services and the customers,

30
00:01:36,580 --> 00:01:42,370
but not allow traffic
between the customers.

31
00:01:42,370 --> 00:01:44,510
The customers don't want
to be joined together.

32
00:01:44,510 --> 00:01:46,720
Remember, this is
not the internet.

33
00:01:46,720 --> 00:01:48,950
This is their WAN service.

34
00:01:48,950 --> 00:01:51,710
So this is effectively
inside of their network.

35
00:01:51,710 --> 00:01:55,040
We can't be leaking routes
between customers here.

36
00:01:55,040 --> 00:01:57,440
So how do we accomplish this?

37
00:01:57,440 --> 00:01:59,870
Well, it's actually
fairly straightforward.

38
00:01:59,870 --> 00:02:04,330
What we need to do is
use the route targets

39
00:02:04,330 --> 00:02:07,040
in the appropriate way.

40
00:02:07,040 --> 00:02:09,669
So what we do is we
create route targets

41
00:02:09,669 --> 00:02:13,840
that the customers can use,
and the Central Service VPN

42
00:02:13,840 --> 00:02:15,020
can use.

43
00:02:15,020 --> 00:02:17,560
They're going to be
different route targets.

44
00:02:17,560 --> 00:02:20,920
And what happens
is, the customers

45
00:02:20,920 --> 00:02:26,150
import the route target for
the services that they desire.

46
00:02:26,150 --> 00:02:29,200
Now, when we say the
customers import.

47
00:02:29,200 --> 00:02:30,880
Understand, of
course, the customers

48
00:02:30,880 --> 00:02:33,640
are not configuring
our network, right?

49
00:02:33,640 --> 00:02:37,060
The customer presents the desire
to be part of this service,

50
00:02:37,060 --> 00:02:39,830
and then we configure our
network appropriately.

51
00:02:39,830 --> 00:02:42,790
And then, of course, we also
configure our Central Services

52
00:02:42,790 --> 00:02:48,350
VPN to import the route target
for the interested customers,

53
00:02:48,350 --> 00:02:50,650
the ones that sign
up for the service.

54
00:02:50,650 --> 00:02:53,530
And then we implement
the appropriate route

55
00:02:53,530 --> 00:02:58,060
filtering to ensure that
customer routes are not

56
00:02:58,060 --> 00:03:01,730
reflected out to
other customers.

57
00:03:01,730 --> 00:03:04,360
So this is just added
to ensure that we

58
00:03:04,360 --> 00:03:08,670
don't leak routes between
customers, giving a gateway.

59
00:03:08,670 --> 00:03:10,420
Now, another issue
that's going to come up

60
00:03:10,420 --> 00:03:12,430
is, of course, IP addresses.

61
00:03:12,430 --> 00:03:14,980
What IP addresses
is the customer

62
00:03:14,980 --> 00:03:18,490
going to use to talk to
the Central Service VPNs?

63
00:03:18,490 --> 00:03:20,860
Because remember,
the customers are

64
00:03:20,860 --> 00:03:24,700
most likely using RFC
1918 addresses inside

65
00:03:24,700 --> 00:03:25,940
of their network.

66
00:03:25,940 --> 00:03:29,620
And they could definitely
have address conflicts

67
00:03:29,620 --> 00:03:31,910
or overlapping addresses.

68
00:03:31,910 --> 00:03:33,980
So there's really
two choices here.

69
00:03:33,980 --> 00:03:36,700
One, we could have
the customers use

70
00:03:36,700 --> 00:03:39,850
NAT to hide their
private addresses

71
00:03:39,850 --> 00:03:42,940
behind a different address,
and use that to deal

72
00:03:42,940 --> 00:03:44,740
with the overlapping addresses.

73
00:03:44,740 --> 00:03:47,740
I don't see this one
done quite as commonly.

74
00:03:47,740 --> 00:03:51,490
The more common one I see
is that the service provider

75
00:03:51,490 --> 00:03:56,590
gives dedicated addresses that
get assigned to the customers,

76
00:03:56,590 --> 00:03:58,690
for them to put on the
devices that they're

77
00:03:58,690 --> 00:04:02,240
going to use to talk to
the central services.

78
00:04:02,240 --> 00:04:04,720
So let's go ahead and
jump over to our diagram,

79
00:04:04,720 --> 00:04:06,460
and take a look
at what this would

80
00:04:06,460 --> 00:04:09,800
look like in our configuration.

81
00:04:09,800 --> 00:04:12,100
So essentially, the way
this is going to work

82
00:04:12,100 --> 00:04:15,790
is, the Central
Services VPNs are

83
00:04:15,790 --> 00:04:19,540
going to be a separate
VRF on our PEs.

84
00:04:19,540 --> 00:04:22,240
So we would have a
separate link out here

85
00:04:22,240 --> 00:04:26,570
to the router that is the
central service VPN router.

86
00:04:26,570 --> 00:04:29,590
So we'll call this C
for Central Services.

87
00:04:29,590 --> 00:04:33,340
And then all we have to do
is set up our route targets

88
00:04:33,340 --> 00:04:34,750
appropriately.

89
00:04:34,750 --> 00:04:37,330
So on our central
services, maybe we

90
00:04:37,330 --> 00:04:42,880
say to export 100 colon 1000.

91
00:04:42,880 --> 00:04:49,120
And we import 100 colon 1001.

92
00:04:49,120 --> 00:04:52,630
Then maybe Customer
A's remote site

93
00:04:52,630 --> 00:04:55,960
decides to sign up for this
central service, whatever

94
00:04:55,960 --> 00:04:56,560
it is.

95
00:04:56,560 --> 00:04:59,240
Maybe it's managed
edge services.

96
00:04:59,240 --> 00:05:04,720
So Customer A simply
says to export 100 colon

97
00:05:04,720 --> 00:05:10,450
1001, import 100 colon 1000.

98
00:05:10,450 --> 00:05:11,470
Now, understand.

99
00:05:11,470 --> 00:05:13,060
We're not going
to configure this

100
00:05:13,060 --> 00:05:15,670
for all of their IP addresses.

101
00:05:15,670 --> 00:05:18,520
We don't need all of their
internal routing and everything

102
00:05:18,520 --> 00:05:19,210
else.

103
00:05:19,210 --> 00:05:22,210
This would just be for
those addresses assigned

104
00:05:22,210 --> 00:05:24,850
for the Central Service VPNs.

105
00:05:24,850 --> 00:05:27,443
So we can see that
using this method,

106
00:05:27,443 --> 00:05:29,860
the customer is going to learn
the routes from the Central

107
00:05:29,860 --> 00:05:31,300
Service VPN.

108
00:05:31,300 --> 00:05:33,040
And the central
service VPN is going

109
00:05:33,040 --> 00:05:35,110
to learn the routes
from the customer.

110
00:05:35,110 --> 00:05:37,570
But then what if
Customer B's headquarters

111
00:05:37,570 --> 00:05:40,323
wants to sign up for
this central service?

112
00:05:40,323 --> 00:05:41,740
Well, they would
do the same thing

113
00:05:41,740 --> 00:05:43,990
that Customer A remote did.

114
00:05:43,990 --> 00:05:46,120
They would then
sign up, and they

115
00:05:46,120 --> 00:05:51,250
would export 100
colon 1001, and they

116
00:05:51,250 --> 00:05:55,120
would import 100 colon 1000.

117
00:05:55,120 --> 00:05:58,010
So just like customer
A's remote site,

118
00:05:58,010 --> 00:06:01,580
they will now get the routes
from the central service VPN.

119
00:06:01,580 --> 00:06:04,160
The central service VPN
will now get the routes

120
00:06:04,160 --> 00:06:06,830
from Customer B's headquarters--

121
00:06:06,830 --> 00:06:09,770
again, just for the
specific addresses.

122
00:06:09,770 --> 00:06:15,590
But notice that between
Customer B and Customer A,

123
00:06:15,590 --> 00:06:19,320
they're not importing
each other route targets.

124
00:06:19,320 --> 00:06:25,070
So Customer B headquarters,
for example, exports the 1001.

125
00:06:25,070 --> 00:06:30,980
But nowhere over here is
customer A importing 1001.

126
00:06:30,980 --> 00:06:34,340
So the customers don't
learn each other's routes.

127
00:06:34,340 --> 00:06:36,950
All of the routes go to
the Central Services.

128
00:06:36,950 --> 00:06:40,400
All of the Central Services
go back out to the customers.

129
00:06:40,400 --> 00:06:43,430
But again, they don't
learn each other's routes.

130
00:06:43,430 --> 00:06:47,190
We can use NAT or
dedicated addressing here.

131
00:06:47,190 --> 00:06:50,340
And we do filtering on
the Central Service VPN

132
00:06:50,340 --> 00:06:54,110
so that the routes don't get
reflected or leaked back out

133
00:06:54,110 --> 00:06:55,940
to the other customers.

134
00:06:55,940 --> 00:06:59,720
But in this way, we can offer
services to our customers

135
00:06:59,720 --> 00:07:02,250
without connecting the
customers together.

136
00:07:02,250 --> 00:07:05,710
And that was our main goal.

137
00:07:05,710 --> 00:07:09,330
So in this video, we saw
how to properly configure

138
00:07:09,330 --> 00:07:14,250
a VRF to offer central
services to our customers.

139
00:07:14,250 --> 00:07:16,500
Remember the two
main factors here.

140
00:07:16,500 --> 00:07:19,920
First, we have to use our
route targets appropriately

141
00:07:19,920 --> 00:07:24,090
so that the Central Service VPN
learns all the customer routes,

142
00:07:24,090 --> 00:07:27,930
and the customers learn all
the Central Service VPN routes,

143
00:07:27,930 --> 00:07:31,050
but the customers don't
learn each other's routes.

144
00:07:31,050 --> 00:07:33,930
The way we do this, of
course, is by using the two

145
00:07:33,930 --> 00:07:35,730
different route targets.

146
00:07:35,730 --> 00:07:38,220
The other thing is
the IP addressing.

147
00:07:38,220 --> 00:07:41,760
Again, that can either be done
with NAT, or with the more

148
00:07:41,760 --> 00:07:45,090
popular option, having
dedicated IP address

149
00:07:45,090 --> 00:07:48,030
space for the
Central Service VPN

150
00:07:48,030 --> 00:07:51,060
that we have the customer
use on the devices

151
00:07:51,060 --> 00:07:53,880
that they're going to use to
talk to that Central Service

152
00:07:53,880 --> 00:07:55,330
VPN.

153
00:07:55,330 --> 00:07:58,810
So the next thing we have to
do is configure our network

154
00:07:58,810 --> 00:08:01,680
so that the CE devices
can actually send

155
00:08:01,680 --> 00:08:04,290
their routes to the PE routers.

156
00:08:04,290 --> 00:08:07,030
And that's exactly
what we get to do next.

157
00:08:07,030 --> 00:08:10,380
Until then, I hope this has
been informative for you,

158
00:08:10,380 --> 00:08:13,490
and I'd like to thank
you for viewing.

159
00:08:13,490 --> 00:08:17,000