1
00:00:00,000 --> 00:00:03,960
[AUDIO LOGO]

2
00:00:03,960 --> 00:00:07,930

3
00:00:07,930 --> 00:00:10,420
So now that we've learned
the customer routes

4
00:00:10,420 --> 00:00:14,740
in the appropriate VRFs
on the appropriate PE,

5
00:00:14,740 --> 00:00:18,190
it's now time to get those
routes through the core

6
00:00:18,190 --> 00:00:21,430
to the other PEs
that need the routes

7
00:00:21,430 --> 00:00:23,440
for that particular customer.

8
00:00:23,440 --> 00:00:26,200
Now, we've already
mentioned that to do this,

9
00:00:26,200 --> 00:00:29,320
we're going to be using
multiprotocol BGP.

10
00:00:29,320 --> 00:00:32,650
Well, in this video,
we're going to discuss why

11
00:00:32,650 --> 00:00:35,470
we call it multiprotocol BGP.

12
00:00:35,470 --> 00:00:38,890
And we're going to address
our next issue, which are

13
00:00:38,890 --> 00:00:40,780
sort of one and the same thing.

14
00:00:40,780 --> 00:00:45,610
We need to keep these routes
with overlapping address space

15
00:00:45,610 --> 00:00:51,130
unique as they're carried
through BGP in the core.

16
00:00:51,130 --> 00:00:53,500
We can't just take
overlapping routes

17
00:00:53,500 --> 00:00:56,650
from the customers, which
we were keeping separate

18
00:00:56,650 --> 00:01:00,400
in our VRFs, and just send
them to the other side,

19
00:01:00,400 --> 00:01:04,150
hoping that the other side knows
how to separate them again.

20
00:01:04,150 --> 00:01:05,740
They're overlapping routes.

21
00:01:05,740 --> 00:01:10,340
We would just see it as two
paths to the same destination.

22
00:01:10,340 --> 00:01:12,460
So we need to deal
with that issue

23
00:01:12,460 --> 00:01:14,690
as we move the routes
to the other side.

24
00:01:14,690 --> 00:01:19,180
So like we did with VRFs, let's
take a look at some things that

25
00:01:19,180 --> 00:01:22,250
possibly could have been done
but don't really work out

26
00:01:22,250 --> 00:01:25,570
so well, just so we understand
a little better why they

27
00:01:25,570 --> 00:01:27,440
chose the solution they did.

28
00:01:27,440 --> 00:01:29,950
Then, of course, we'll
talk about that solution

29
00:01:29,950 --> 00:01:31,220
and how it works.

30
00:01:31,220 --> 00:01:33,055
So let's go ahead
and get started.

31
00:01:33,055 --> 00:01:36,140

32
00:01:36,140 --> 00:01:39,040
So as we mentioned
during the introduction,

33
00:01:39,040 --> 00:01:42,820
VRFs do a really
good job on the PE

34
00:01:42,820 --> 00:01:45,730
routers to keep the
customer routes separate.

35
00:01:45,730 --> 00:01:50,290
However, we now need to get
the routes between the VRFs

36
00:01:50,290 --> 00:01:52,690
on different PEs.

37
00:01:52,690 --> 00:01:56,870
And this, again, is going
to have different problems.

38
00:01:56,870 --> 00:02:00,250
So let's first talk about the
ways that possibly could have

39
00:02:00,250 --> 00:02:03,230
been used but weren't chosen.

40
00:02:03,230 --> 00:02:07,690
So first, we could have used
a different routing protocol

41
00:02:07,690 --> 00:02:10,930
or at least instance of
that routing protocol

42
00:02:10,930 --> 00:02:12,760
for each customer.

43
00:02:12,760 --> 00:02:16,930
Now, there's really two major
problems with this solution.

44
00:02:16,930 --> 00:02:21,070
One is it, of course,
does not scale at all.

45
00:02:21,070 --> 00:02:23,620
The core routers,
or the P routers,

