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

2
00:00:03,984 --> 00:00:07,980

3
00:00:07,980 --> 00:00:10,200
So the next thing we
want to look at here

4
00:00:10,200 --> 00:00:16,590
is loop prevention with
OSPF in an MPLS layer 3 VPN

5
00:00:16,590 --> 00:00:17,860
environment.

6
00:00:17,860 --> 00:00:22,770
So we'll start off with a
decent discussion on our diagram

7
00:00:22,770 --> 00:00:27,030
about what the problem is and
why we need the downward bit

8
00:00:27,030 --> 00:00:28,380
to address it.

9
00:00:28,380 --> 00:00:31,140
The fact of the matter
is the downward bit

10
00:00:31,140 --> 00:00:33,510
is set automatically
on our equipment.

11
00:00:33,510 --> 00:00:35,850
And this isn't something
that we really need

12
00:00:35,850 --> 00:00:37,630
to be overly concerned with.

13
00:00:37,630 --> 00:00:40,650
But you do have to
understand why it's needed

14
00:00:40,650 --> 00:00:43,540
and when and how it gets set.

15
00:00:43,540 --> 00:00:45,850
The other thing that's
going to be of concern

16
00:00:45,850 --> 00:00:49,200
and we'll spend a decent
amount of time on in this video

17
00:00:49,200 --> 00:00:52,320
is how this affects
our customers

18
00:00:52,320 --> 00:00:58,890
if they, for whatever reason,
choose to use a VRF for OSPF

19
00:00:58,890 --> 00:01:00,420
in their environment.

20
00:01:00,420 --> 00:01:02,370
That's going to become an issue.

21
00:01:02,370 --> 00:01:05,050
And we have to talk
about how to handle that.

22
00:01:05,050 --> 00:01:07,660
So those are going to
be our two main topics--

23
00:01:07,660 --> 00:01:11,550
why we need the downward bit
and how that downward bit

24
00:01:11,550 --> 00:01:16,630
is going to be dealt with if the
customer decides to run a VRF.

25
00:01:16,630 --> 00:01:18,450
So let's go ahead and jump in.

26
00:01:18,450 --> 00:01:20,820
Again, we'll start
off on that diagram,

27
00:01:20,820 --> 00:01:23,460
talking about what
the actual problem is

28
00:01:23,460 --> 00:01:27,780
and why we need the
downward bit to begin with.

29
00:01:27,780 --> 00:01:33,050
So here's why we need loop
prevention for OSPF in the MPLS

30
00:01:33,050 --> 00:01:34,230
environment.

31
00:01:34,230 --> 00:01:36,800
Let's take, for
example, this prefix

32
00:01:36,800 --> 00:01:40,820
up here on router 6 at
customer A's headquarters.

33
00:01:40,820 --> 00:01:44,150
This prefix, of course, is
going to get advertised up here

34
00:01:44,150 --> 00:01:46,130
to router 1.

35
00:01:46,130 --> 00:01:49,370
This is going to get
redistributed on router 1, who

36
00:01:49,370 --> 00:01:53,250
is going to send it through
BGP up to the route reflector.

37
00:01:53,250 --> 00:01:55,010
And then of course,
the route reflector

38
00:01:55,010 --> 00:01:58,640
is going to reflect this
back down to router 5.

39
00:01:58,640 --> 00:02:02,480
At this point, router 5
is learning this update

40
00:02:02,480 --> 00:02:05,180
through iBGP.

41
00:02:05,180 --> 00:02:11,720
And let's keep in mind that iBGP
has an admin distance of 200.

42
00:02:11,720 --> 00:02:14,360
It's then going to
take this update

43
00:02:14,360 --> 00:02:18,650
and redistribute
it back into OSPF.

44
00:02:18,650 --> 00:02:24,080
This update now gets sent
via OSPF to router 8.

45
00:02:24,080 --> 00:02:26,610
Now, it will send it
to router 9 as well.

46
00:02:26,610 --> 00:02:28,790
But that's not our
discussion at the moment.

47
00:02:28,790 --> 00:02:32,090
I'm trying to show you
how the loop can occur.

48
00:02:32,090 --> 00:02:34,640
Router 8 gets the
update, sends it

49
00:02:34,640 --> 00:02:37,730
through this potential backdoor
link between the customer's

