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

2
00:00:03,465 --> 00:00:08,130

3
00:00:08,130 --> 00:00:10,780
So the first PIM enhancement
that we want to look at

4
00:00:10,780 --> 00:00:13,390
is Anycast RP.

5
00:00:13,390 --> 00:00:16,780
The very simple concept here
is that we're going to take

6
00:00:16,780 --> 00:00:20,560
multiple devices, give
them an interface--

7
00:00:20,560 --> 00:00:24,970
we'll use a loopback interface
with the same IP address--

8
00:00:24,970 --> 00:00:28,000
advertise that into
our routing protocol,

9
00:00:28,000 --> 00:00:31,150
and then all of the other
devices on our network

10
00:00:31,150 --> 00:00:35,990
will go to the nearest
instance of that IP address.

11
00:00:35,990 --> 00:00:38,830
Now, since we could
hit any of the devices

12
00:00:38,830 --> 00:00:41,200
with that IP address,
it's, of course,

13
00:00:41,200 --> 00:00:45,320
imperative that those devices
are performing the same task--

14
00:00:45,320 --> 00:00:48,160
in other words, being
a rendezvous point.

15
00:00:48,160 --> 00:00:50,800
It's also critical
that they have

16
00:00:50,800 --> 00:00:53,830
the same information
keeping in mind,

17
00:00:53,830 --> 00:00:56,170
what is a rendezvous point for?

18
00:00:56,170 --> 00:01:00,670
It's to help us find the source
of a particular multicast

19
00:01:00,670 --> 00:01:01,580
group.

20
00:01:01,580 --> 00:01:06,800
So all of the RPs would have to
know about all of the groups.

21
00:01:06,800 --> 00:01:09,620
Now, here's where
the problem comes in.

22
00:01:09,620 --> 00:01:14,540
If a particular first hop
router registers a source

23
00:01:14,540 --> 00:01:18,620
with one instance
of the RP and then

24
00:01:18,620 --> 00:01:22,400
the client side or
the last hop router

25
00:01:22,400 --> 00:01:26,820
tries to get that group
from that particular source

26
00:01:26,820 --> 00:01:30,470
but contacts a different
instance of the RP,

27
00:01:30,470 --> 00:01:34,490
that other RP needs to
know about that source's

28
00:01:34,490 --> 00:01:35,750
availability.

29
00:01:35,750 --> 00:01:38,840
We call this a source
active message,

30
00:01:38,840 --> 00:01:44,480
and we exchange this using MSDP
or Multicast Source Discovery

31
00:01:44,480 --> 00:01:45,710
Protocol.

32
00:01:45,710 --> 00:01:47,420
Just as a quick note.

33
00:01:47,420 --> 00:01:52,220
On some other Cisco platforms
such as the Nexus platform,

34
00:01:52,220 --> 00:01:56,400
this can actually be
exchanged through PIM itself.

35
00:01:56,400 --> 00:02:01,310
These platforms do not support
that, so we will be using MSDP.

36
00:02:01,310 --> 00:02:03,800
But just be aware there
may be other methods

37
00:02:03,800 --> 00:02:09,090
to do Anycast on other platforms
if you ever run into those.

38
00:02:09,090 --> 00:02:13,640
But we're going to advertise
this Anycast address using

39
00:02:13,640 --> 00:02:18,810
BSR, which is simply a method to
advertise the rendezvous point.

40
00:02:18,810 --> 00:02:22,190
So we're going to jump in, put
all of these different moving

41
00:02:22,190 --> 00:02:27,020
pieces together, and get our
multicast working with Anycast

42
00:02:27,020 --> 00:02:29,870
for the RP address
and advertising

43
00:02:29,870 --> 00:02:36,890
that using BSR, with MSDP being
used to essentially cluster

44
00:02:36,890 --> 00:02:39,410
the rendezvous points
so that they have

45
00:02:39,410 --> 00:02:43,220
the same information
as far as which sources