46
00:02:23,620 --> 00:02:28,150
would have had to have run
every instance of every protocol

47
00:02:28,150 --> 00:02:29,810
for every customer.

48
00:02:29,810 --> 00:02:32,650
So just totally impractical.

49
00:02:32,650 --> 00:02:35,350
And part of the reason this
would have had to have happened

50
00:02:35,350 --> 00:02:41,470
is IGPs are not meant to run
between nonconnected neighbors,

51
00:02:41,470 --> 00:02:43,630
which is what the PEs are.

52
00:02:43,630 --> 00:02:46,030
The PEs are not
connected to each other.

53
00:02:46,030 --> 00:02:48,020
The P routers are in the middle.

54
00:02:48,020 --> 00:02:50,740
So you can't exactly
neighbor OSPF

55
00:02:50,740 --> 00:02:53,690
to another router that far away.

56
00:02:53,690 --> 00:02:57,280
Now, theoretically-- I just
put a little note here--

57
00:02:57,280 --> 00:03:01,900
EIGRP OTP, which stands
for Over The Top,

58
00:03:01,900 --> 00:03:04,870
could theoretically
have been used.

59
00:03:04,870 --> 00:03:07,090
Again, we're not going to
pursue this a whole lot,

60
00:03:07,090 --> 00:03:09,940
because there are, of course,
other solutions, which

61
00:03:09,940 --> 00:03:12,230
is what we're talking
about in this video.

62
00:03:12,230 --> 00:03:17,710
But EIGRP OTP can actually run
between nonconnected neighbors.

63
00:03:17,710 --> 00:03:21,077
So theoretically, it could
have been a possibility.

64
00:03:21,077 --> 00:03:22,660
But there's a lot
of issues with that.

65
00:03:22,660 --> 00:03:25,090
Again, we don't have to
go too far down that path,

66
00:03:25,090 --> 00:03:27,730
because, well,
we're not using it.

67
00:03:27,730 --> 00:03:29,830
The other choice,
of course, is we

68
00:03:29,830 --> 00:03:34,720
could have used VRFs to
separate this on every P router.

69
00:03:34,720 --> 00:03:38,920
But this, of course, does not
scale, not even a little bit,

70
00:03:38,920 --> 00:03:42,010
because, again, the core
routers would have to maintain

71
00:03:42,010 --> 00:03:45,520
a VRF for every customer.

72
00:03:45,520 --> 00:03:48,400
This is not going
to scale anymore

73
00:03:48,400 --> 00:03:52,090
than the IGP solution right
above would have scaled.

74
00:03:52,090 --> 00:03:56,960
Last but not least, we could
have used traditional tunnels.

75
00:03:56,960 --> 00:03:59,570
Now, the problem with
traditional tunnels, of course,

76
00:03:59,570 --> 00:04:02,300
once again, these
don't scale either,

77
00:04:02,300 --> 00:04:07,480
and really sort of defeats
the purpose of the entire MPLS

78
00:04:07,480 --> 00:04:08,800
environment.

79
00:04:08,800 --> 00:04:13,390
If we really think about
it, ISPs, service providers,

80
00:04:13,390 --> 00:04:18,100
have been doing tunnels
between customers for years.

81
00:04:18,100 --> 00:04:22,490
The idea behind all of this was
sort of to get away from that.

82
00:04:22,490 --> 00:04:27,970
So yeah, we could have just done
traditional maybe GRE or L2TP

83
00:04:27,970 --> 00:04:29,600
tunnels, that sort of thing.

84
00:04:29,600 --> 00:04:32,650
But it really doesn't
meet this model.

85
00:04:32,650 --> 00:04:35,680
The idea was to not have
the service provider

86
00:04:35,680 --> 00:04:38,830
have to set up all these
different tunnels for all

87
00:04:38,830 --> 00:04:40,280
the different customers.

88
00:04:40,280 --> 00:04:43,450
That's why we like
layer 3 MPLS VPN.