50
00:02:37,730 --> 00:02:40,730
sites up here to router 9.

51
00:02:40,730 --> 00:02:43,670
Now, of course, if
the customer did not

52
00:02:43,670 --> 00:02:47,490
have this backdoor link,
this wouldn't be happening.

53
00:02:47,490 --> 00:02:51,310
However, we have to assume that
the customer might have this.

54
00:02:51,310 --> 00:02:53,960
This might not be
two different sites.

55
00:02:53,960 --> 00:02:59,280
Maybe this is just dual-attached
routers at the same site.

56
00:02:59,280 --> 00:03:02,750
So in my example, yes, I drew
it as two different sites.

57
00:03:02,750 --> 00:03:04,080
But it doesn't have to be.

58
00:03:04,080 --> 00:03:07,310
Again, it could just be dual
routers at the same site.

59
00:03:07,310 --> 00:03:10,100
For whatever reason,
routers 8 and 9

60
00:03:10,100 --> 00:03:13,250
are directly connected
through OSPF.

61
00:03:13,250 --> 00:03:15,890
And here's where the
potential problem comes in.

62
00:03:15,890 --> 00:03:18,830
Router 9 could
potentially advertise this

63
00:03:18,830 --> 00:03:21,560
back up to router 5.

64
00:03:21,560 --> 00:03:24,650
Now, remember, this is
coming from OSPF now.

65
00:03:24,650 --> 00:03:29,330
That means that this will
have an admin distance of 110.

66
00:03:29,330 --> 00:03:32,660
110 beats 200.

67
00:03:32,660 --> 00:03:35,540
So the potential
problem is that router 5

68
00:03:35,540 --> 00:03:41,360
discards the iBGP update and
starts following this OSPF

69
00:03:41,360 --> 00:03:43,560
route instead.

70
00:03:43,560 --> 00:03:45,680
So we can see the
potential problem here

71
00:03:45,680 --> 00:03:49,610
because we know that we've
lost the real route now.

72
00:03:49,610 --> 00:03:51,830
The route coming
from the other side

73
00:03:51,830 --> 00:03:56,028
is now potentially being
replaced by the loop.

74
00:03:56,028 --> 00:03:58,070
And if you're having any
trouble seeing the loop,

75
00:03:58,070 --> 00:04:00,230
just follow the green arrows.

76
00:04:00,230 --> 00:04:01,190
That's your loop.

77
00:04:01,190 --> 00:04:03,500
It's going to go router
5 to router 8 to router 9

78
00:04:03,500 --> 00:04:05,370
to router 5, and so on.

79
00:04:05,370 --> 00:04:08,790
So this is our
potential problem.

80
00:04:08,790 --> 00:04:11,810
Now, the very
simple fix for this

81
00:04:11,810 --> 00:04:17,630
would be to filter these routes
as they come in on router 5.

82
00:04:17,630 --> 00:04:23,270
Router 5 should not be
learning any routes from OSPF

83
00:04:23,270 --> 00:04:25,950
that belong to the other side--

84
00:04:25,950 --> 00:04:29,180
in other words to customer
A's headquarters over here,

85
00:04:29,180 --> 00:04:32,400
this prefix that we
started off with.

86
00:04:32,400 --> 00:04:36,560
So this is exactly where
the downward bit comes in.

87
00:04:36,560 --> 00:04:39,795
Now, before we jump into
it, are there other ways

88
00:04:39,795 --> 00:04:40,670
we could filter this?

89
00:04:40,670 --> 00:04:42,960
Are there other
things we can do?

90
00:04:42,960 --> 00:04:44,160
Of course.

91
00:04:44,160 --> 00:04:46,820
If you have been following along
through this entire course,

92
00:04:46,820 --> 00:04:49,010
you know we have a
lot of things that we

93
00:04:49,010 --> 00:04:51,140
can do to filter routes.

94
00:04:51,140 --> 00:04:55,790
But OSPF gives us a built-in
method called the downward bit.

95
00:04:55,790 --> 00:04:57,900
And here's how it works.

96
00:04:57,900 --> 00:05:00,770
Remember that we
are using VRFs here

97
00:05:00,770 --> 00:05:04,100
on router 5 for each
of these customers.

98
00:05:04,100 --> 00:05:08,630
Whenever you are
running OSPF in a VRF,