46
00:02:43,220 --> 00:02:45,750
are available for which groups.

47
00:02:45,750 --> 00:02:49,830
So as usual, let's start
with looking at our topology

48
00:02:49,830 --> 00:02:52,460
so we know what we're going
to be building and where,

49
00:02:52,460 --> 00:02:54,290
and then we'll jump
into the command line

50
00:02:54,290 --> 00:02:58,570
and get all of this
up and running.

51
00:02:58,570 --> 00:03:03,660
So in this skill, we're going to
be using Multicast Topology 2.

52
00:03:03,660 --> 00:03:09,540
So let's begin by talking about
what's changed in topology 2

53
00:03:09,540 --> 00:03:11,460
because if you've
been following along

54
00:03:11,460 --> 00:03:14,400
with the multicast
skills, this may

55
00:03:14,400 --> 00:03:19,050
look very similar to topology
1, and, in fact, it is.

56
00:03:19,050 --> 00:03:24,340
What's changed is all
of the iOS XR routers,

57
00:03:24,340 --> 00:03:32,100
so router 1, router 2,
router 3, and router 4

58
00:03:32,100 --> 00:03:36,850
have been replaced
with iOS XE routers.

59
00:03:36,850 --> 00:03:40,770
Now, just for the record,
this is not a change

60
00:03:40,770 --> 00:03:43,080
that I actually wanted to make.

61
00:03:43,080 --> 00:03:48,660
However, iOS XRV, which is
what we're using in these lab

62
00:03:48,660 --> 00:03:53,040
demonstrations, does not
appear to work correctly

63
00:03:53,040 --> 00:03:55,080
with a lot of the
features that we're

64
00:03:55,080 --> 00:03:57,750
going to be talking
about in this skill.

65
00:03:57,750 --> 00:04:03,130
Just as one small example,
MSDP would come up

66
00:04:03,130 --> 00:04:07,360
perfectly fine between
the iOS XR routers.

67
00:04:07,360 --> 00:04:13,240
However, it wouldn't actually
exchange any SA or Source

68
00:04:13,240 --> 00:04:14,630
Active messages.

69
00:04:14,630 --> 00:04:17,410
So even though it was
learning the information

70
00:04:17,410 --> 00:04:18,970
and one router--

71
00:04:18,970 --> 00:04:21,399
what would potentially
be the sender--

72
00:04:21,399 --> 00:04:25,150
said that it was putting
the entry into MSDP,

73
00:04:25,150 --> 00:04:27,640
it wouldn't show up
on the other side.

74
00:04:27,640 --> 00:04:31,270
I also had a lot of issues
with bidirectional PIM,

75
00:04:31,270 --> 00:04:34,520
which we'll be talking
about in an upcoming video.

76
00:04:34,520 --> 00:04:37,150
So rather than trying
to fight and get

77
00:04:37,150 --> 00:04:40,510
iOS XRV to actually
work, which it appears

78
00:04:40,510 --> 00:04:45,550
to have some both control plane
and data plane issues with some

79
00:04:45,550 --> 00:04:48,880
of these technologies,
unfortunately, we just

80
00:04:48,880 --> 00:04:53,830
ultimately had to replace these
with iOS XE routers, which

81
00:04:53,830 --> 00:04:56,840
actually function perfectly
fine in this environment.

82
00:04:56,840 --> 00:04:59,920
So that also further
proves that it

83
00:04:59,920 --> 00:05:03,220
must be some sort of an issue
with these particular versions

84
00:05:03,220 --> 00:05:05,230
of iOS XRV.

85
00:05:05,230 --> 00:05:07,700
And I did try a few
different versions,

86
00:05:07,700 --> 00:05:10,460
and I just couldn't get
it functioning properly.

87
00:05:10,460 --> 00:05:12,500
So although I didn't
really want to do it,

88
00:05:12,500 --> 00:05:15,010
this is a change we
had to make in order