89
00:04:43,450 --> 00:04:46,250
It's because we don't
have to do that.

90
00:04:46,250 --> 00:04:48,700
So clearly, given
everything we just said,

91
00:04:48,700 --> 00:04:51,820
we needed a better solution.

92
00:04:51,820 --> 00:04:56,440
And that better solution really
should meet these criteria.

93
00:04:56,440 --> 00:05:00,170
Number one, it should be
a single routing protocol.

94
00:05:00,170 --> 00:05:03,520
We don't want to have to support
multiple routing protocols.

95
00:05:03,520 --> 00:05:08,350
It's also going to have to be
very scalable because, again,

96
00:05:08,350 --> 00:05:13,270
it has to handle all the
routes from all the customers.

97
00:05:13,270 --> 00:05:16,970
It also needs to be
easily extensible.

98
00:05:16,970 --> 00:05:20,290
We need this to be able to
support additional information.

99
00:05:20,290 --> 00:05:23,830
We'll see why we need to support
that additional information

100
00:05:23,830 --> 00:05:25,670
as we go.

101
00:05:25,670 --> 00:05:28,870
And it also needs to
be designed to run

102
00:05:28,870 --> 00:05:31,690
between those
nonconnected neighbors.

103
00:05:31,690 --> 00:05:35,350
It just so happens that we
have a routing protocol that

104
00:05:35,350 --> 00:05:38,210
meets all of these criteria.

105
00:05:38,210 --> 00:05:41,920
And of course,
that would be BGP.

106
00:05:41,920 --> 00:05:44,860
Now, there is one thing
not addressed by this yet.

107
00:05:44,860 --> 00:05:47,800
And that is if we
use one protocol--

108
00:05:47,800 --> 00:05:50,800
again, BGP-- this
really does not

109
00:05:50,800 --> 00:05:54,160
solve the problem of
allowing customers to have

110
00:05:54,160 --> 00:05:57,010
those overlapping IP addresses.

111
00:05:57,010 --> 00:06:00,190
Again, if we tried to do
overlapping address spaces,

112
00:06:00,190 --> 00:06:05,680
even with BGP, the routers would
just see this as multiple paths

113
00:06:05,680 --> 00:06:08,020
to the same destination.

114
00:06:08,020 --> 00:06:11,350
And theoretically, they
might try to do multipathing.

115
00:06:11,350 --> 00:06:13,660
That probably wouldn't
work out too well.

116
00:06:13,660 --> 00:06:17,320
Imagine if we start doing load
sharing between customer A

117
00:06:17,320 --> 00:06:22,030
and B. Each customer gets
half of their own traffic

118
00:06:22,030 --> 00:06:24,760
and half the competitor's
traffic, possibly.

119
00:06:24,760 --> 00:06:27,740
So this would
definitely be a problem.

120
00:06:27,740 --> 00:06:33,380
So we still need a way to deal
with overlapping address space.

121
00:06:33,380 --> 00:06:35,840
So how exactly are
we going to do that?

122
00:06:35,840 --> 00:06:39,220
Well, to support the
overlapping addresses,

123
00:06:39,220 --> 00:06:43,540
we're going to have to
modify those routes in order

124
00:06:43,540 --> 00:06:45,700
to make them unique.

125
00:06:45,700 --> 00:06:48,650
They can't be the same anymore.

126
00:06:48,650 --> 00:06:50,620
So yes, we're
going to carry them

127
00:06:50,620 --> 00:06:53,110
in BGP, as we've already said.

128
00:06:53,110 --> 00:06:58,450
But they need to be unique
before we send them into BGP.

129
00:06:58,450 --> 00:07:02,650
The way we do this is
with a new number that

130
00:07:02,650 --> 00:07:06,500
is going to be prepended to
the front of the address.

131
00:07:06,500 --> 00:07:11,710
And we're going to call this a
Route Distinguisher, or an RD.

