1
00:00:08,140 --> 00:00:13,360
 So in the previous videos we've seen
 how with AutoRP we have the concept

2
00:00:13,360 --> 00:00:18,340
 of candidate RPs that are announcing
 their candidacy and the mapping agent

3
00:00:18,340 --> 00:00:22,220
 which is collecting all those entries,
 electing just one for any given

4
00:00:22,220 --> 00:00:27,100
 group and then dispersing that
 via discovery messages.

5
00:00:27,100 --> 00:00:29,520
 And that's what all the other routers
 are listening to, those discovery

6
00:00:29,520 --> 00:00:33,280
 messages to see which
 RP has been elected.

7
00:00:33,280 --> 00:00:43,480
 But the downside to this process is that
 we know that by default RP candidates,

8
00:00:43,480 --> 00:00:46,300
 if you don't do anything special, if
 you don't use any access to this

9
00:00:46,300 --> 00:00:49,460
 or anything, by default they will announce
 their candidacy for the entire

10
00:00:49,460 --> 00:00:53,800
 class D range. But what if you start
 getting tricky and you start saying

11
00:00:53,800 --> 00:00:57,300
 okay well I only want you to be an
 RP for a certain range, like in my

12
00:00:57,300 --> 00:01:02,200
 lab example previously I said only
 for the 238 range, that's it.

13
00:01:02,200 --> 00:01:05,100
 No other multicast ranges
 will have an RP.

14
00:01:05,100 --> 00:01:10,580
 Well what happens then if a multicast
 stream does come in that's in one

15
00:01:10,580 --> 00:01:14,300
 of those other ranges for
 which there is no RP.

16
00:01:14,300 --> 00:01:18,620
 Well in that particular case, because
 all of your interfaces are in sparse

17
00:01:18,620 --> 00:01:22,840
 dense mode, which is what you really
 need to get this to work, those other

18
00:01:22,840 --> 00:01:26,200
 multicast streams will be flooded.

19
00:01:26,200 --> 00:01:32,140
 So you might think okay, prime use
 case of once again doing a network

20
00:01:32,140 --> 00:01:38,460
 attack, right? Just put a router into
 the network and have him listen

21
00:01:38,460 --> 00:01:42,740
 to the incoming discovery messages,
 take a look and say aha, okay so I

22
00:01:42,740 --> 00:01:46,320
 can see in this particular network,
 they've only got an RP for the 238

23
00:01:46,320 --> 00:01:49,700
 range. So here's what I'm going
 to do to mess everybody up.

24
00:01:49,700 --> 00:01:53,840
 I'm going to introduce a packet generator
 that sends out just gobs of

25
00:01:53,840 --> 00:01:58,400
 traffic going to, oh I don't know,
 how about 227 dot something.

26
00:01:58,400 --> 00:02:01,780
 Because I know that's going to
 be flooded via dense mode.

27
00:02:01,780 --> 00:02:04,300
 Every single router is going to get that,
 it's going to be flooded everywhere,

28
00:02:04,300 --> 00:02:06,260
 flood on every single segment.

29
00:02:06,260 --> 00:02:09,720
 If I do enough traffic, maybe I'll start
 congesting some links and maybe

30
00:02:09,720 --> 00:02:12,900
 some memory buffers and queues will get
 so full that I'll just start dropping

31
00:02:12,900 --> 00:02:16,120
 traffic and he he he I can really
 do some nasty work here.

32
00:02:16,120 --> 00:02:19,700
 So we want to prevent that kind
 of thing from happening, right?

33
00:02:19,700 --> 00:02:24,780
 This is where we would use something called
 an RP of last resort to prevent

34
00:02:24,780 --> 00:02:28,360
 that evil malicious person
 from doing that.

35
00:02:28,360 --> 00:02:35,160
 So talked about this is
 the potential problem.

36
00:02:35,160 --> 00:02:38,380
 So an RP of last resort
 is called a sync RP.

37
00:02:38,380 --> 00:02:45,880
 It's basically an RP that says, okay,
 we're going to we're going to I

38
00:02:45,880 --> 00:02:48,580
 have this valid R I've got
 these RPs over here.

39
00:02:48,580 --> 00:02:50,060
 This guy's doing 238.

40
00:02:50,060 --> 00:02:52,060
 This guy's doing 239.

41
00:02:52,060 --> 00:02:53,700
 What about everything else?

42
00:02:53,700 --> 00:02:59,260
 Well, while we have this third RP, we'll
 call him the sync RP and he will

43
00:02:59,260 --> 00:03:03,020
 be used for any other multicast stream
 that comes in, he'll have to register

44
00:03:03,020 --> 00:03:07,720
 with him. And presumably, there's
 no listeners for that.

45
00:03:07,720 --> 00:03:11,880
 Nobody is you know, that's you know,
 if 226 comes in, well, hey, in our

46
00:03:11,880 --> 00:03:15,260
 network and our company,
 we don't use 236.