89
00:05:15,010 --> 00:05:17,750
to make these demonstrations
actually function.

90
00:05:17,750 --> 00:05:19,570
So let's talk about
what we're going

91
00:05:19,570 --> 00:05:21,340
to actually do in this video.

92
00:05:21,340 --> 00:05:25,330
But keep in mind, throughout
this skill, all of our routers

93
00:05:25,330 --> 00:05:27,460
are iOS XE.

94
00:05:27,460 --> 00:05:30,040
So all of that said, what
are we actually going

95
00:05:30,040 --> 00:05:31,150
to configure here?

96
00:05:31,150 --> 00:05:34,720
Well, we're going to start
by creating new loopback

97
00:05:34,720 --> 00:05:39,640
interfaces on both
router 2 and router 4.

98
00:05:39,640 --> 00:05:44,740
We're going to give both of them
the address of the RP, which

99
00:05:44,740 --> 00:05:49,060
we're going to use AS 100.1.1.1.

100
00:05:49,060 --> 00:05:55,000
Then we're going to advertise
both of these into OSPF.

101
00:05:55,000 --> 00:05:58,660
So these are both going to
get advertised into the IGP

102
00:05:58,660 --> 00:06:01,840
so they're reachable from
all of the other devices,

103
00:06:01,840 --> 00:06:07,180
and then we're going to
advertise them into BSR so

104
00:06:07,180 --> 00:06:10,270
that router 5 will
then advertise them

105
00:06:10,270 --> 00:06:12,170
to the rest of the network.

106
00:06:12,170 --> 00:06:15,350
And, of course, once all
that is up and running,

107
00:06:15,350 --> 00:06:17,830
we're going to have
to then configure

108
00:06:17,830 --> 00:06:23,140
MSDP between these routers so
that they can exchange source

109
00:06:23,140 --> 00:06:24,610
active messages.

110
00:06:24,610 --> 00:06:30,140
Now, of course, MSDP cannot
be run between the Anycast

111
00:06:30,140 --> 00:06:36,410
loopback interfaces, so we'll
run MSDP between the normal

112
00:06:36,410 --> 00:06:40,010
standard loopback zero
interfaces that these routers

113
00:06:40,010 --> 00:06:41,670
already have configured.

114
00:06:41,670 --> 00:06:43,610
So this is what we're
going to be building.

115
00:06:43,610 --> 00:06:45,930
Let's go ahead and jump
in and get started.

116
00:06:45,930 --> 00:06:48,080
We'll just start by
creating these loopbacks,

117
00:06:48,080 --> 00:06:51,620
so we'll start on router 2.

118
00:06:51,620 --> 00:06:54,260
So we'll simply go into
configuration mode.

119
00:06:54,260 --> 00:06:57,110
We'll make this new
loopback interface.

120
00:06:57,110 --> 00:07:00,120
We'll simply make
it loopback 100.

121
00:07:00,120 --> 00:07:02,570
We'll give it its IP address.

122
00:07:02,570 --> 00:07:05,540
Again, it's going
to be 100.1.1.1.

123
00:07:05,540 --> 00:07:08,180
This is going to be a slash 32.

124
00:07:08,180 --> 00:07:12,320
We also, of course, need
to bring it into OSPF,

125
00:07:12,320 --> 00:07:16,610
so we'll simply say
ip ospf 1 area 0.

126
00:07:16,610 --> 00:07:22,820
And we need to enable PIM on
it, so ip pim sparse mode.

127
00:07:22,820 --> 00:07:25,070
We'll exit out of the
interface, but we'll

128
00:07:25,070 --> 00:07:28,530
stay in configuration mode
because we're not quite done.

129
00:07:28,530 --> 00:07:31,100
Let's do the same
thing on router 4.

130
00:07:31,100 --> 00:07:34,790
So we'll configure the exact
same thing on router 4.

131
00:07:34,790 --> 00:07:37,580
Again, it's interface
loopback 100.

