1
00:00:00,000 --> 00:00:00,500

2
00:00:00,500 --> 00:00:04,000
[AUDIO LOGO]

3
00:00:04,000 --> 00:00:08,000

4
00:00:08,000 --> 00:00:11,990
So now that we've taken our
customer route from the VRF

5
00:00:11,990 --> 00:00:15,920
on the engress PE, put
on a route distinguisher

6
00:00:15,920 --> 00:00:19,550
to make it unique as it travels
through the core, put it

7
00:00:19,550 --> 00:00:24,560
into multiprotocol BGP, sent it
through most likely our route

8
00:00:24,560 --> 00:00:29,120
reflector, and now it's
arrived at the egress PE,

9
00:00:29,120 --> 00:00:32,210
well, now we're presented
with our next problem.

10
00:00:32,210 --> 00:00:36,260
How do we know which
VRF on the egress

11
00:00:36,260 --> 00:00:40,130
PE this route is supposed
to go to so that it

12
00:00:40,130 --> 00:00:41,990
gets to the correct customer?

13
00:00:41,990 --> 00:00:43,970
And that's exactly the
problem that we're going

14
00:00:43,970 --> 00:00:46,380
to be addressing in this video.

15
00:00:46,380 --> 00:00:48,290
So let's just go
ahead and jump in

16
00:00:48,290 --> 00:00:52,990
and see how this process is
handled in our layer 3 VPN

17
00:00:52,990 --> 00:00:55,510
core.

18
00:00:55,510 --> 00:00:59,080
So once that
multiprotocol BGP update

19
00:00:59,080 --> 00:01:03,430
reaches the remote
or egress PE router,

20
00:01:03,430 --> 00:01:07,120
we come across our
next issue, which

21
00:01:07,120 --> 00:01:10,390
is that the correct
prefixes have

22
00:01:10,390 --> 00:01:13,400
to go to the correct customers.

23
00:01:13,400 --> 00:01:16,420
Therefore, they have to
be placed in the BGP table

24
00:01:16,420 --> 00:01:20,920
for the correct customers
in the correct VRF.

25
00:01:20,920 --> 00:01:24,970
So the question becomes,
how do we accomplish this?

26
00:01:24,970 --> 00:01:28,060
Now, at this point,
a lot of people ask,

27
00:01:28,060 --> 00:01:30,910
couldn't we just use
the route distinguisher?

28
00:01:30,910 --> 00:01:33,310
If we use the same
route distinguisher

29
00:01:33,310 --> 00:01:38,020
for each location for a single
customer-- like in our example

30
00:01:38,020 --> 00:01:41,372
for customer A, we did 100:1.

31
00:01:41,372 --> 00:01:44,830
If we use that same route
distinguisher at every customer

32
00:01:44,830 --> 00:01:48,010
location, couldn't
we use that number

33
00:01:48,010 --> 00:01:51,820
to know which VRF we
should put the routes in?

34
00:01:51,820 --> 00:01:57,400
And quite frankly, the answer is
yes, we absolutely could have.

35
00:01:57,400 --> 00:01:59,440
So then why didn't we?

36
00:01:59,440 --> 00:02:02,830
Well, the answer is, if you
remember a few videos ago

37
00:02:02,830 --> 00:02:06,490
during our introduction, I
discussed the fact that we

38
00:02:06,490 --> 00:02:09,430
could have overlapping VPNs.

39
00:02:09,430 --> 00:02:11,590
And we also have
another type of VPN

40
00:02:11,590 --> 00:02:15,160
we discussed and are going to
discuss in more detail, which

41
00:02:15,160 --> 00:02:17,800
is the central service VPN.

42
00:02:17,800 --> 00:02:21,580
Those types of VPNs
would not be very

43
00:02:21,580 --> 00:02:25,000
easy to accomplish if
all we had to work with

44
00:02:25,000 --> 00:02:27,250
was the route distinguisher.

45
00:02:27,250 --> 00:02:30,350
Therefore, we just
decided not to use it.

46
00:02:30,350 --> 00:02:32,030
So what do we do instead?

47
00:02:32,030 --> 00:02:34,000
Well, let's take a look.

48
00:02:34,000 --> 00:02:36,820
What we do instead
is we simply use

49
00:02:36,820 --> 00:02:43,750
yet another new number called
the Route Target, or the RT.

50
00:02:43,750 --> 00:02:46,210
Now, like the route
distinguisher,

51
00:02:46,210 --> 00:02:49,090
this is a 64-bit value.

52
00:02:49,090 --> 00:02:53,080
Again, we wanted to ensure
that there was plenty of space.

53
00:02:53,080 --> 00:02:57,230
This one, rather than
being part of the prefix,