99
00:05:08,630 --> 00:05:12,350
that router acts like a PE.

100
00:05:12,350 --> 00:05:14,090
We have that sort
of buried in there.

101
00:05:14,090 --> 00:05:16,580
But it's acting like a PE.

102
00:05:16,580 --> 00:05:17,970
What does that mean?

103
00:05:17,970 --> 00:05:21,920
It means that it's implementing
PE loop prevention.

104
00:05:21,920 --> 00:05:25,470
PE loop prevention
does two things.

105
00:05:25,470 --> 00:05:31,640
Number one, when the root is
first redistributed into OSPF,

106
00:05:31,640 --> 00:05:35,210
it's going to set the
downward bit on this update

107
00:05:35,210 --> 00:05:38,000
as it's sent into OSPF.

108
00:05:38,000 --> 00:05:42,020
Now, router 8 here,
which is not using a VRF,

109
00:05:42,020 --> 00:05:45,500
and router 9, which
is not using a VRF,

110
00:05:45,500 --> 00:05:48,810
will simply ignore
that downward bit.

111
00:05:48,810 --> 00:05:52,680
So what happens is as the update
is sent between the routers

112
00:05:52,680 --> 00:05:55,190
now, this downward
bit is carried

113
00:05:55,190 --> 00:05:56,970
through the environment.

114
00:05:56,970 --> 00:05:59,300
And if this route were
to get echoed back up

115
00:05:59,300 --> 00:06:02,720
here to router 5,
it would again have

116
00:06:02,720 --> 00:06:04,820
the downward bit set on it.

117
00:06:04,820 --> 00:06:07,730
This is where the second thing
that PE loop prevention does

118
00:06:07,730 --> 00:06:09,020
kicks in.

119
00:06:09,020 --> 00:06:13,850
If you receive an update
with the downward bit set

120
00:06:13,850 --> 00:06:21,740
on it from OSPF in a VRF,
you discard that update.

121
00:06:21,740 --> 00:06:23,910
And you do not use it.

122
00:06:23,910 --> 00:06:27,320
And that is where our
loop prevention comes in.

123
00:06:27,320 --> 00:06:29,780
Now, we're going to jump
into the command line.

124
00:06:29,780 --> 00:06:33,650
And we'll see that the OSPF
routes have this downward bit

125
00:06:33,650 --> 00:06:35,090
set on them.

126
00:06:35,090 --> 00:06:37,530
As I said during
the introduction,

127
00:06:37,530 --> 00:06:40,490
the problem here isn't
setting the downward bit.

128
00:06:40,490 --> 00:06:42,560
The equipment does this for us.

129
00:06:42,560 --> 00:06:45,810
We just need to understand
what it does, why it's there,

130
00:06:45,810 --> 00:06:47,720
and understand
its functionality.

131
00:06:47,720 --> 00:06:49,430
But now let's go
ahead and take a look

132
00:06:49,430 --> 00:06:51,920
at the potential problem
with the downward bit

133
00:06:51,920 --> 00:06:55,470
from the customer's perspective.

134
00:06:55,470 --> 00:06:58,470
What happens if for any reason--

135
00:06:58,470 --> 00:07:00,870
and it's not really
for us to decide,

136
00:07:00,870 --> 00:07:02,670
because we're not the customer.

137
00:07:02,670 --> 00:07:05,400
What if the customer
decides that they

138
00:07:05,400 --> 00:07:10,230
want to use a VRF up here
on router 8 for their OSPF

139
00:07:10,230 --> 00:07:11,550
environment?

140
00:07:11,550 --> 00:07:13,920
Well, the problem
is their router

141
00:07:13,920 --> 00:07:18,660
8 will then assume, since
you're running OSPF in a VRF,

142
00:07:18,660 --> 00:07:22,290
that it is supposed
to act like a PE.

143
00:07:22,290 --> 00:07:24,930
And as soon as it's
supposed to act like a PE,

144
00:07:24,930 --> 00:07:29,310
not only would it start setting
the downward bit on its routes

145
00:07:29,310 --> 00:07:30,370
potentially.

146
00:07:30,370 --> 00:07:32,910
But the more important
thing is the discarding

147
00:07:32,910 --> 00:07:36,360
of these updates would start
happening right up here now,

148
00:07:36,360 --> 00:07:39,480
because now the routes coming
from the service provider