132
00:07:11,710 --> 00:07:15,850
Now, some attributes of that
route distinguisher-- first,

133
00:07:15,850 --> 00:07:18,310
it is a 64-bit number.

134
00:07:18,310 --> 00:07:20,900
We wanted to make sure that
we weren't going to run out.

135
00:07:20,900 --> 00:07:23,740
So we've given it
plenty of bit space.

136
00:07:23,740 --> 00:07:26,980
This is going to be
configured in the VRF.

137
00:07:26,980 --> 00:07:31,900
We use it for both
IPv4 and IPv6.

138
00:07:31,900 --> 00:07:33,730
But here's the thing.

139
00:07:33,730 --> 00:07:38,200
If you take 64 bits
and you add that

140
00:07:38,200 --> 00:07:43,510
to the front of either
32 bits for IPv4

141
00:07:43,510 --> 00:07:50,440
or 128 bits for IPv6 addresses,
what do you end up with?

142
00:07:50,440 --> 00:07:55,220
You end up with a route that
is either 96 bits, of course,

143
00:07:55,220 --> 00:08:01,270
for IPv4 or 192 bits for IPv6.

144
00:08:01,270 --> 00:08:02,950
And guess what.

145
00:08:02,950 --> 00:08:09,400
That means that those prefixes
are no longer IPv4 four or IPv6

146
00:08:09,400 --> 00:08:13,660
routes, because IPv4
routes are 32 bit.

147
00:08:13,660 --> 00:08:16,760
And IPv6 routes are 128 bit.

148
00:08:16,760 --> 00:08:19,690
So as soon as we modify
them, they're not routes

149
00:08:19,690 --> 00:08:21,890
for those protocols anymore.

150
00:08:21,890 --> 00:08:25,210
So instead, we come up
with a new name for them.

151
00:08:25,210 --> 00:08:30,580
And they are called
VPNv4 and VPNv6 routes.

152
00:08:30,580 --> 00:08:36,669
And of course, those are 96
and 192 bits respectfully.

153
00:08:36,669 --> 00:08:39,669
And just in case you didn't
put this together yet,

154
00:08:39,669 --> 00:08:44,350
this is why it's
multiprotocol BGP in the core,

155
00:08:44,350 --> 00:08:49,930
because it's not carrying
standard IPv4 or IPv6 routes,

156
00:08:49,930 --> 00:08:51,710
although it still can.

157
00:08:51,710 --> 00:08:55,870
We can do things like internet
handoff inside the MPLS core

158
00:08:55,870 --> 00:08:58,990
and some things like that,
where we may still want to carry

159
00:08:58,990 --> 00:09:01,700
standard IPv4 and IPv6 routes.

160
00:09:01,700 --> 00:09:04,270
But for our current
topic, they're

161
00:09:04,270 --> 00:09:08,560
going to be VPNv4
and VPNv6 routes.

162
00:09:08,560 --> 00:09:11,480
And to support all
of those things,

163
00:09:11,480 --> 00:09:13,700
well, that sounds like more
than one protocol to me,

164
00:09:13,700 --> 00:09:15,730
so it's multiprotocol BGP.

165
00:09:15,730 --> 00:09:18,630

166
00:09:18,630 --> 00:09:21,520
So I'm pretty sure
that's what we just said.

167
00:09:21,520 --> 00:09:25,350
Since we're carrying
VPNv4 and VPNv6,

168
00:09:25,350 --> 00:09:29,850
it's Multiprotocol, or MP, BGP.

169
00:09:29,850 --> 00:09:34,620
So again, this will be carrying
the VPNv4 and the VPNv6 routes

170
00:09:34,620 --> 00:09:39,030
specifically between
the PEs in the core.

171
00:09:39,030 --> 00:09:43,200
Also, sort of important
here is the next hop

172
00:09:43,200 --> 00:09:49,710
on these updates will be set to
the advertising PE's address,