132
00:07:37,580 --> 00:07:40,340
This is Anycast,
so remember, it's

133
00:07:40,340 --> 00:07:45,740
going to have the exact same
IP address, again, a slash 32.

134
00:07:45,740 --> 00:07:49,130
We need to bring it
into OSPF, so we'll

135
00:07:49,130 --> 00:07:53,130
bring it into area zero,
and it's going to need PIM.

136
00:07:53,130 --> 00:07:56,880
The next thing we need
to do is advertise this

137
00:07:56,880 --> 00:08:00,870
as a candidate RP into BSR.

138
00:08:00,870 --> 00:08:03,960
So since we're already on
router 4, we'll just start here.

139
00:08:03,960 --> 00:08:08,490
It's ip pim
rp-candidate, and we're

140
00:08:08,490 --> 00:08:10,530
going to be advertising
the loopback 100

141
00:08:10,530 --> 00:08:12,640
interface that we just created.

142
00:08:12,640 --> 00:08:15,090
We'll go ahead and
exit configuration,

143
00:08:15,090 --> 00:08:17,970
and we'll go do the
same thing on router 2.

144
00:08:17,970 --> 00:08:22,810

145
00:08:22,810 --> 00:08:27,170
Now that that's done, let's make
sure that all of our routers

146
00:08:27,170 --> 00:08:30,760
now know which device is the RP.

147
00:08:30,760 --> 00:08:33,580
So we'll simply use
our chat window here,

148
00:08:33,580 --> 00:08:37,659
and looking at all of the
routers, here on router 2,

149
00:08:37,659 --> 00:08:42,789
we can see that we know
the RP is 100.1.1.1.

150
00:08:42,789 --> 00:08:47,410
If we look back at router 1,
it has the information as well.

151
00:08:47,410 --> 00:08:51,730
Router 3 has been updated,
4 has been updated,

152
00:08:51,730 --> 00:08:56,686
5 has been updated, 6, and 7.

153
00:08:56,686 --> 00:08:59,800
8, 9, and 10 are
not running PIM,

154
00:08:59,800 --> 00:09:02,500
so we don't need to check there.

155
00:09:02,500 --> 00:09:08,500
But now that everybody knows the
RP, we do still have a problem.

156
00:09:08,500 --> 00:09:12,530
Here on router 7, if we were
to trace to that address,

157
00:09:12,530 --> 00:09:18,700
notice the path is going from
7 to router 3 to router 4.

158
00:09:18,700 --> 00:09:24,020
So ultimately, router 7
is going to the router 4

159
00:09:24,020 --> 00:09:28,100
instance of the 100.1.1.1.

160
00:09:28,100 --> 00:09:37,480
If we look at router 6, however,
router 6 is going to router 1

161
00:09:37,480 --> 00:09:39,550
and then to router 2.

162
00:09:39,550 --> 00:09:42,920
So basically, what we
have going on here,

163
00:09:42,920 --> 00:09:45,250
we have the first
hop router, which

164
00:09:45,250 --> 00:09:47,800
is the one responsible
for registering

165
00:09:47,800 --> 00:09:53,260
the source with the RP,
is going to router 2.

166
00:09:53,260 --> 00:09:57,520
So it's going to register
its source with router 2.

167
00:09:57,520 --> 00:10:01,280
On the other hand,
the last hop router,

168
00:10:01,280 --> 00:10:03,760
which is router
7, which is what's

169
00:10:03,760 --> 00:10:06,700
in charge of building
the star comma G tree

170
00:10:06,700 --> 00:10:09,310
or the shared tree
to the rendezvous

171
00:10:09,310 --> 00:10:13,960
point, well, that one's
going directly to router 4.

172
00:10:13,960 --> 00:10:17,440
So you can see here where
we have a problem where

173
00:10:17,440 --> 00:10:20,860
the source is going to get
registered with router 2,

174
00:10:20,860 --> 00:10:25,660
but the star comma G tree is
going to be built to router 4.