149
00:07:39,480 --> 00:07:41,430
have the downward bit set.

150
00:07:41,430 --> 00:07:44,490
And router 8 is
acting like a PE.

151
00:07:44,490 --> 00:07:47,160
So essentially, we
need a way to tell

152
00:07:47,160 --> 00:07:51,870
router 8 that just because
you're running OSPF in a VRF

153
00:07:51,870 --> 00:07:55,260
does not mean you are a PE.

154
00:07:55,260 --> 00:07:57,420
And for this, we have
a particular feature

155
00:07:57,420 --> 00:07:58,770
we're going to be looking at.

156
00:07:58,770 --> 00:08:02,310
This is called VRF-Lite.

157
00:08:02,310 --> 00:08:03,900
So these are the
things we're going

158
00:08:03,900 --> 00:08:06,540
to look at as we jump
into the command line.

159
00:08:06,540 --> 00:08:08,130
First, we'll just
look at the updates

160
00:08:08,130 --> 00:08:10,170
and see that they have
the downward bit set.

161
00:08:10,170 --> 00:08:11,970
And then we'll
take a look at what

162
00:08:11,970 --> 00:08:16,860
happens if a customer
actually wants to use a VRF.

163
00:08:16,860 --> 00:08:19,530
We'll actually go ahead and
implement this on router 6.

164
00:08:19,530 --> 00:08:22,330
But either way, it
works the same way.

165
00:08:22,330 --> 00:08:23,790
It's just less
interfaces to have

166
00:08:23,790 --> 00:08:27,460
to move to demonstrate
how VRF-Lite works.

167
00:08:27,460 --> 00:08:29,550
So all of that
said, let's go ahead

168
00:08:29,550 --> 00:08:32,100
and jump into the command
line and take a look

169
00:08:32,100 --> 00:08:34,610
at the downward bit.

170
00:08:34,610 --> 00:08:39,350
So we'll start here on router
5, looking at the update coming

171
00:08:39,350 --> 00:08:41,850
in for router 6's loopback.

172
00:08:41,850 --> 00:08:44,430
So we're going to want to look
at the OSPF database here.

173
00:08:44,430 --> 00:08:49,760
So we'll say show ip
ospf for the process 101.

174
00:08:49,760 --> 00:08:51,000
We'll look for the database.

175
00:08:51,000 --> 00:08:53,100
This is going to
be a type 3 LSA.

176
00:08:53,100 --> 00:08:54,740
So it will be a summary.

177
00:08:54,740 --> 00:08:57,620
And we're looking for 10.6.6.6.

178
00:08:57,620 --> 00:08:59,870
What we're looking
for here is simply

179
00:08:59,870 --> 00:09:02,930
that it has this
flag under Options,

180
00:09:02,930 --> 00:09:05,510
where it says Downward.

181
00:09:05,510 --> 00:09:08,390
If you look at a prefix that
does not have the downward bit

182
00:09:08,390 --> 00:09:12,470
set, this will
simply say Upward.

183
00:09:12,470 --> 00:09:16,820
So like I said, actually setting
the downward bit isn't anything

184
00:09:16,820 --> 00:09:18,020
we need to worry about.

185
00:09:18,020 --> 00:09:21,240
We just wanted to be
aware of how it operates.

186
00:09:21,240 --> 00:09:23,540
What we really
want to do here is

187
00:09:23,540 --> 00:09:28,050
see what happens if a
customer tries to use a VRF.

188
00:09:28,050 --> 00:09:31,900
So for that, let's
jump over to router 6.

189
00:09:31,900 --> 00:09:33,790
So what we're going
to do is we're simply

190
00:09:33,790 --> 00:09:35,920
going to create a VRF here.

191
00:09:35,920 --> 00:09:38,950
We'll just call it
WAN, for example.

192
00:09:38,950 --> 00:09:41,470
We'll activate our
address-family.

193
00:09:41,470 --> 00:09:43,600
If we do a show ip
interface brief,

194
00:09:43,600 --> 00:09:46,330
this will give us an
idea of the interfaces

195
00:09:46,330 --> 00:09:49,370
that we need to
move into the VRF.

196
00:09:49,370 --> 00:09:53,410
So the first thing we want to do
is go into interface gigabit 1.