47
00:03:15,260 --> 00:03:17,980
 All of our multicasts
 are 238 or 239.

48
00:03:17,980 --> 00:03:19,860
 That's why we got those
 RPs out there.

49
00:03:19,860 --> 00:03:24,940
 So if something comes in going to 225
 or 226 or 227, there's not going

50
00:03:24,940 --> 00:03:26,520
 to be receivers for that.

51
00:03:26,520 --> 00:03:31,040
 So why don't we just send register packets
 to an RP and they'll just be

52
00:03:31,040 --> 00:03:33,020
 dropped right there.

53
00:03:33,020 --> 00:03:34,000
 They'll go nowhere.

54
00:03:34,000 --> 00:03:35,740
 They won't be flooded.

55
00:03:35,740 --> 00:03:38,160
 Or you might think,
 well, wait a second.

56
00:03:38,160 --> 00:03:40,220
 That's going to be bad
 for that router, right?

57
00:03:40,220 --> 00:03:43,820
 Because if an attack actually starts
 happening and gobs of traffic, gobs

58
00:03:43,820 --> 00:03:48,340
 of register messages start going to
 him for like hundreds or thousands

59
00:03:48,340 --> 00:03:51,600
 of multicast groups, isn't
 that going to kill him?

60
00:03:51,600 --> 00:03:54,080
 And then so what are we
 going to do about that?

61
00:03:54,080 --> 00:03:55,280
 Well, guess what?

62
00:03:55,280 --> 00:03:56,840
 Look at that last bullet point.

63
00:03:56,840 --> 00:03:59,160
 It could be a black hole.

64
00:03:59,160 --> 00:04:03,140
 In other words, you could go on to
 these routers and say, OK, your RP

65
00:04:03,140 --> 00:04:09,180
 is 9.9.9.9 for everything that you
 don't learn about via auto RP.

66
00:04:09,180 --> 00:04:14,060
 But in reality, 9.9
.9.9 doesn't exist.

67
00:04:14,060 --> 00:04:15,920
 It doesn't exist anywhere.

68
00:04:15,920 --> 00:04:19,820
 So even if there's a route for it in
 the routing table, eventually those

69
00:04:19,820 --> 00:04:24,720
 register packets will be dumped
 onto a LAN and just deleted.

70
00:04:24,720 --> 00:04:26,220
 Or maybe you don't have
 a route for it at all.

71
00:04:26,220 --> 00:04:29,740
 And maybe you make your sync RP and
 say, OK, let's see, in my network,

72
00:04:29,740 --> 00:04:32,860
 I'm using the 90 network
 for everything.

73
00:04:32,860 --> 00:04:36,900
 My entire enterprise is various
 subnets of 90.something.

74
00:04:36,900 --> 00:04:43,240
 So I'll make my sync RP 7.7.7.7.

75
00:04:43,240 --> 00:04:45,900
 There's not even a route for it.

76
00:04:45,900 --> 00:04:49,420
 So now if any of my routers start getting
 pounded with this unauthorized

77
00:04:49,420 --> 00:04:52,580
 multicast traffic, they'll say,
 oh, I need to register this.

78
00:04:52,580 --> 00:04:55,800
 Uh-oh. Don't have a
 route to this RP.

79
00:04:55,800 --> 00:04:59,660
 I'm supposed to be registering it to,
 I guess I'll just drop the traffic.

80
00:04:59,660 --> 00:05:00,780
 And it'll just die.

81
00:05:00,780 --> 00:05:02,100
 It won't be flooded.

82
00:05:02,100 --> 00:05:05,460
 And that's the whole idea behind this,
 this idea of an RP of last resort

83
00:05:05,460 --> 00:05:10,420
 or a sync RP. So how are
 we going to create this?

84
00:05:10,420 --> 00:05:15,640
 Real simple. We just go back to configuring
 the static RP address command.

85
00:05:15,640 --> 00:05:17,960
 Now you might be thinking,
 wait a second.

86
00:05:17,960 --> 00:05:19,640
 I know how routing works.

87
00:05:19,640 --> 00:05:23,900
 Static routes always take preference
 over dynamic routes.

88
00:05:23,900 --> 00:05:27,300
 Isn't this going to completely
 undo auto RP?

89
00:05:27,300 --> 00:05:31,280
 Nope, because in this particular
 case, it's just the opposite.

90
00:05:31,280 --> 00:05:36,640
 When routers are running auto RP, any
 RP they learn via an RP discover

91
00:05:36,640 --> 00:05:47,340
 packet from the mapping agent
 takes priority over this.

92
00:05:47,340 --> 00:05:50,900
 Yes. So what we're actually doing right
 here, let me go back to this,

93
00:05:50,900 --> 00:05:57,260
 is this is saying, okay, I'm going
 to configure 1.1.1.1 as my RP.

94
00:05:57,260 --> 00:05:58,540
 Now that doesn't even exist.