175
00:10:25,660 --> 00:10:27,950
Let's go ahead and
check that out.

176
00:10:27,950 --> 00:10:30,490
So if we come back
over here to router 2

177
00:10:30,490 --> 00:10:34,820
and we do our show ip
mroute, what we see here

178
00:10:34,820 --> 00:10:40,130
is that router 2 does, in
fact, have the S comma G tree.

179
00:10:40,130 --> 00:10:43,580
But let's take note of a
few things about this entry.

180
00:10:43,580 --> 00:10:47,670
First, it has the
flag prune set on it.

181
00:10:47,670 --> 00:10:50,990
Second, the incoming
interface of gigabit one

182
00:10:50,990 --> 00:10:55,580
is correct, so is the
RPF neighbor of router 1.

183
00:10:55,580 --> 00:10:58,430
But look at the
outgoing interface list.

184
00:10:58,430 --> 00:11:02,750
It's null because as far
as router 2 is concerned,

185
00:11:02,750 --> 00:11:06,600
no devices have
requested this group.

186
00:11:06,600 --> 00:11:09,830
However, if we go
look at router 4,

187
00:11:09,830 --> 00:11:15,020
our show ip mroute here
shows the star comma G entry,

188
00:11:15,020 --> 00:11:17,750
but there's no S comma G entry.

189
00:11:17,750 --> 00:11:22,490
Now, the incoming interface
is correct since it is an RP,

190
00:11:22,490 --> 00:11:25,220
and that's the root
of the star comma G.

191
00:11:25,220 --> 00:11:27,800
That incoming interface
should be null,

192
00:11:27,800 --> 00:11:31,070
and the outgoing interface
list is also correct--

193
00:11:31,070 --> 00:11:32,090
gigabit 1.

194
00:11:32,090 --> 00:11:33,740
That's what it should be.

195
00:11:33,740 --> 00:11:37,640
But what we're missing
here is router 4,

196
00:11:37,640 --> 00:11:41,570
who actually does have a
potential client all the way

197
00:11:41,570 --> 00:11:42,470
over at router 8.

198
00:11:42,470 --> 00:11:46,760
But nonetheless, the star
comma G tree is built.

199
00:11:46,760 --> 00:11:49,940
It doesn't know where
to go for the source,

200
00:11:49,940 --> 00:11:53,840
and this is exactly
why we need MSDP.

201
00:11:53,840 --> 00:11:56,990
So now let's build
our MSDP neighborship

202
00:11:56,990 --> 00:11:59,360
between router 2 and 4.

203
00:11:59,360 --> 00:12:03,080
Since we're on router 4, let's
just go ahead and start here.

204
00:12:03,080 --> 00:12:06,050
MSDP can get
complicated, but just

205
00:12:06,050 --> 00:12:08,360
for the sake of
doing Anycast, this

206
00:12:08,360 --> 00:12:10,730
is going to be a very
simple configuration.

207
00:12:10,730 --> 00:12:16,010
We simply have to say
ip msdp and then list

208
00:12:16,010 --> 00:12:17,900
the peer router's address--

209
00:12:17,900 --> 00:12:20,930
in this case,
router 2's loopback.

210
00:12:20,930 --> 00:12:24,740
Then we tell it to connect
from our local source

211
00:12:24,740 --> 00:12:27,650
interface of loopback 0.

212
00:12:27,650 --> 00:12:30,230
That's actually all
we have to configure.

213
00:12:30,230 --> 00:12:34,490
We'll do a mirror
configuration on router 2.

214
00:12:34,490 --> 00:12:38,030
So again, we simply go
into configuration mode.

215
00:12:38,030 --> 00:12:41,320
Ip msdp peer, this is
going to be 10.4.4.4,

216
00:12:41,320 --> 00:12:46,700
and the connect source
here is also loopback 0.

217
00:12:46,700 --> 00:12:49,700
Remember, we can't
build this neighborship

