1
00:00:08,300 --> 00:00:12,680
 Up until this point in time, all of
 the videos I've done so far and all

2
00:00:12,680 --> 00:00:16,480
 the lab demonstrations I've done have
 been utilizing a static rendezvous

3
00:00:16,480 --> 00:00:21,800
 point where every single router had a
 static RP configured, which is fine,

4
00:00:21,800 --> 00:00:27,240
 it works, it's acceptable, but main downside
 to it is what if that rendezvous

5
00:00:27,240 --> 00:00:29,380
 point crashes and goes away.

6
00:00:29,380 --> 00:00:33,660
 Now multicast will not work
 at all in my network.

7
00:00:33,660 --> 00:00:37,940
 So for this reason, if you're actually
 going to implement multicast in

8
00:00:37,940 --> 00:00:41,120
 your network, you probably want to
 implement some sort of dynamic way

9
00:00:41,120 --> 00:00:43,780
 of discovering rendezvous points.

10
00:00:43,780 --> 00:00:48,340
 And using that same dynamic way, if
 a rendezvous point fails, you can

11
00:00:48,340 --> 00:00:56,600
 now switch over to a different
 rendezvous point.

12
00:00:56,600 --> 00:00:59,040
 So autorp is one way
 that you can do that.

13
00:00:59,040 --> 00:01:01,380
 So let's start by talking
 about autorp.

14
00:01:01,380 --> 00:01:07,220
 So autorp provides a method for dynamically
 learning of rendezvous points

15
00:01:07,220 --> 00:01:10,680
 and provides for rendezvous
 point redundancy.

16
00:01:10,680 --> 00:01:12,700
 It is Cisco proprietary.

17
00:01:12,700 --> 00:01:14,160
 It's pretty old.

18
00:01:14,160 --> 00:01:19,160
 Autorp actually was developed
 when PIM version one came out.

19
00:01:19,160 --> 00:01:23,260
 So as soon as the RSC for PIM version
 one came out, Cisco developed this

20
00:01:23,260 --> 00:01:28,580
 to provide for RP redundancy
 and dynamic learning.

21
00:01:28,580 --> 00:01:32,800
 So within autorp, routers
 play one of three roles.

22
00:01:32,800 --> 00:01:36,420
 You have RP candidates, so like the name
 suggests, these are routers that

23
00:01:36,420 --> 00:01:40,400
 are advertising their capability
 of being rendezvous points.

24
00:01:40,400 --> 00:01:45,220
 You have something called a mapping
 agent, which sort of collects all

25
00:01:45,220 --> 00:01:47,060
 of those advertisements.

26
00:01:47,060 --> 00:01:50,420
 And so the mapping agent's job then to
 create a message which he disperses

27
00:01:50,420 --> 00:01:52,880
 to everybody else, which
 I call others.

28
00:01:52,880 --> 00:01:54,700
 That's just my name for it.

29
00:01:54,700 --> 00:01:57,880
 And all the routers listen to this
 message from the mapping agent.

30
00:01:57,880 --> 00:02:02,220
 And that's how they learn who
 the rendezvous point is.

31
00:02:02,220 --> 00:02:07,560
 So in Cisco developed this, they reserved
 two special multicast addresses

32
00:02:07,560 --> 00:02:22,060
 for this purpose, and they're talking
 about PIM with the exception of

33
00:02:22,060 --> 00:02:26,560
 register messages, which were unicast,
 all of your PIM multicast messages

34
00:02:26,560 --> 00:02:33,140
 like joins and prunes and hellos,
 all were in the 224.00 range.

35
00:02:33,140 --> 00:02:36,060
 And remember I said that according to the
 Internet Assigned Numbers Authority,

36
00:02:36,060 --> 00:02:39,540
 that was called the link
 local multicast scope.

37
00:02:39,540 --> 00:02:44,380
 The any multicast packet going out
 to 224.00 was only meant to stay on

38
00:02:44,380 --> 00:02:46,920
 the local link. It could
 not be routed.

39
00:02:46,920 --> 00:02:48,880
 Well, no, that's not
 the case here, right?

40
00:02:48,880 --> 00:02:52,240
 This is using 224.0.1.

41
00:02:52,240 --> 00:02:57,940
 So when auto RP routers, either candidates
 or mapping agents, could use

42
00:02:57,940 --> 00:03:01,980
 these to create their messages, it will
 actually go through routers will

43
00:03:01,980 --> 00:03:06,740
 process it, but then they will continue
 to forward the message as well.

44
00:03:06,740 --> 00:03:09,720
 And we're going to talk more
 about that in detail.

45
00:03:09,720 --> 00:03:14,600
 So let's talk just a real high level
 of RP candidates, and then we'll

46
00:03:14,600 --> 00:03:17,720
 drill down into the details
 a little bit later.

47
00:03:17,720 --> 00:03:20,180
 So RP candidates must be
 manually configured.

48
00:03:20,180 --> 00:03:24,200
 A router does not just automatically assume
 it could be a rendezvous point.

49
00:03:24,200 --> 00:03:25,520
 So there's a command.