54
00:02:57,230 --> 00:03:01,240
like the route distinguisher
is, this one is carried

55
00:03:01,240 --> 00:03:05,110
in BGP extended communities.

56
00:03:05,110 --> 00:03:08,920
Now, this does mean
that BGP extended

57
00:03:08,920 --> 00:03:12,140
communities have to be enabled.

58
00:03:12,140 --> 00:03:16,930
This is also another reason
why BGP was the perfect fit

59
00:03:16,930 --> 00:03:18,860
for running our core.

60
00:03:18,860 --> 00:03:23,350
This is part of that being able
to carry extra information.

61
00:03:23,350 --> 00:03:27,770
BGP communities are perfect
just for this sort of thing.

62
00:03:27,770 --> 00:03:29,710
Now, another very
important consideration

63
00:03:29,710 --> 00:03:34,870
here is an update can
carry many route targets.

64
00:03:34,870 --> 00:03:37,990
Again, they're just
carried as communities.

65
00:03:37,990 --> 00:03:40,810
And there's really no limit
on the length of the community

66
00:03:40,810 --> 00:03:41,510
string.

67
00:03:41,510 --> 00:03:44,020
So we can put
numerous route targets

68
00:03:44,020 --> 00:03:47,020
on here, which, again,
is what's giving us

69
00:03:47,020 --> 00:03:51,340
the capability of doing
things like simple VPNs

70
00:03:51,340 --> 00:03:56,020
just for customer A and
customer B, overlapping VPNs,

71
00:03:56,020 --> 00:03:58,870
and things like
central service VPNs.

72
00:03:58,870 --> 00:04:03,100
This flexibility gives
us a lot of control.

73
00:04:03,100 --> 00:04:08,080
Now, the route targets,
again, are configured per VRF.

74
00:04:08,080 --> 00:04:10,990
And they can either be
configured that we import

75
00:04:10,990 --> 00:04:12,700
a particular route target.

76
00:04:12,700 --> 00:04:15,430
We export particular
route targets.

77
00:04:15,430 --> 00:04:17,680
The ones we export,
of course, are

78
00:04:17,680 --> 00:04:20,350
the ones that are going to
be added to the updates,

79
00:04:20,350 --> 00:04:22,430
or we can do both.

80
00:04:22,430 --> 00:04:25,780
Now, both is only a
configuration term.

81
00:04:25,780 --> 00:04:27,490
It's just a shortcut.

82
00:04:27,490 --> 00:04:29,680
If we do a show
run, it'll actually

83
00:04:29,680 --> 00:04:33,510
list both import and export.

84
00:04:33,510 --> 00:04:36,480
Now, when an update
is being sent,

85
00:04:36,480 --> 00:04:42,660
any and all route targets that
are set to export in the VRF

86
00:04:42,660 --> 00:04:45,850
will be added to that update.

87
00:04:45,850 --> 00:04:49,680
So you can, of course, have more
than one export route target.

88
00:04:49,680 --> 00:04:51,690
That's the point.

89
00:04:51,690 --> 00:04:56,310
On the opposite side, when
an update is received,

90
00:04:56,310 --> 00:04:59,220
the list of route
targets on the update

91
00:04:59,220 --> 00:05:02,820
are going to be compared
to the route targets that

92
00:05:02,820 --> 00:05:09,090
are being imported by each
VRF on that particular PE.

93
00:05:09,090 --> 00:05:11,880
And one of three things
is going to happen.

94
00:05:11,880 --> 00:05:17,760
First, if any VRF is set to
import that route target,

95
00:05:17,760 --> 00:05:21,750
that route is then going to
be placed in the VRF that's

96
00:05:21,750 --> 00:05:23,430
doing the import.

97
00:05:23,430 --> 00:05:28,800
If no VRFs on the PE
are set to import,

98
00:05:28,800 --> 00:05:32,160
the update is simply
going to be discarded.

99
00:05:32,160 --> 00:05:35,940
Now, the third one here is a
little bit more conditional.

100
00:05:35,940 --> 00:05:40,090
This one is if the route
target is modified.

101
00:05:40,090 --> 00:05:44,400
So in other words, if you as
the administrator go into a VRF

102
00:05:44,400 --> 00:05:49,410
and add a new import route
target, since that route

103
00:05:49,410 --> 00:05:51,810
target wasn't being
imported before,

104
00:05:51,810 --> 00:05:54,300
it may have already
been discarded.

105
00:05:54,300 --> 00:05:56,220
I might have already
received that earlier,

106
00:05:56,220 --> 00:06:00,390
and I threw it away because
no VRFs were importing it.

107
00:06:00,390 --> 00:06:03,750
So since it may have
already been discarded,