173
00:09:49,710 --> 00:09:55,836
usually and preferably a
loopback interface on that PE.

174
00:09:55,836 --> 00:09:59,730
So let's go ahead and jump
back over to our topology

175
00:09:59,730 --> 00:10:02,400
and take a look at
how this would work

176
00:10:02,400 --> 00:10:05,700
in a practical environment.

177
00:10:05,700 --> 00:10:07,580
So here we have our environment.

178
00:10:07,580 --> 00:10:11,060
As we discussed before,
we have our VRFs A and B

179
00:10:11,060 --> 00:10:14,460
that we put in here
in our previous video.

180
00:10:14,460 --> 00:10:16,190
So what we're going
to be doing is

181
00:10:16,190 --> 00:10:21,980
running a multiprotocol BGP
session between the two PE

182
00:10:21,980 --> 00:10:23,460
routers.

183
00:10:23,460 --> 00:10:27,770
Now, keep in mind, this is just
a logical discussion right now.

184
00:10:27,770 --> 00:10:32,060
In the real world, this
multiprotocol BGP session

185
00:10:32,060 --> 00:10:35,570
would most likely be running
through a route reflector

186
00:10:35,570 --> 00:10:39,770
or a pair of route reflectors
in the service provider core.

187
00:10:39,770 --> 00:10:41,770
I'm not going to draw
this on the diagram,

188
00:10:41,770 --> 00:10:43,520
just because we have
a lot of things we're

189
00:10:43,520 --> 00:10:44,960
going to talk about on here.

190
00:10:44,960 --> 00:10:47,450
But realistically,
we're not going

191
00:10:47,450 --> 00:10:49,640
to be peering the
PE routers directly

192
00:10:49,640 --> 00:10:52,820
to each other with
multiprotocol BGP.

193
00:10:52,820 --> 00:10:55,400
Again, there would
be a route reflector.

194
00:10:55,400 --> 00:10:58,010
In our next skill,
we are actually

195
00:10:58,010 --> 00:11:00,500
going to be implementing
this on the command line.

196
00:11:00,500 --> 00:11:04,020
And we will be using a route
reflector when we do that.

197
00:11:04,020 --> 00:11:06,830
So on a practical
scale, yes, this

198
00:11:06,830 --> 00:11:08,990
would be using route
reflectors, preferably

199
00:11:08,990 --> 00:11:10,640
redundant route reflectors.

200
00:11:10,640 --> 00:11:12,920
But here we're just
going to draw it as

201
00:11:12,920 --> 00:11:14,820
if they're directly connected.

202
00:11:14,820 --> 00:11:17,810
Now, keep in mind, the
other thing we discussed

203
00:11:17,810 --> 00:11:21,140
is we also need
root distinguishers.

204
00:11:21,140 --> 00:11:24,590
So for example,
maybe for customer A,

205
00:11:24,590 --> 00:11:31,595
we would give this customer a
route distinguisher of 100:1.

206
00:11:31,595 --> 00:11:34,520
And maybe for customer
two, we give them

207
00:11:34,520 --> 00:11:38,600
a route distinguisher of 100:2.

208
00:11:38,600 --> 00:11:42,320
So what happens now, when
this address is advertised up

209
00:11:42,320 --> 00:11:46,910
to the PE router and the PE
router redistributes this

210
00:11:46,910 --> 00:11:48,380
into BGP--

211
00:11:48,380 --> 00:11:51,600
which we'll be talking about
this process coming up.

212
00:11:51,600 --> 00:11:55,220
But when customer
B's network actually

213
00:11:55,220 --> 00:11:59,300
shows up in multiprotocol
BGP in the core,

214
00:11:59,300 --> 00:12:01,530
it's actually going
to look like this.

215
00:12:01,530 --> 00:12:12,050
It's going to be
100:2:10.1.1.0/24.

216
00:12:12,050 --> 00:12:17,330
And again, this
is a VPNv4 route.