50
00:03:25,520 --> 00:03:28,100
 You have to type in to
 get to realize that.

51
00:03:28,100 --> 00:03:31,460
 Once you type in that command, then
 it will send out special messages

52
00:03:31,460 --> 00:03:34,360
 called RP announce messages.

53
00:03:34,360 --> 00:03:42,600
 And I'll actually show you
 this in a few minutes.

54
00:03:42,600 --> 00:03:47,080
 So if you type in RP candidate, it's
 RP announced message will say, I

55
00:03:47,080 --> 00:03:48,780
 want to be the RP for everything.

56
00:03:48,780 --> 00:03:54,200
 Everything beginning with 1110, you
 know, those first four bits, which

57
00:03:54,200 --> 00:03:56,580
 is the entire class D range.

58
00:03:56,580 --> 00:04:01,520
 Now, as part of the command to get the
 router to believe he's an RP candidate,

59
00:04:01,520 --> 00:04:05,900
 you can optionally tell the router, no,
 when you send out your RP announced

60
00:04:05,900 --> 00:04:09,760
 messages, I only want you to say you're
 capable for a particular range,

61
00:04:09,760 --> 00:04:13,140
 a group range like maybe
 the 224s and 225s.

62
00:04:13,140 --> 00:04:17,540
 I'll have another RP out there announce
 his capability for the 226s through

63
00:04:17,540 --> 00:04:21,340
 the 239s. You can optionally do that,
 but by default, they don't.

64
00:04:21,340 --> 00:04:25,280
 They say, I'm going to be
 the RP for everything.

65
00:04:25,280 --> 00:04:30,340
 Now, so those RP announced
 messages go out.

66
00:04:30,340 --> 00:04:36,260
 Router is between the rendezvous point
 and the mapping agent will get

67
00:04:36,260 --> 00:04:40,380
 those messages. But they will just,
 they will just sort of forward them

68
00:04:40,380 --> 00:04:42,820
 on through. It gets a little bit
 more complicated than that.

69
00:04:42,820 --> 00:04:47,500
 But the routers in the middle, what I
 call the other routers, do not listen

70
00:04:47,500 --> 00:04:51,700
 to the RP announced messages to say,
 Oh, there's a rendezvous point out

71
00:04:51,700 --> 00:04:53,680
 there. They don't listen to that.

72
00:04:53,680 --> 00:04:55,740
 It's sort of like,
 here's an analogy.

73
00:04:55,740 --> 00:05:00,700
 Think of the world of switching of VTP,
 right, the VLAN trunking protocol.

74
00:05:00,700 --> 00:05:04,360
 Think of a VTP transparent
 switch, right?

75
00:05:04,360 --> 00:05:07,460
 A VTP message can come into
 a transparent switch.

76
00:05:07,460 --> 00:05:11,080
 He'll check a couple things, make sure
 the domain name is okay, the password's

77
00:05:11,080 --> 00:05:15,880
 okay. And if those basic things check
 out, then he'll transparently pass

78
00:05:15,880 --> 00:05:20,020
 it on through. But that VTP message
 is saying, do something.

79
00:05:20,020 --> 00:05:21,340
 Create a new VLAN.

80
00:05:21,340 --> 00:05:22,700
 Delete an old VLAN.

81
00:05:22,700 --> 00:05:24,900
 The transparent switch
 will not do that.

82
00:05:24,900 --> 00:05:26,560
 He doesn't look at
 the instructions.

83
00:05:26,560 --> 00:05:28,540
 He just passes it on through.

84
00:05:28,540 --> 00:05:30,120
 Same type of thing here.

85
00:05:30,120 --> 00:05:35,040
 Rodders that are not mapping agents, when
 they get an RP announced message,

86
00:05:35,040 --> 00:05:38,420
 they just sort of pass it on through
 to make sure that eventually it can

87
00:05:38,420 --> 00:05:40,060
 get to the mapping agent.

88
00:05:40,060 --> 00:05:44,080
 So the mapping agent is actually the
 one who's listening for these RP

89
00:05:44,080 --> 00:05:47,700
 announcements and will actually
 process it in his CPU.

90
00:05:47,700 --> 00:05:52,660
 So if more than one rendezvous point
 announces his capability for the

91
00:05:52,660 --> 00:05:58,940
 same group, it's the mapping agent's
 job to elect the best one.

92
00:05:58,940 --> 00:06:01,200
 So this is a critical point here.

93
00:06:01,200 --> 00:06:06,080
 If I'm one of these other routers that's
 not an RP, not a mapping agent,

94
00:06:06,080 --> 00:06:09,720
 I'm just sitting there, running regular
 PIM, I'm not going to learn about

95
00:06:09,720 --> 00:06:12,380
 all the potential RPs out there.

96
00:06:12,380 --> 00:06:15,840
 I'm only going to learn about the rendezvous
 points that the mapping agent

97
00:06:15,840 --> 00:06:18,680
 decided were the best ones.

98
00:06:18,680 --> 00:06:22,560
 So that's a, now the other protocol
 we're going to talk about BSR is not

99
00:06:22,560 --> 00:06:25,200
 like that. But auto RP is.