108
00:06:03,750 --> 00:06:08,100
the PE will do a BGP
route refresh message

109
00:06:08,100 --> 00:06:10,990
to get that update sent again.

110
00:06:10,990 --> 00:06:14,520
So as we've been doing,
let's hop over to our diagram

111
00:06:14,520 --> 00:06:16,290
and take a look at
how this would all

112
00:06:16,290 --> 00:06:19,900
fit in to the big picture.

113
00:06:19,900 --> 00:06:23,850
So let's start here with a very,
very simple example, just doing

114
00:06:23,850 --> 00:06:28,200
simple VPNs for customer
A and customer B.

115
00:06:28,200 --> 00:06:29,670
To do that, we
could do something

116
00:06:29,670 --> 00:06:38,470
as simple as, on VRF A, we could
simply say to export 100:100.

117
00:06:38,470 --> 00:06:43,630
We would also say
to import 100:100.

118
00:06:43,630 --> 00:06:46,060
We would do the same
thing over here.

119
00:06:46,060 --> 00:06:48,600
So just as a very
simple example here,

120
00:06:48,600 --> 00:06:52,950
the update comes in from
the customer into the VRF.

121
00:06:52,950 --> 00:06:57,780
When we send it into BGP,
we add the export route

122
00:06:57,780 --> 00:07:00,870
target 100:100.

123
00:07:00,870 --> 00:07:04,920
That route then passes
through our multiprotocol BGP.

124
00:07:04,920 --> 00:07:08,940
And when it gets over
to the egress PE side,

125
00:07:08,940 --> 00:07:15,330
we then look to see, is
any VRF importing 100:100?

126
00:07:15,330 --> 00:07:19,110
And we see that,
in fact, VRF A is--

127
00:07:19,110 --> 00:07:22,050
therefore, this route
is brought into VRF A

128
00:07:22,050 --> 00:07:26,890
and, ultimately, therefore
sent up to the customer.

129
00:07:26,890 --> 00:07:30,510
So this is the basic idea
behind import and export route

130
00:07:30,510 --> 00:07:31,660
targets.

131
00:07:31,660 --> 00:07:33,960
We do not have to
use the same import

132
00:07:33,960 --> 00:07:38,010
and export route targets
for a particular customer.

133
00:07:38,010 --> 00:07:40,770
Commonly, that will be
done, but we could also

134
00:07:40,770 --> 00:07:42,600
do something like this.

135
00:07:42,600 --> 00:07:50,160
I can export 100:200
and import 100:201.

136
00:07:50,160 --> 00:07:52,710
Then all I have
to do is when I'm

137
00:07:52,710 --> 00:07:55,920
configuring the other
sites, I basically just

138
00:07:55,920 --> 00:07:57,720
have to mirror these.

139
00:07:57,720 --> 00:08:00,330
And we'll have the
exact same thing happen.

140
00:08:00,330 --> 00:08:05,310
As long as one site is importing
whatever I'm exporting,

141
00:08:05,310 --> 00:08:08,320
this will work perfectly fine.

142
00:08:08,320 --> 00:08:10,750
So let me clean this
up a little bit.

143
00:08:10,750 --> 00:08:14,670
What we have right now
are two simple VPNs--

144
00:08:14,670 --> 00:08:18,390
one for customer A and
one for customer B. Well,

145
00:08:18,390 --> 00:08:23,160
to do a more advanced VPN,
an overlapping VPN, this

146
00:08:23,160 --> 00:08:26,010
is how easy it is to do.

147
00:08:26,010 --> 00:08:28,920
Let's say I wanted my
customer A headquarters

148
00:08:28,920 --> 00:08:32,130
to be able to talk to my
customer B headquarters,

149
00:08:32,130 --> 00:08:35,770
but not to the remote
sites directly.

150
00:08:35,770 --> 00:08:40,169
So all I want to do is
link this CE headquarter's

151
00:08:40,169 --> 00:08:43,559
router to this CE
headquarter's router.

152
00:08:43,559 --> 00:08:46,890
If the remote sites want to
talk to the other remote sites,

153
00:08:46,890 --> 00:08:48,480
maybe they can,
but it would have

154
00:08:48,480 --> 00:08:51,180
to go through headquarters.

155
00:08:51,180 --> 00:08:53,610
I'm trying to explain
why we would not just

156
00:08:53,610 --> 00:08:58,170
want to import say the
100:100 down here because that

157
00:08:58,170 --> 00:09:01,810
would include these routes
that are being exported.

158
00:09:01,810 --> 00:09:02,940
So what we do instead--

159
00:09:02,940 --> 00:09:05,130
and I'll just write this
as both since we're going