197
00:09:53,410 --> 00:09:56,320
We'll say vrf forwarding WAN.

198
00:09:56,320 --> 00:09:59,540
This will, of course, remove
the IP address from it.

199
00:09:59,540 --> 00:10:01,420
So we'll have to
put that back on.

200
00:10:01,420 --> 00:10:07,000
The IP address here
was 192.168.16.6.

201
00:10:07,000 --> 00:10:09,580
And this was a /24.

202
00:10:09,580 --> 00:10:11,960
So that puts the IP
address back on there.

203
00:10:11,960 --> 00:10:15,130
We also need to move our
interface loopback 0 interface,

204
00:10:15,130 --> 00:10:17,420
since that's what
we were focusing on.

205
00:10:17,420 --> 00:10:20,380
So again, vrf forwarding WAN.

206
00:10:20,380 --> 00:10:23,660
This is saying it removed
an IPv6 address as well.

207
00:10:23,660 --> 00:10:24,460
And that's OK.

208
00:10:24,460 --> 00:10:26,720
We're not going to worry
about that for right now.

209
00:10:26,720 --> 00:10:31,600
We're just going to put our /32
loopback address back on here

210
00:10:31,600 --> 00:10:33,490
for IPv4.

211
00:10:33,490 --> 00:10:36,280
Finally, we also need to
move our loopback 100.

212
00:10:36,280 --> 00:10:39,280
This is the loopback that's
simply sort of pretending

213
00:10:39,280 --> 00:10:43,900
to be the customer network, the
customer LAN side, if you will.

214
00:10:43,900 --> 00:10:47,590
If we do a show vrf, we see that
we've now successfully moved

215
00:10:47,590 --> 00:10:51,970
our gigabit 1, our loopback 0,
and our loopback 100 interfaces

216
00:10:51,970 --> 00:10:54,880
into the VRF called WAN.

217
00:10:54,880 --> 00:10:59,770
Now, the problem is right
now, our OSPF process

218
00:10:59,770 --> 00:11:04,070
has been operating in
the global routing table.

219
00:11:04,070 --> 00:11:06,490
So what we need to
do is we now need

220
00:11:06,490 --> 00:11:10,390
to say "no router ospf
1" in order to get rid

221
00:11:10,390 --> 00:11:12,370
of that global process.

222
00:11:12,370 --> 00:11:17,260
Then we'll say "router
ospf 1" for the vrf WAN.

223
00:11:17,260 --> 00:11:19,810
We'll set our router ID again.

224
00:11:19,810 --> 00:11:22,930
And we'll just again use a
network statement that brings

225
00:11:22,930 --> 00:11:26,410
all the networks into area 0.

226
00:11:26,410 --> 00:11:28,190
We'll exit out of configuration.

227
00:11:28,190 --> 00:11:30,410
And if we give this
just a few seconds,

228
00:11:30,410 --> 00:11:32,980
our OSPF neighborship
with router 1

229
00:11:32,980 --> 00:11:36,770
should come back up in this VRF.

230
00:11:36,770 --> 00:11:38,950
So here we have our
neighborship back up.

231
00:11:38,950 --> 00:11:42,310
And let's go back over
to router 1 and take

232
00:11:42,310 --> 00:11:44,030
a look at our routes.

233
00:11:44,030 --> 00:11:46,210
So the first thing we
see here on the console

234
00:11:46,210 --> 00:11:49,030
is where the neighborship
went down, when we first

235
00:11:49,030 --> 00:11:50,230
started configuring.

236
00:11:50,230 --> 00:11:52,270
And it came back up
when we were done

237
00:11:52,270 --> 00:11:55,010
configuring the OSPF process.

238
00:11:55,010 --> 00:11:59,530
But if we were to say show
ip route for vrf Customer A,

239
00:11:59,530 --> 00:12:05,230
the main thing we want to see
here is that the 10.6.6.6/32 is

240
00:12:05,230 --> 00:12:06,310
still coming in.

241
00:12:06,310 --> 00:12:09,820
Well, it's coming in
as of 35 seconds ago,

242
00:12:09,820 --> 00:12:12,220
when we just reconfigured it.

243
00:12:12,220 --> 00:12:13,810
What's the point?

244
00:12:13,810 --> 00:12:19,000
The point here is that using
a VRF on the customer router