217
00:12:17,330 --> 00:12:20,780
But the main point here is
that the route distinguisher

218
00:12:20,780 --> 00:12:24,380
is put in front of
the customer's prefix

219
00:12:24,380 --> 00:12:26,330
that they're advertising.

220
00:12:26,330 --> 00:12:29,750
Of course, customer A's network
over here would look like

221
00:12:29,750 --> 00:12:38,630
100:1:10.1.1.0/24.

222
00:12:38,630 --> 00:12:42,260
And hopefully, we can all see
that because of this 2 right

223
00:12:42,260 --> 00:12:45,380
here and this 1
right here, these

224
00:12:45,380 --> 00:12:48,950
are no longer
overlapping addresses.

225
00:12:48,950 --> 00:12:51,210
They are now unique.

226
00:12:51,210 --> 00:12:54,950
So now we can pass the
routes from the VRFs

227
00:12:54,950 --> 00:12:59,540
into multiprotocol BGP
and keep them unique

228
00:12:59,540 --> 00:13:04,370
and not cause overlapping
address problems.

229
00:13:04,370 --> 00:13:07,120
So in this video,
we talked about how

230
00:13:07,120 --> 00:13:11,590
to get the customer routes
between the PEs in the service

231
00:13:11,590 --> 00:13:13,140
provider core.

232
00:13:13,140 --> 00:13:16,340
Two main aspects that we
have to worry about here.

233
00:13:16,340 --> 00:13:18,880
Number one is the
routing protocol.

234
00:13:18,880 --> 00:13:21,910
Well, we know we're going
to run multiprotocol BGP.

235
00:13:21,910 --> 00:13:23,890
And we know that
that's going to follow

236
00:13:23,890 --> 00:13:27,730
a typical BGP-type architecture,
using, most likely,

237
00:13:27,730 --> 00:13:29,110
route reflectors.

238
00:13:29,110 --> 00:13:31,490
The other thing we have
to worry about, of course,

239
00:13:31,490 --> 00:13:34,210
is that overlapping
address space.

240
00:13:34,210 --> 00:13:38,800
The way we handle that is
by assigning a 64-bit route

241
00:13:38,800 --> 00:13:41,950
distinguisher to each VRF.

242
00:13:41,950 --> 00:13:44,380
Now, as you can see
in our example here,

243
00:13:44,380 --> 00:13:46,810
we used the same
route distinguisher

244
00:13:46,810 --> 00:13:49,540
for each side of
the same customer.

245
00:13:49,540 --> 00:13:52,600
We just kept it unique
between customers.

246
00:13:52,600 --> 00:13:55,810
And you can certainly do that,
although a lot of service

247
00:13:55,810 --> 00:13:59,200
providers simply provide a
unique route distinguisher

248
00:13:59,200 --> 00:14:01,790
for each customer's
each location.

249
00:14:01,790 --> 00:14:04,690
So they're pretty
much all different.

250
00:14:04,690 --> 00:14:07,880
But either way,
this 64-bit number

251
00:14:07,880 --> 00:14:10,120
now makes the
addresses unique so

252
00:14:10,120 --> 00:14:13,750
that they can travel through
BGP without BGP thinking

253
00:14:13,750 --> 00:14:15,730
it's just doing multipathing.

254
00:14:15,730 --> 00:14:20,260
Now, the next problem
comes in when this BGP

255
00:14:20,260 --> 00:14:23,680
update reaches the other PE.

256
00:14:23,680 --> 00:14:28,570
How does the other PE know, by
looking at these updates, which

257
00:14:28,570 --> 00:14:31,510
VRF to put the route in?

258
00:14:31,510 --> 00:14:33,830
Well, that's what we
have to talk about next.

259
00:14:33,830 --> 00:14:37,690
But until then, I hope this
has been informative for you,

260
00:14:37,690 --> 00:14:40,830
and I'd like to thank
you for viewing.

261
00:14:40,830 --> 00:14:44,000