160
00:09:05,130 --> 00:09:07,270
to use the same number here--

161
00:09:07,270 --> 00:09:09,810
we'll use 100 colon--

162
00:09:09,810 --> 00:09:11,250
we'll just make up a new number.

163
00:09:11,250 --> 00:09:12,900
We'll just say 500.

164
00:09:12,900 --> 00:09:16,000
And down here, we say both.

165
00:09:16,000 --> 00:09:18,660
So now what we've
done is effectively

166
00:09:18,660 --> 00:09:23,550
made another VPN between
customer A and customer B

167
00:09:23,550 --> 00:09:24,780
headquarters.

168
00:09:24,780 --> 00:09:27,600
This is the power
of route targets.

169
00:09:27,600 --> 00:09:30,480
We can make whatever
routes show up

170
00:09:30,480 --> 00:09:34,470
on whatever routers we want
based on the route targets.

171
00:09:34,470 --> 00:09:37,230
And, again, what
that means is when

172
00:09:37,230 --> 00:09:41,430
this update is sent
from this CE to VRF A,

173
00:09:41,430 --> 00:09:46,320
it's going to get both the
100:100 and the 100:500 put

174
00:09:46,320 --> 00:09:47,410
on it.

175
00:09:47,410 --> 00:09:50,800
That means that when
it shows up over here,

176
00:09:50,800 --> 00:09:54,840
we're going to be importing
based on the 100:100.

177
00:09:54,840 --> 00:09:57,660
And when it shows up
at VRF B because this

178
00:09:57,660 --> 00:10:00,670
will be processed
locally as well,

179
00:10:00,670 --> 00:10:03,750
we are importing the 100:500.

180
00:10:03,750 --> 00:10:08,250
So this prefix ends up
on both of these VRFs.

181
00:10:08,250 --> 00:10:13,900
Now, just one quick note here,
in this particular example,

182
00:10:13,900 --> 00:10:17,760
these routers have
overlapping IP space.

183
00:10:17,760 --> 00:10:20,710
So that would
still be a problem.

184
00:10:20,710 --> 00:10:24,330
These customers would still
have to do something like NAT

185
00:10:24,330 --> 00:10:27,840
or something along those lines
so that they could actually

186
00:10:27,840 --> 00:10:28,860
communicate.

187
00:10:28,860 --> 00:10:32,850
I'm just trying to explain at
this point how the VPNs work.

188
00:10:32,850 --> 00:10:35,760
I'm not worried about the
overlapping address space

189
00:10:35,760 --> 00:10:39,780
that both of these customers
are sharing at this moment.

190
00:10:39,780 --> 00:10:41,910
The important part
is that this is

191
00:10:41,910 --> 00:10:46,170
how we use route targets to
control which routes show up

192
00:10:46,170 --> 00:10:49,710
in which routing tables
of which routers.

193
00:10:49,710 --> 00:10:51,810
And at the end of
the day, that's

194
00:10:51,810 --> 00:10:56,590
what layer 3 VPN is all about.

195
00:10:56,590 --> 00:11:00,000
So in this video, we
discussed the problem we have

196
00:11:00,000 --> 00:11:03,030
when our multiprotocol
BGP update

197
00:11:03,030 --> 00:11:07,470
arrives at the egress
PE, how we determine

198
00:11:07,470 --> 00:11:10,570
which VRF the route belongs to.

199
00:11:10,570 --> 00:11:14,670
And, of course, the way we do
that is with our 64-bit route

200
00:11:14,670 --> 00:11:15,720
target.

201
00:11:15,720 --> 00:11:18,870
The route targets
completely control which

202
00:11:18,870 --> 00:11:21,480
routes go into which VRFs.

203
00:11:21,480 --> 00:11:26,490
And at the end of the day, that
is really what a layer 3 MPLS

204
00:11:26,490 --> 00:11:29,020
VPN is all about.

205
00:11:29,020 --> 00:11:31,290
Now, earlier, we
mentioned that we

206
00:11:31,290 --> 00:11:36,900
have this special type of VPN,
the central services VPN, which

207
00:11:36,900 --> 00:11:41,820
is similar to what we did
here with the overlapping VPNs

208
00:11:41,820 --> 00:11:44,220
but handled it a little
bit differently when

209
00:11:44,220 --> 00:11:45,790
it comes to the route targets.

210
00:11:45,790 --> 00:11:48,610
So that's what we're going
to take a look at next.

211
00:11:48,610 --> 00:11:51,990
Until then, I hope this has
been informative for you.

212
00:11:51,990 --> 00:11:55,160
And I'd like to thank
you for viewing.

213
00:11:55,160 --> 00:11:59,000