245
00:12:19,000 --> 00:12:22,720
is not affecting the
customer's routes from coming

246
00:12:22,720 --> 00:12:24,350
in to the service provider.

247
00:12:24,350 --> 00:12:27,010
In fact, we'll hop
over to router 8 and 9

248
00:12:27,010 --> 00:12:30,290
and see that router 6's routes
are still there as well.

249
00:12:30,290 --> 00:12:34,060
It's not a problem with the
outgoing routes, so to speak.

250
00:12:34,060 --> 00:12:37,640
The problem is going to
be on the incoming routes.

251
00:12:37,640 --> 00:12:39,970
So let's verify routers
8 and 9 real quick.

252
00:12:39,970 --> 00:12:42,700
And then we'll jump back
over to router 6 and see

253
00:12:42,700 --> 00:12:43,540
what's happening.

254
00:12:43,540 --> 00:12:47,270

255
00:12:47,270 --> 00:12:51,070
So again, here on router 8, we
see that we have the 10.6.6.6

256
00:12:51,070 --> 00:12:51,670
update.

257
00:12:51,670 --> 00:12:52,940
So that's good.

258
00:12:52,940 --> 00:12:59,720
And if we go to router 9, we
see the 10.6.6.6 here as well.

259
00:12:59,720 --> 00:13:02,590
So again, not
affecting the outgoing

260
00:13:02,590 --> 00:13:04,210
routes from the customer.

261
00:13:04,210 --> 00:13:06,370
But of course,
here's the problem.

262
00:13:06,370 --> 00:13:09,250
If we go back over
to router 6, and we

263
00:13:09,250 --> 00:13:13,270
were to say show ip
route for the vrf WAN,

264
00:13:13,270 --> 00:13:16,130
well, as you can see,
there's nothing here,

265
00:13:16,130 --> 00:13:18,260
except local and connected.

266
00:13:18,260 --> 00:13:20,680
And again, this is
because the updates

267
00:13:20,680 --> 00:13:24,250
are coming in from the service
provider with the downward bit

268
00:13:24,250 --> 00:13:24,880
set.

269
00:13:24,880 --> 00:13:28,480
And of course, router 6
is now throwing those away

270
00:13:28,480 --> 00:13:31,940
because it's implementing
PE loop prevention.

271
00:13:31,940 --> 00:13:34,460
Now, we already mentioned
how to fix this.

272
00:13:34,460 --> 00:13:38,410
So let's go ahead and turn
on the feature VRF-Lite.

273
00:13:38,410 --> 00:13:40,330
And then we'll see
how we suddenly

274
00:13:40,330 --> 00:13:42,400
start getting all
of our updates back

275
00:13:42,400 --> 00:13:47,080
in on router 6, because it's
no longer acting as a PE.

276
00:13:47,080 --> 00:13:48,940
Now, a couple of things
to look at before we

277
00:13:48,940 --> 00:13:50,920
actually turn on
the feature though.

278
00:13:50,920 --> 00:13:56,740
First, let's do a show ip ospf
database for the 10.8.8.8.

279
00:13:56,740 --> 00:13:59,650
What we want to see here
is that we are, in fact,

280
00:13:59,650 --> 00:14:01,090
receiving the update.

281
00:14:01,090 --> 00:14:03,500
It's in our database.

282
00:14:03,500 --> 00:14:05,530
It just has the
downward bit set.

283
00:14:05,530 --> 00:14:07,580
And therefore, we
are not using it.

284
00:14:07,580 --> 00:14:09,070
We're discarding it.

285
00:14:09,070 --> 00:14:11,870
Discarding it, simply
meaning we're not using it.

286
00:14:11,870 --> 00:14:14,680
We're not going to discard
it from the OSPF database.

287
00:14:14,680 --> 00:14:17,300
But we're not going to use it.

288
00:14:17,300 --> 00:14:19,990
So let's go ahead into
configuration mode

289
00:14:19,990 --> 00:14:22,060
for router ospf 1.

290
00:14:22,060 --> 00:14:25,000
And this feature
is as easy as this.

291
00:14:25,000 --> 00:14:26,530
You say capability.

292
00:14:26,530 --> 00:14:28,600
And notice it doesn't
have a whole lot.

293
00:14:28,600 --> 00:14:32,890
But the one we're looking for,
of course, is the vrf-lite.