218
00:12:49,700 --> 00:12:53,960
between the loopback
100 Anycast interfaces

219
00:12:53,960 --> 00:12:55,550
because each router
would think it

220
00:12:55,550 --> 00:12:57,410
was trying to
neighbor with itself

221
00:12:57,410 --> 00:12:59,910
because they both have
that same address.

222
00:12:59,910 --> 00:13:03,420
So this definitely has to be
between different interfaces,

223
00:13:03,420 --> 00:13:06,050
not the Anycast address itself.

224
00:13:06,050 --> 00:13:07,800
That would not work.

225
00:13:07,800 --> 00:13:09,740
So let's go ahead and hit Enter.

226
00:13:09,740 --> 00:13:12,980
We'll exit
configuration, and we see

227
00:13:12,980 --> 00:13:16,520
here the MSDP peer
is already going up

228
00:13:16,520 --> 00:13:19,280
between routers 2 and 4.

229
00:13:19,280 --> 00:13:21,800
So now let's do
some verification.

230
00:13:21,800 --> 00:13:26,120
It's actually going to be best
to verify this on router 4

231
00:13:26,120 --> 00:13:29,360
since it's the one in this
environment that should

232
00:13:29,360 --> 00:13:31,680
be receiving some information.

233
00:13:31,680 --> 00:13:35,240
So let's go over to router
4 and do some verification.

234
00:13:35,240 --> 00:13:38,820
We can start with a
show ip msdp summary.

235
00:13:38,820 --> 00:13:43,670
We can see that it's saying our
peer, 10.2.2.2, is currently

236
00:13:43,670 --> 00:13:44,210
up.

237
00:13:44,210 --> 00:13:46,940
And notice, it's
actually telling us

238
00:13:46,940 --> 00:13:50,420
that it has an SA count
or a source active message

239
00:13:50,420 --> 00:13:52,990
count of 1.

240
00:13:52,990 --> 00:13:55,120
We can get a little
bit more information

241
00:13:55,120 --> 00:13:58,390
if we say show ip msdp peer.

242
00:13:58,390 --> 00:14:00,400
This will give us a
lot more information

243
00:14:00,400 --> 00:14:03,040
about that neighbor,
particularly

244
00:14:03,040 --> 00:14:05,380
what interfaces we're
connecting with,

245
00:14:05,380 --> 00:14:08,260
how many messages have
been sent and received,

246
00:14:08,260 --> 00:14:13,000
if we're doing any form of SA
filtering because we may not

247
00:14:13,000 --> 00:14:15,700
want all of the
S comma G entries

248
00:14:15,700 --> 00:14:18,130
to be exchanged
between these devices.

249
00:14:18,130 --> 00:14:20,260
In our example, we do.

250
00:14:20,260 --> 00:14:24,560
But again, in more advanced
scenarios, we may not want to.

251
00:14:24,560 --> 00:14:28,240
So like I said, this can get a
lot more complicated, but not

252
00:14:28,240 --> 00:14:30,310
for the sake of Anycast.

253
00:14:30,310 --> 00:14:33,590
Probably the most important
thing to keep an eye on though

254
00:14:33,590 --> 00:14:38,500
is the show ip msdp SA cache.

255
00:14:38,500 --> 00:14:41,680
This actually tells
us the entries

256
00:14:41,680 --> 00:14:44,030
that we've learned
from the other side.

257
00:14:44,030 --> 00:14:48,340
So as we can see here,
we've learned the S comma G

258
00:14:48,340 --> 00:14:54,080
entry available through
the RP 10.1.1.1.

259
00:14:54,080 --> 00:15:00,140
But most importantly,
through the peer, 10.2.2.2.

260
00:15:00,140 --> 00:15:04,760
So we're getting the
information through MSDP,

261
00:15:04,760 --> 00:15:07,670
but that doesn't really
do us a whole lot of good

262
00:15:07,670 --> 00:15:11,040
unless we're putting it in
the multicast routing table.