95
00:05:58,540 --> 00:06:01,640
 That IP address isn't even in
 any routing tables anywhere.

96
00:06:01,640 --> 00:06:03,760
 It's just a black hole.

97
00:06:03,760 --> 00:06:05,860
 And I'm going to say, and I'm going
 to configure this on every single

98
00:06:05,860 --> 00:06:06,980
 router in my network.

99
00:06:06,980 --> 00:06:11,200
 Because I never know where that
 rogue attack might start from.

100
00:06:11,200 --> 00:06:14,840
 So every single router who's doing auto
 RP is learning about my legitimate

101
00:06:14,840 --> 00:06:23,280
 RPs, and every router has this command,
 which says, okay, this guy 1.1

102
00:06:23,280 --> 00:06:25,680
.1.1. Do not register with him.

103
00:06:25,680 --> 00:06:28,940
 Do not talk to him on these two addresses,
 because this is used for auto

104
00:06:28,940 --> 00:06:32,040
 RP. So he's excluded
 from those ranges.

105
00:06:32,040 --> 00:06:37,800
 But he's included for everything
 else, the entire class D range.

106
00:06:37,800 --> 00:06:49,340
 And so now, if, let's say here, if
 we receive in an RP discover packet

107
00:06:49,340 --> 00:06:53,200
 from the mapping agent.

108
00:06:53,200 --> 00:07:01,620
 And it says, hey, the elected
 RP is 90.0.0.1.

109
00:07:01,620 --> 00:07:04,880
 Because after all, we're using
 the 90 network in our company.

110
00:07:04,880 --> 00:07:14,660
 And he's the RP for
 224.000 slash 4.

111
00:07:14,660 --> 00:07:21,200
 What we'll say, okay, this
 conflicts with this.

112
00:07:21,200 --> 00:07:28,240
 But the RP discover takes
 priority over this.

113
00:07:28,240 --> 00:07:32,400
 Or if we just make it a little bit
 less, like let's say something like

114
00:07:32,400 --> 00:07:46,860
 this. Our RP discover says 90.001 is
 going to be the RP for 238.000 slash

115
00:07:46,860 --> 00:07:55,200
 8. Okay, so now my router knows that
 if he ever gets an IGMP membership

116
00:07:55,200 --> 00:08:00,880
 report, that he should send his star,
 join, if he gets an IGMP membership

117
00:08:00,880 --> 00:08:09,480
 report for 238.anything, he should
 send his PIM join to 90.001.

118
00:08:09,480 --> 00:08:15,360
 If he ever actually receives a real multicast
 packet going to 238.anything,

119
00:08:15,360 --> 00:08:19,120
 he should register
 that with 90.001.

120
00:08:19,120 --> 00:08:26,560
 If he gets a multicast packet going to
 anything else, like 237.225, whatever,

121
00:08:26,560 --> 00:08:33,600
 then he'll say, okay, I need to register
 that packet with 1.1.1.1.

122
00:08:33,600 --> 00:08:38,400
 And if 1.1.1.1 doesn't actually
 exist, it's not real.

123
00:08:38,400 --> 00:08:41,260
 And he doesn't even have
 a route to this.

124
00:08:41,260 --> 00:08:44,040
 He'll just drop that
 multicast packet.

125
00:08:44,040 --> 00:08:47,340
 And that prevents it from being
 flooded via dense mode.

126
00:08:47,340 --> 00:08:50,920
 Which is what we wanted
 in the first place.

127
00:08:50,920 --> 00:08:54,960
 So that's how you configure what's
 known as an RP of last resort or a

128
00:08:54,960 --> 00:09:01,060
 sync RP. Now you might say one other
 permutation or option to this.

129
00:09:01,060 --> 00:09:06,300
 You might say, well, what if I actually
 do want to statically configure

130
00:09:06,300 --> 00:09:08,700
 an RP for one group?

131
00:09:08,700 --> 00:09:11,420
 And I want to make sure that
 that always takes priority.

132
00:09:11,420 --> 00:09:18,040
 So even if I learn about an RP by that
 same group via auto RP, I don't

133
00:09:18,040 --> 00:09:20,920
 want auto RP to take precedence.

134
00:09:20,920 --> 00:09:23,920
 I want my static configuration
 to take precedence.

135
00:09:23,920 --> 00:09:25,840
 Well, you can do that.

136
00:09:25,840 --> 00:09:29,860
 And that's where you would
 use the override keyword.

137
00:09:29,860 --> 00:09:34,140
 So like in this particular case, we're saying,
 okay, I'm statically configuring

138
00:09:34,140 --> 00:09:36,800
 2222. He's a real RP.

139
00:09:36,800 --> 00:09:40,540
 He's allowed to be the RP
 for this particular group.

140
00:09:40,540 --> 00:09:45,220
 And even if I learn about this group
 from auto RP, I'm going to ignore

141
00:09:45,220 --> 00:09:48,580
 that. This overrides auto RP.