294
00:14:32,890 --> 00:14:35,680
And notice, it even
says on the description,

295
00:14:35,680 --> 00:14:40,000
"do not perform
PE-specific checks."

296
00:14:40,000 --> 00:14:43,720
It means to not look
at the downward bit.

297
00:14:43,720 --> 00:14:47,270
Do not implement
PE loop prevention.

298
00:14:47,270 --> 00:14:49,450
So let's go ahead and
turn that feature on.

299
00:14:49,450 --> 00:14:51,350
We'll exit out of configuration.

300
00:14:51,350 --> 00:14:54,370
Notice, as we do so that
it once again bounces

301
00:14:54,370 --> 00:14:56,590
that OSPF neighborship.

302
00:14:56,590 --> 00:14:58,450
So clearly, this would
need to be set up

303
00:14:58,450 --> 00:15:00,260
during a maintenance window.

304
00:15:00,260 --> 00:15:03,340
But either way, let's go ahead
and check our routing table

305
00:15:03,340 --> 00:15:04,820
again.

306
00:15:04,820 --> 00:15:07,870
So we'll do a show
ip route for vrf WAN.

307
00:15:07,870 --> 00:15:11,470
And we see here that all of our
OSPF routes for the other side

308
00:15:11,470 --> 00:15:12,590
are back.

309
00:15:12,590 --> 00:15:14,890
So there's still O IA routes.

310
00:15:14,890 --> 00:15:16,990
This doesn't affect
that in any way.

311
00:15:16,990 --> 00:15:20,980
But they are back because we
are ignoring the downward bit.

312
00:15:20,980 --> 00:15:23,840
It doesn't get rid
of the downward bit.

313
00:15:23,840 --> 00:15:25,840
If we look at our
database summary again,

314
00:15:25,840 --> 00:15:28,220
this entry looks
exactly the same.

315
00:15:28,220 --> 00:15:30,160
It still has the downward bit.

316
00:15:30,160 --> 00:15:35,340
We're just not using
it for loop prevention.

317
00:15:35,340 --> 00:15:38,150
So in this video,
we just took a look

318
00:15:38,150 --> 00:15:40,940
at how to do OSPF
loop prevention

319
00:15:40,940 --> 00:15:43,140
with the downward bit.

320
00:15:43,140 --> 00:15:45,810
And again, it's not that
we have to do anything.

321
00:15:45,810 --> 00:15:49,520
We just wanted to get a clear
understanding of how it works,

322
00:15:49,520 --> 00:15:52,610
and see that it gets set
automatically by the equipment,

323
00:15:52,610 --> 00:15:54,890
and how it shows
up in the database.

324
00:15:54,890 --> 00:15:57,210
And we did all those things.

325
00:15:57,210 --> 00:16:00,260
We also took a look at
how this can adversely

326
00:16:00,260 --> 00:16:04,460
affect a customer if they
want to, for whatever reason,

327
00:16:04,460 --> 00:16:07,760
use a VRF on the
customer router.

328
00:16:07,760 --> 00:16:12,380
But we also saw that there
is a feature in IOS XE called

329
00:16:12,380 --> 00:16:17,990
capability VRF-Lite that allows
us to turn off that PE loop

330
00:16:17,990 --> 00:16:21,860
prevention and allow those
routers to accept the routes,

331
00:16:21,860 --> 00:16:24,480
even if they have
the downward bit set.

332
00:16:24,480 --> 00:16:26,660
Now, the next thing
we want to look at

333
00:16:26,660 --> 00:16:33,110
is how to handle routes that
have a backup if we want to use

334
00:16:33,110 --> 00:16:36,470
MPLS as the primary path.

335
00:16:36,470 --> 00:16:38,660
That can be an
interesting problem,

336
00:16:38,660 --> 00:16:40,550
given that our
routes are currently

337
00:16:40,550 --> 00:16:43,260
showing up as O IA routes.

338
00:16:43,260 --> 00:16:47,000
So we have to implement
something called a sham link.

339
00:16:47,000 --> 00:16:50,100
And that's exactly
what we get to do next.

340
00:16:50,100 --> 00:16:53,510
Until then, I hope this has
been informative for you,

341
00:16:53,510 --> 00:16:56,710
and I'd like to thank
you for viewing.

342
00:16:56,710 --> 00:17:01,000