263
00:15:11,040 --> 00:15:14,180
So if we do our show
ip mroute again,

264
00:15:14,180 --> 00:15:20,720
notice that router 4 now
has an S comma G entry,

265
00:15:20,720 --> 00:15:24,320
and it has a flag of M on
it, which means that it

266
00:15:24,320 --> 00:15:27,050
was learned through MSDP.

267
00:15:27,050 --> 00:15:29,030
So this is looking good.

268
00:15:29,030 --> 00:15:36,160
If we take a look at router
2, notice that this S comma G

269
00:15:36,160 --> 00:15:39,610
entry now has a flag
of A on it, indicating

270
00:15:39,610 --> 00:15:44,070
that it is a candidate
for MSDP advertisement.

271
00:15:44,070 --> 00:15:46,910
So now this information
is being exchanged

272
00:15:46,910 --> 00:15:49,140
between our rendezvous points.

273
00:15:49,140 --> 00:15:52,220
Now that that's working,
if we jump all the way over

274
00:15:52,220 --> 00:15:56,750
to router 7, we see that
the last hop router now also

275
00:15:56,750 --> 00:16:01,430
has the S comma G entry and
it has the correct incoming

276
00:16:01,430 --> 00:16:04,310
and outgoing
interfaces to forward

277
00:16:04,310 --> 00:16:06,950
this traffic towards router 8.

278
00:16:06,950 --> 00:16:10,290
And, of course, to verify
that we're forwarding traffic,

279
00:16:10,290 --> 00:16:13,250
we'll do a show ip mroute count.

280
00:16:13,250 --> 00:16:17,960
We see that currently, it
has forwarded 207 packets

281
00:16:17,960 --> 00:16:20,270
down the source-based tree.

282
00:16:20,270 --> 00:16:26,420
We give it just a second, repeat
the command, it is now 212.

283
00:16:26,420 --> 00:16:29,810
So this indicates that we are
properly forwarding the traffic

284
00:16:29,810 --> 00:16:32,720
through our multicast
environment using

285
00:16:32,720 --> 00:16:38,890
Anycast with BSR and MSDP.

286
00:16:38,890 --> 00:16:43,930
So in this video, we saw
how to configure Anycast

287
00:16:43,930 --> 00:16:48,700
by putting loopback interfaces
on our routers with the same IP

288
00:16:48,700 --> 00:16:53,320
address, then advertising those
into our routing protocol,

289
00:16:53,320 --> 00:16:56,860
enabling PIM sparse mode
on those interfaces,

290
00:16:56,860 --> 00:17:01,390
then configuring BSR to
advertise that address

291
00:17:01,390 --> 00:17:03,190
as the rendezvous point.

292
00:17:03,190 --> 00:17:05,890
Now, of course, that
created a disconnect

293
00:17:05,890 --> 00:17:08,170
between the rendezvous
points as far

294
00:17:08,170 --> 00:17:11,510
as where the sources were
available on the network.

295
00:17:11,510 --> 00:17:15,880
So then, we set up MSDP
to exchange the source

296
00:17:15,880 --> 00:17:18,970
active messages between
the rendezvous points

297
00:17:18,970 --> 00:17:23,859
to keep the source information
synchronized in our Anycast

298
00:17:23,859 --> 00:17:24,880
environment.

299
00:17:24,880 --> 00:17:28,930
Another really cool feature
that we have available with PIM

300
00:17:28,930 --> 00:17:32,620
is bidirectional PIM,
so let's go ahead

301
00:17:32,620 --> 00:17:36,640
and talk about some more detail
on bidirectional PIM coming up

302
00:17:36,640 --> 00:17:37,450
next.

303
00:17:37,450 --> 00:17:40,940
Until then, I hope this has
been informative for you,

304
00:17:40,940 --> 00:17:44,050
and I'd like to thank
you for viewing.

305
00:17:44,050 --> 00:17:48,000