1 00:00:00,000 --> 00:00:03,472 [AUDIO LOGO] 2 00:00:03,472 --> 00:00:07,940 3 00:00:07,940 --> 00:00:11,000 Now let's take a look at our first choice 4 00:00:11,000 --> 00:00:16,940 for doing dynamic RP discovery, which is Cisco's Auto-RP. 5 00:00:16,940 --> 00:00:20,360 So given that static configuration can 6 00:00:20,360 --> 00:00:24,110 be a little tedious and that it doesn't provide for any way 7 00:00:24,110 --> 00:00:27,500 to do redundancy, Cisco came up with a way 8 00:00:27,500 --> 00:00:31,550 to dynamically discover the RP so that all we have to do 9 00:00:31,550 --> 00:00:35,390 is turn on the RP in our environment, all of the routers 10 00:00:35,390 --> 00:00:36,830 automatically learn it. 11 00:00:36,830 --> 00:00:39,470 And we can have redundancy because we 12 00:00:39,470 --> 00:00:43,460 can have multiple routers be a candidate RP. 13 00:00:43,460 --> 00:00:47,330 And then we have something called a mapping agent that 14 00:00:47,330 --> 00:00:51,140 will choose the winner and advertise that to everybody 15 00:00:51,140 --> 00:00:52,280 else in the network. 16 00:00:52,280 --> 00:00:56,870 And then everybody agrees on which device is the RP. 17 00:00:56,870 --> 00:01:03,050 Now, Cisco had to get this to work in PIM version 1. 18 00:01:03,050 --> 00:01:06,110 That's because that's what was out at the time. 19 00:01:06,110 --> 00:01:09,310 I bring this up because in our next video, 20 00:01:09,310 --> 00:01:13,470 we're going to look at another option called BSR or bootstrap 21 00:01:13,470 --> 00:01:14,220 router. 22 00:01:14,220 --> 00:01:17,110 That's the industry standard way of doing this. 23 00:01:17,110 --> 00:01:21,540 However, it only operates in PIM version 2. 24 00:01:21,540 --> 00:01:26,280 They updated the PIM standard to support automatically 25 00:01:26,280 --> 00:01:28,140 finding the RP. 26 00:01:28,140 --> 00:01:32,580 Cisco did this before this standard was updated. 27 00:01:32,580 --> 00:01:34,710 And the reason I bring all of that up 28 00:01:34,710 --> 00:01:38,460 is as we're looking at how Auto-RP works, 29 00:01:38,460 --> 00:01:42,680 its mechanism is a little odd. 30 00:01:42,680 --> 00:01:47,780 We're going to actually use multicast to disseminate 31 00:01:47,780 --> 00:01:53,280 the information that we need to do multicast routing. 32 00:01:53,280 --> 00:01:57,920 So it is a little bit of a cart before the horse problem 33 00:01:57,920 --> 00:02:01,160 in that we have to have our multicast routing working 34 00:02:01,160 --> 00:02:03,480 to send out this information. 35 00:02:03,480 --> 00:02:06,530 Now we're, of course, going to jump into the detail of how 36 00:02:06,530 --> 00:02:07,620 that works. 37 00:02:07,620 --> 00:02:11,360 But that's a fundamental problem that we have with Auto-RP. 38 00:02:11,360 --> 00:02:14,300 So let's jump in, and take a look at the detail, 39 00:02:14,300 --> 00:02:16,700 and how that actually operates. 40 00:02:16,700 --> 00:02:19,220 And we'll look at, of course, at the two moving 41 00:02:19,220 --> 00:02:21,560 parts of Auto-RP. 42 00:02:21,560 --> 00:02:23,570 So let's go ahead, and jump in, and get started. 43 00:02:23,570 --> 00:02:26,270 And then, of course, we'll configure this on the command 44 00:02:26,270 --> 00:02:28,910 line, and take a look at some of our show commands, 45 00:02:28,910 --> 00:02:33,350 and stuff to verify that this is working. 46 00:02:33,350 --> 00:02:38,120 So now we're talking about Auto-RP and its attributes. 47 00:02:38,120 --> 00:02:41,260 So first and foremost, as we mentioned 48 00:02:41,260 --> 00:02:45,490 during the introduction, this is in fact, Cisco proprietary. 49 00:02:45,490 --> 00:02:48,490 And Cisco does enable this by default 50 00:02:48,490 --> 00:02:51,370 on most of their platforms, certainly, 51 00:02:51,370 --> 00:02:53,150 the routing platforms. 52 00:02:53,150 --> 00:02:56,530 And we also mentioned that this actually uses 53 00:02:56,530 --> 00:02:59,810 multicast for communication. 54 00:02:59,810 --> 00:03:01,790 Now, it uses two different groups. 55 00:03:01,790 --> 00:03:04,040 Let's just go ahead and bring both of those up here. 56 00:03:04,040 --> 00:03:11,410 So it uses 224.0.1.39 for its announcements. 57 00:03:11,410 --> 00:03:16,930 This is for the information where the candidate RPs will 58 00:03:16,930 --> 00:03:22,270 announce their willingness to be the RP to the mapping agent. 59 00:03:22,270 --> 00:03:30,320 Then it uses 224.0.1.40 for the discovery portion, 60 00:03:30,320 --> 00:03:34,800 which is where the mapping agent sends this information out. 61 00:03:34,800 --> 00:03:39,740 Now, the reason I underlined the 1 in this discussion is we 62 00:03:39,740 --> 00:03:47,630 have to realize that 224.0.1 is not link local multicast. 63 00:03:47,630 --> 00:03:52,580 These two groups are routed multicast groups. 64 00:03:52,580 --> 00:03:54,950 And herein lies the problem. 65 00:03:54,950 --> 00:03:58,190 We have to route these groups through our network 66 00:03:58,190 --> 00:04:02,480 in order to learn the Auto-RP information, 67 00:04:02,480 --> 00:04:07,620 in other words, the RP that we need to use for sparse mode. 68 00:04:07,620 --> 00:04:11,400 So we'll talk about how that's handled here in just a moment. 69 00:04:11,400 --> 00:04:14,450 Now, the way auto handles redundancy 70 00:04:14,450 --> 00:04:20,450 is we're actually going to use a mapping agent to elect 71 00:04:20,450 --> 00:04:22,170 the rendezvous point. 72 00:04:22,170 --> 00:04:26,540 So the way this works is the candidate RPs 73 00:04:26,540 --> 00:04:28,880 advertise the groups that they're 74 00:04:28,880 --> 00:04:33,230 willing to be the RP for to the mapping agent. 75 00:04:33,230 --> 00:04:39,440 And that is what's using the 224.0.1.39. 76 00:04:39,440 --> 00:04:44,150 The mapping agent then collects all the information 77 00:04:44,150 --> 00:04:49,410 about all of the candidate RPs for each group. 78 00:04:49,410 --> 00:04:55,850 The mapping agent then chooses which RP to use for that group. 79 00:04:55,850 --> 00:04:59,600 And then that RP is then announced 80 00:04:59,600 --> 00:05:01,580 to the rest of the routers. 81 00:05:01,580 --> 00:05:07,860 That's where it's using the 224.0.1.40 address. 82 00:05:07,860 --> 00:05:11,540 Now as we mentioned, there is a slight issue 83 00:05:11,540 --> 00:05:14,740 with using these multicast groups. 84 00:05:14,740 --> 00:05:18,520 Since these groups are routed groups, 85 00:05:18,520 --> 00:05:23,230 as we said, and sparse mode is not up and running because we 86 00:05:23,230 --> 00:05:25,300 don't have a rendezvous point yet, 87 00:05:25,300 --> 00:05:28,910 these have to use dense mode. 88 00:05:28,910 --> 00:05:30,640 So yes, it's true. 89 00:05:30,640 --> 00:05:35,260 We are going to use dense mode to disseminate the information 90 00:05:35,260 --> 00:05:40,840 about who the RP is so that the routers know the RP, 91 00:05:40,840 --> 00:05:43,460 so that they can do sparse mode. 92 00:05:43,460 --> 00:05:46,100 Now, like I said during the introduction, 93 00:05:46,100 --> 00:05:49,040 this is a little bit of an odd situation. 94 00:05:49,040 --> 00:05:51,910 But it's necessary because none of this 95 00:05:51,910 --> 00:05:54,230 is built into PIM itself. 96 00:05:54,230 --> 00:05:56,380 So Cisco had to find a way to get this 97 00:05:56,380 --> 00:05:58,910 to work within the parameters. 98 00:05:58,910 --> 00:06:01,750 So how do we get these groups to operate 99 00:06:01,750 --> 00:06:04,450 in dense mode and all of the other groups 100 00:06:04,450 --> 00:06:06,710 to operate in sparse mode? 101 00:06:06,710 --> 00:06:08,670 Let's take a look. 102 00:06:08,670 --> 00:06:13,370 So we basically have two options here for IOS XE. 103 00:06:13,370 --> 00:06:16,580 Notice that this bottom choice here, this is automatically 104 00:06:16,580 --> 00:06:19,370 handled on IOS XR. 105 00:06:19,370 --> 00:06:22,550 So we don't have to do anything on IOS XR for this. 106 00:06:22,550 --> 00:06:26,420 It effectively already does the second choice here. 107 00:06:26,420 --> 00:06:30,080 But let's talk about the two choices we have on IOS XE. 108 00:06:30,080 --> 00:06:35,780 First and foremost, we can run what's called sparse-dense mode 109 00:06:35,780 --> 00:06:37,850 on every interface. 110 00:06:37,850 --> 00:06:41,210 That's going to allow these groups to operate 111 00:06:41,210 --> 00:06:43,880 in dense mode, and everything else 112 00:06:43,880 --> 00:06:46,160 will operate in sparse mode. 113 00:06:46,160 --> 00:06:48,440 The general rule with sparse dense mode 114 00:06:48,440 --> 00:06:52,430 is if we have a rendezvous point, well, 115 00:06:52,430 --> 00:06:54,200 then use sparse mode. 116 00:06:54,200 --> 00:06:57,320 If we don't, then use dense mode. 117 00:06:57,320 --> 00:07:01,520 And since we won't have an RP until these two 118 00:07:01,520 --> 00:07:04,400 groups advertise one, these groups 119 00:07:04,400 --> 00:07:07,070 will advertise in dense mode. 120 00:07:07,070 --> 00:07:10,310 Now I want to be clear, sparse dense mode 121 00:07:10,310 --> 00:07:12,800 was the initial way to do this. 122 00:07:12,800 --> 00:07:16,790 But over time, well, we'll say that a small issue 123 00:07:16,790 --> 00:07:18,080 was discovered. 124 00:07:18,080 --> 00:07:24,410 What happens if the RP goes down or Auto-RP fails? 125 00:07:24,410 --> 00:07:29,630 For whatever reason, we lose the RP information. 126 00:07:29,630 --> 00:07:32,900 Again, maybe it's not available or maybe auto 127 00:07:32,900 --> 00:07:34,950 fails, guess what? 128 00:07:34,950 --> 00:07:39,480 All of our groups would then revert to dense mode. 129 00:07:39,480 --> 00:07:43,490 And as we've mentioned in previous skills, 130 00:07:43,490 --> 00:07:46,010 there's reasons we don't just want to use 131 00:07:46,010 --> 00:07:48,110 dense mode on our network. 132 00:07:48,110 --> 00:07:51,780 There's a reason we chose to run sparse mode to begin with. 133 00:07:51,780 --> 00:07:54,350 So we don't really want the entire network 134 00:07:54,350 --> 00:07:56,510 to fall back to dense mode. 135 00:07:56,510 --> 00:08:00,630 And that's why they gave us this second option. 136 00:08:00,630 --> 00:08:05,720 The second option here is your IP PIM Auto-RP listener. 137 00:08:05,720 --> 00:08:08,950 This is configured in global configuration. 138 00:08:08,950 --> 00:08:11,400 And again, this is specifically on IOS XE 139 00:08:11,400 --> 00:08:14,710 because IOS XR automatically does this. 140 00:08:14,710 --> 00:08:21,330 But what this allows is these two groups and only 141 00:08:21,330 --> 00:08:25,140 these two groups to operate in dense mode. 142 00:08:25,140 --> 00:08:27,930 There is no falling back to dense mode 143 00:08:27,930 --> 00:08:29,760 for any other groups. 144 00:08:29,760 --> 00:08:34,440 It's limited specifically to the groups for Auto-RP, 145 00:08:34,440 --> 00:08:36,250 and that's it. 146 00:08:36,250 --> 00:08:39,870 So our best choices for running Auto-RP 147 00:08:39,870 --> 00:08:43,919 is we're probably going to want to use IP PIM Auto-RP 148 00:08:43,919 --> 00:08:46,260 listener on IOS XE. 149 00:08:46,260 --> 00:08:49,800 And, of course, we don't have to do anything on IOS XR. 150 00:08:49,800 --> 00:08:52,260 It just does this automatically. 151 00:08:52,260 --> 00:08:56,670 I have seen some newer versions of IOS XE that 152 00:08:56,670 --> 00:09:01,470 also have IP PIM Auto-RP listener already enabled. 153 00:09:01,470 --> 00:09:03,550 But just be aware of these commands. 154 00:09:03,550 --> 00:09:07,770 And these are things that we may have to actually configure. 155 00:09:07,770 --> 00:09:10,170 Also be aware here of the default 156 00:09:10,170 --> 00:09:13,680 timers, which are 60 and 180. 157 00:09:13,680 --> 00:09:17,250 So this can be a little bit slow to respond. 158 00:09:17,250 --> 00:09:19,720 We'll see as we go through our configuration. 159 00:09:19,720 --> 00:09:21,960 We will have to wait a few minutes for things 160 00:09:21,960 --> 00:09:25,740 to happen because these aren't exactly fast timers. 161 00:09:25,740 --> 00:09:28,900 And truth be told, in most environments, 162 00:09:28,900 --> 00:09:30,570 they don't need to be. 163 00:09:30,570 --> 00:09:32,850 It's not usually critical that we find out 164 00:09:32,850 --> 00:09:36,070 where the RP is right away or that it went down right away. 165 00:09:36,070 --> 00:09:39,300 So these default timers are generally OK. 166 00:09:39,300 --> 00:09:41,950 But if you need them to operate faster, of course, 167 00:09:41,950 --> 00:09:43,410 they can be adjusted. 168 00:09:43,410 --> 00:09:45,540 And as we can tell by the discussion 169 00:09:45,540 --> 00:09:51,000 we've been having, Auto-RP does provide redundancy. 170 00:09:51,000 --> 00:09:55,450 Because if one of our candidate RPs were to go down-- 171 00:09:55,450 --> 00:09:59,020 so if we were to lose one of these candidate RPs up here, 172 00:09:59,020 --> 00:10:03,960 well, the mapping agent will simply choose a different RP 173 00:10:03,960 --> 00:10:08,470 and then advertise that to the rest of the network again. 174 00:10:08,470 --> 00:10:11,310 So that's where the redundancy comes in. 175 00:10:11,310 --> 00:10:15,600 It can also provide mobility because not only could this 176 00:10:15,600 --> 00:10:18,180 be an RP went down and a new one came up, 177 00:10:18,180 --> 00:10:20,440 it could be in a different location. 178 00:10:20,440 --> 00:10:23,310 So the redundancy and mobility go together. 179 00:10:23,310 --> 00:10:28,080 But what this does not offer us is a way to do load sharing. 180 00:10:28,080 --> 00:10:33,550 The mapping agent chooses one out of the group 181 00:10:33,550 --> 00:10:36,790 and advertises it to everybody else. 182 00:10:36,790 --> 00:10:40,020 Now I will put one qualification on this. 183 00:10:40,020 --> 00:10:44,130 Just like we mentioned with static RP, 184 00:10:44,130 --> 00:10:46,260 well, remember what we said up here 185 00:10:46,260 --> 00:10:49,650 that the candidate RPs will advertise 186 00:10:49,650 --> 00:10:53,970 the groups that they're willing to be the RP for. 187 00:10:53,970 --> 00:10:59,400 So just like with static RP, I could have different Auto-RP 188 00:10:59,400 --> 00:11:01,710 routers for different groups. 189 00:11:01,710 --> 00:11:05,250 This again, would involve manual load sharing. 190 00:11:05,250 --> 00:11:07,110 But from that perspective, it can 191 00:11:07,110 --> 00:11:09,480 do that type of load sharing. 192 00:11:09,480 --> 00:11:14,850 But it has no built-in automatic mechanism for load sharing. 193 00:11:14,850 --> 00:11:17,160 I'm just trying to bring this up because we're 194 00:11:17,160 --> 00:11:20,820 going to contrast this to some other options coming up later, 195 00:11:20,820 --> 00:11:25,740 BSR for example, which does have a built-in load sharing option. 196 00:11:25,740 --> 00:11:28,050 That's why we're contrasting this. 197 00:11:28,050 --> 00:11:29,790 Can you do it manually? 198 00:11:29,790 --> 00:11:30,420 Yes. 199 00:11:30,420 --> 00:11:32,040 But that's not what we're exactly 200 00:11:32,040 --> 00:11:35,760 referring to when we say that the technology itself 201 00:11:35,760 --> 00:11:37,990 is not doing load sharing. 202 00:11:37,990 --> 00:11:41,760 So that takes care of all of the detailed discussion of Auto-RP. 203 00:11:41,760 --> 00:11:46,650 Let's jump into the command line and see how we configure this. 204 00:11:46,650 --> 00:11:49,790 So once again, we'll just be using one router for this. 205 00:11:49,790 --> 00:11:53,480 And let's start with a show ip mroute. 206 00:11:53,480 --> 00:11:56,390 And what we want to see here is notice 207 00:11:56,390 --> 00:12:00,140 that without configuring Auto-RP at all on this router, 208 00:12:00,140 --> 00:12:02,990 all we've done is enabled a few interfaces 209 00:12:02,990 --> 00:12:05,660 and turned on multicast routing. 210 00:12:05,660 --> 00:12:11,270 We're already listening to the 224.0.1.40. 211 00:12:11,270 --> 00:12:16,490 And we have a star comma G entry for it here in our table. 212 00:12:16,490 --> 00:12:21,470 Also note the D on this entry indicating that this 213 00:12:21,470 --> 00:12:23,810 is operating in dense mode. 214 00:12:23,810 --> 00:12:26,150 We don't have to worry too much about the other flags 215 00:12:26,150 --> 00:12:26,960 right now. 216 00:12:26,960 --> 00:12:29,660 Those are connected and local. 217 00:12:29,660 --> 00:12:32,270 That's, of course, because it's locally 218 00:12:32,270 --> 00:12:36,170 listening to this on the loopback 0 and the gigabit 1 219 00:12:36,170 --> 00:12:37,310 interfaces. 220 00:12:37,310 --> 00:12:42,020 But nonetheless, we're listening for this Auto-RP group 221 00:12:42,020 --> 00:12:43,230 automatically. 222 00:12:43,230 --> 00:12:47,490 However, if we do a show ip pim rp map, 223 00:12:47,490 --> 00:12:51,120 we currently do not have any RP mappings. 224 00:12:51,120 --> 00:12:54,210 So let's start by configuring this router 225 00:12:54,210 --> 00:12:56,580 to be an RP candidate. 226 00:12:56,580 --> 00:13:02,100 The way we do that is we say ip pim send-rp-announce. 227 00:13:02,100 --> 00:13:05,640 Then we have to tell it what interface we want to announce. 228 00:13:05,640 --> 00:13:09,450 And we're going to be announcing our loopback 0 interface. 229 00:13:09,450 --> 00:13:12,570 The other thing we have to specify here is the scope. 230 00:13:12,570 --> 00:13:15,480 Or you could call this the TTL. 231 00:13:15,480 --> 00:13:19,620 What TTL is it going to put on these announcements? 232 00:13:19,620 --> 00:13:24,390 This announcement message has to have a scope high enough 233 00:13:24,390 --> 00:13:26,700 to reach the mapping agent. 234 00:13:26,700 --> 00:13:30,060 Now, this router is also going to be our mapping agent 235 00:13:30,060 --> 00:13:31,950 because we only have this one router 236 00:13:31,950 --> 00:13:33,610 right now that we're working with. 237 00:13:33,610 --> 00:13:37,260 However, if the mapping agent was four hops away 238 00:13:37,260 --> 00:13:39,420 then you want to make this at least four. 239 00:13:39,420 --> 00:13:41,070 In a lot of environments, we'll just 240 00:13:41,070 --> 00:13:43,410 make it something like 16, which should 241 00:13:43,410 --> 00:13:44,950 cover the whole environment. 242 00:13:44,950 --> 00:13:49,530 But if you want, you can scope how far these messages will go. 243 00:13:49,530 --> 00:13:53,460 Also note that this is where we could specify that group 244 00:13:53,460 --> 00:13:56,430 list if we only want to announce our willingness 245 00:13:56,430 --> 00:14:00,360 to be the RP for certain groups just like we 246 00:14:00,360 --> 00:14:02,280 did on our static entries. 247 00:14:02,280 --> 00:14:05,730 Also this is where we can change that interval if we 248 00:14:05,730 --> 00:14:07,950 don't like the default timers. 249 00:14:07,950 --> 00:14:10,050 Now they're going to be OK for us here today. 250 00:14:10,050 --> 00:14:11,670 We'll just go ahead and hit Enter. 251 00:14:11,670 --> 00:14:16,050 But those are some options that we have on the announce line. 252 00:14:16,050 --> 00:14:21,060 If we do a show ip mroute again, notice that now we 253 00:14:21,060 --> 00:14:30,270 have a star comma G and an S, G entry for the group 224.0.1.39. 254 00:14:30,270 --> 00:14:36,090 That's us advertising ourselves as being a candidate RP. 255 00:14:36,090 --> 00:14:41,160 Remember, the 224.0.1.40 is us listening 256 00:14:41,160 --> 00:14:43,470 for somebody else, the mapping agent, 257 00:14:43,470 --> 00:14:46,300 to tell us who the RP is. 258 00:14:46,300 --> 00:14:49,350 But now that we're advertising our candidacy, 259 00:14:49,350 --> 00:14:53,880 we're now using the 224.0.1.39, which 260 00:14:53,880 --> 00:14:56,340 is what we use to talk to the mapping agent. 261 00:14:56,340 --> 00:15:00,750 Now unfortunately, if we do a show ip pim rp map, 262 00:15:00,750 --> 00:15:04,230 we're going to discover that we still don't have an RP. 263 00:15:04,230 --> 00:15:06,540 That's because as of right now, we 264 00:15:06,540 --> 00:15:10,050 don't have the second part of Auto-RP. 265 00:15:10,050 --> 00:15:12,730 We don't have a mapping agent yet. 266 00:15:12,730 --> 00:15:16,680 However, notice that it does recognize that this system 267 00:15:16,680 --> 00:15:19,470 is configured as an RP. 268 00:15:19,470 --> 00:15:21,810 It's not using itself. 269 00:15:21,810 --> 00:15:25,200 But it knows that it's advertising its candidacy 270 00:15:25,200 --> 00:15:27,840 because it has seen that announce command 271 00:15:27,840 --> 00:15:29,590 in the configuration. 272 00:15:29,590 --> 00:15:31,890 So in order for this to work, we're 273 00:15:31,890 --> 00:15:33,630 going to need a mapping agent. 274 00:15:33,630 --> 00:15:35,460 The way you configure a mapping agent 275 00:15:35,460 --> 00:15:39,430 is almost the same way as you configure the candidate. 276 00:15:39,430 --> 00:15:42,480 It's ip pim send-rp. 277 00:15:42,480 --> 00:15:45,810 But this time, it's discovery. 278 00:15:45,810 --> 00:15:48,300 Once again, we have to specify a loopback. 279 00:15:48,300 --> 00:15:51,090 Once again, we have to specify a scope. 280 00:15:51,090 --> 00:15:53,550 And the only real option we have on this one 281 00:15:53,550 --> 00:15:55,950 is simply to change the timers. 282 00:15:55,950 --> 00:15:58,200 So we'll just go ahead and hit Enter. 283 00:15:58,200 --> 00:16:00,550 We'll exit configuration. 284 00:16:00,550 --> 00:16:05,580 Now if we do a show ip pim rp map, 285 00:16:05,580 --> 00:16:08,940 notice that we still don't have the information. 286 00:16:08,940 --> 00:16:12,240 As we said, these timers are a little bit slow. 287 00:16:12,240 --> 00:16:14,430 So we'll give this just a few minutes 288 00:16:14,430 --> 00:16:17,430 to realize who the RP is. 289 00:16:17,430 --> 00:16:19,800 One indicator that it's probably working 290 00:16:19,800 --> 00:16:22,530 is our tunnel interfaces just came up 291 00:16:22,530 --> 00:16:25,930 like they did when we configured this statically. 292 00:16:25,930 --> 00:16:28,050 So it'd be a pretty good guess to say 293 00:16:28,050 --> 00:16:30,720 if we do a show ip pim rp map again, 294 00:16:30,720 --> 00:16:33,600 that now we know who the RP is. 295 00:16:33,600 --> 00:16:35,790 We see that just like with static. 296 00:16:35,790 --> 00:16:40,920 It says that for the groups 224.0.0.0/4, 297 00:16:40,920 --> 00:16:46,260 the entire multicast group, the RP is 10.1.1.1. 298 00:16:46,260 --> 00:16:48,810 It did resolve to the host name R1 299 00:16:48,810 --> 00:16:51,510 because our IP host entry is still 300 00:16:51,510 --> 00:16:54,060 in there from our previous lab. 301 00:16:54,060 --> 00:16:58,440 This is compatible with PIM version 2 and PIM version 1. 302 00:16:58,440 --> 00:17:02,790 The info source is telling us who the mapping agent is. 303 00:17:02,790 --> 00:17:07,290 It's telling us who told us about the rendezvous point. 304 00:17:07,290 --> 00:17:09,480 That's a little confusing on this output 305 00:17:09,480 --> 00:17:11,250 just because it's the same device. 306 00:17:11,250 --> 00:17:15,390 But our mapping agent is also 10.1.1.1. 307 00:17:15,390 --> 00:17:18,660 This was, of course, elected via Auto-RP. 308 00:17:18,660 --> 00:17:22,440 We can see that the current uptime is about 19 seconds. 309 00:17:22,440 --> 00:17:24,390 That's how long it took us to look 310 00:17:24,390 --> 00:17:26,880 at this from when the tunnels came up essentially. 311 00:17:26,880 --> 00:17:29,070 And we can see that it's going to expire 312 00:17:29,070 --> 00:17:31,920 in 2 minutes and 41 seconds. 313 00:17:31,920 --> 00:17:35,820 It times out after three minutes. 314 00:17:35,820 --> 00:17:38,280 Another good command to look at to verify this 315 00:17:38,280 --> 00:17:41,820 is show ip pim autorp. 316 00:17:41,820 --> 00:17:45,900 What we see here is, of course, that Auto-RP is enabled. 317 00:17:45,900 --> 00:17:50,520 RP packet discovery MTU is 1,500 bytes, probably not 318 00:17:50,520 --> 00:17:52,680 all that critical in most environments. 319 00:17:52,680 --> 00:17:58,080 But notice that the 224.0.1.40 is joined on the loopback 0 320 00:17:58,080 --> 00:17:59,010 interface. 321 00:17:59,010 --> 00:18:03,750 And it has sent, and received multiple RP announcements, 322 00:18:03,750 --> 00:18:06,400 and RP discovery messages. 323 00:18:06,400 --> 00:18:10,020 So all of this indicates that Auto-RP is up and running 324 00:18:10,020 --> 00:18:12,690 as it should on this device. 325 00:18:12,690 --> 00:18:17,310 It's acting as an RP candidate and as the Auto-RP mapping 326 00:18:17,310 --> 00:18:18,030 agent. 327 00:18:18,030 --> 00:18:20,040 And ultimately, I guess we could say 328 00:18:20,040 --> 00:18:23,550 it's acting as an Auto-RP client as well since it's 329 00:18:23,550 --> 00:18:26,300 learned its own information. 330 00:18:26,300 --> 00:18:29,440 So in this video, we saw how to configure 331 00:18:29,440 --> 00:18:34,510 Cisco's proprietary Auto-RP solution for providing 332 00:18:34,510 --> 00:18:37,930 a dynamic way of discovering the rendezvous point 333 00:18:37,930 --> 00:18:40,870 and electing the rendezvous point out 334 00:18:40,870 --> 00:18:43,060 of a group of possible candidates, 335 00:18:43,060 --> 00:18:47,000 which allows us to do some redundancy here as well. 336 00:18:47,000 --> 00:18:49,630 Now as we mentioned, this doesn't exactly 337 00:18:49,630 --> 00:18:51,280 support load sharing. 338 00:18:51,280 --> 00:18:55,150 Although we can do some manually if we restrict those group 339 00:18:55,150 --> 00:18:56,110 numbers. 340 00:18:56,110 --> 00:18:59,080 Now this works a little bit odd as we 341 00:18:59,080 --> 00:19:02,350 said because it has to use dense mode in order 342 00:19:02,350 --> 00:19:04,330 to flood the information it needs 343 00:19:04,330 --> 00:19:08,320 to learn who the Auto-RP is so that it can do sparse mode. 344 00:19:08,320 --> 00:19:11,080 But again, in its defense, that's 345 00:19:11,080 --> 00:19:15,280 because it came along before PIM version 2. 346 00:19:15,280 --> 00:19:19,540 And this can operate in PIM version 1 where it's-- 347 00:19:19,540 --> 00:19:23,360 we'll call it competitor, BSR cannot. 348 00:19:23,360 --> 00:19:27,620 Now BSR is the industry standard way of doing this. 349 00:19:27,620 --> 00:19:30,630 And it doesn't need its own special groups. 350 00:19:30,630 --> 00:19:34,710 So that's what we need to take a more detailed look at next. 351 00:19:34,710 --> 00:19:38,420 And until then, I hope this has been informative for you. 352 00:19:38,420 --> 00:19:41,470 And I'd like to thank you for viewing. 353 00:19:41,470 --> 00:19:45,000