100
00:06:25,200 --> 00:06:28,420
 The mapping agent has this very critical
 role that's his job to figure

101
00:06:28,420 --> 00:06:32,120
 out who the best rendezvous
 points are.

102
00:06:32,120 --> 00:06:34,340
 And we'll talk about
 how he does that.

103
00:06:34,340 --> 00:06:39,380
 And so the mapping agent sends out another
 message called the RP-discovery

104
00:06:39,380 --> 00:06:42,860
 message. And this is the one where he
 says, okay, everybody, here's the

105
00:06:42,860 --> 00:06:46,820
 rendezvous points I've elected
 for each specific group.

106
00:06:46,820 --> 00:06:53,240
 So we talked about in some of the earlier
 videos that that a router can

107
00:06:53,240 --> 00:06:56,580
 only know about one RP
 for any given group.

108
00:06:56,580 --> 00:07:01,260
 In other words, it would confuse a router
 for router, said, okay, I just

109
00:07:01,260 --> 00:07:07,980
 received a join for 225.777 and there's
 two RPs out there who are capable

110
00:07:07,980 --> 00:07:09,600
 of servicing that group.

111
00:07:09,600 --> 00:07:12,440
 Which one do I send my
 star comma G join to?

112
00:07:12,440 --> 00:07:14,100
 To both of them, to one of them?

113
00:07:14,100 --> 00:07:15,460
 So that's why in PIM it says no.

114
00:07:15,460 --> 00:07:19,820
 A router can only know of one
 RP for any given group.

115
00:07:19,820 --> 00:07:22,840
 So this is how that's accomplished
 in auto RP.

116
00:07:22,840 --> 00:07:25,180
 The mapping agent says, okay,
 I'll do that job for you.

117
00:07:25,180 --> 00:07:29,540
 I'll elect the best ones and then send
 you a list of the best ones within

118
00:07:29,540 --> 00:07:32,500
 this RP-discovery message.

119
00:07:32,500 --> 00:07:38,720
 Now if you want to, like this says,
 you could configure one router to

120
00:07:38,720 --> 00:07:42,480
 be both the RP candidate and the mapping
 agent, nothing wrong with that.

121
00:07:42,480 --> 00:07:46,400
 Kind of taking away your redundancy
 and your resiliency though, right?

122
00:07:46,400 --> 00:07:49,240
 Because if that one router
 crashes, you got a problem.

123
00:07:49,240 --> 00:07:54,220
 So usually it's a better idea to separate
 them onto different devices.

124
00:07:54,220 --> 00:07:59,120
 PIM dense mode is used to propagate
 these messages, RP announced and RP

125
00:07:59,120 --> 00:08:02,320
 discovery. This is a
 critical factor here.

126
00:08:02,320 --> 00:08:13,480
 This means that when you use sparse
-dense mode, I'll show you what that

127
00:08:13,480 --> 00:08:23,520
 looks like. Just basically go to a router,
 go to one of his interfaces,

128
00:08:23,520 --> 00:08:28,120
 and you say IPPIM
 sparse-dense-mode.

129
00:08:28,120 --> 00:08:31,900
 And that's the mode you're
 going to use to do auto RP.

130
00:08:31,900 --> 00:08:40,660
 And what's going to happen here is that
 when a router receives an RP announced

131
00:08:40,660 --> 00:08:47,100
 message or an RP discover messages,
 he's going to flood that via dense

132
00:08:47,100 --> 00:08:49,720
 mode. That's what dense mode
 is going to be used for.

133
00:08:49,720 --> 00:08:54,480
 And hopefully, sparse mode will be used
 for the actual building of your

134
00:08:54,480 --> 00:08:58,760
 multicast distribution trees and the
 forwarding of your multicast data.

135
00:08:58,760 --> 00:09:02,340
 I say hopefully because sometimes
 that might not happen.

136
00:09:02,340 --> 00:09:05,380
 And I'll talk about that
 in a little bit.

137
00:09:05,380 --> 00:09:11,200
 Interfaces typically have to be in
 sparse dense mode in order to work

138
00:09:11,200 --> 00:09:17,180
 with auto RP so they can propagate
 these various RP announcements and

139
00:09:17,180 --> 00:09:21,100
 RP discover messages
 that auto RP uses.

140
00:09:21,100 --> 00:09:25,540
 And there can be situations where you
 don't want that, where you don't

141
00:09:25,540 --> 00:09:29,660
 want that to be used for the dense mode
 portion of sparse dense because

142
00:09:29,660 --> 00:09:32,100
 we know that dense mode
 is used for flooding.

143
00:09:32,100 --> 00:09:36,200
 And after all, that's why we use sparse
 mode because we don't want flooding.

144
00:09:36,200 --> 00:09:41,700
 So in a little bit, I'll talk a little
 bit more about why that could be

145
00:09:41,700 --> 00:09:43,460
 a problem in a way you
 can get around it.

146
00:09:43,460 --> 00:09:48,280
 But one way is this, you can configure
 the IPPIM auto RP listener command

147
00:09:48,280 --> 00:09:53,380
 and that should allow you just to stay
 in sparse mode and still work with