WEBVTT 00:00.200 --> 00:01.550 Right now is. 00:01.550 --> 00:06.800 Yes, my my edges of these are different sites. 00:06.800 --> 00:07.190 Right. 00:09.370 --> 00:09.820 I'll wait. 00:17.790 --> 00:19.770 The sites are talking to each other. 00:19.770 --> 00:20.700 But that's not the point. 00:20.730 --> 00:22.140 What do I want to do? 00:24.660 --> 00:30.040 Think I want to make sure that my private IPS communicate to each other. 00:31.030 --> 00:31.950 How will they do that? 00:31.960 --> 00:37.180 How did I do it in run a routing protocol? 00:40.090 --> 00:44.860 With since the routs that are behind me, I ran a routing protocol. 00:44.980 --> 00:47.560 But there is going to be a small little issue in here. 00:48.370 --> 00:51.820 Let's check what that is if you remember from your routing switching days. 00:52.570 --> 01:04.630 Do you remember this R1, R2, R3, R4, R5. 01:05.630 --> 01:09.400 They're all connected together now through, let's say, a switch. 01:10.540 --> 01:16.120 The address is, say, 192 168 .1.0 slash 24. 01:18.540 --> 01:19.770 This network. 01:19.860 --> 01:28.020 By default, OSPF considers to be an n b a non-broadcast multiaccess network. 01:30.180 --> 01:34.080 In case of IP, this is a simple network. 01:34.530 --> 01:36.510 The problem is not going to be a problem. 01:36.510 --> 01:45.270 The problem is that between R1 and R3 and R2, the mappings that you have there, what dynamic? 01:46.200 --> 01:47.910 Every two hours they'll go down. 01:47.910 --> 01:50.730 That means your neighbor relationship will also go. 01:52.670 --> 01:53.700 Is that feasible? 01:54.870 --> 01:55.830 That's not feasible. 01:55.860 --> 01:56.820 What do I want to do? 01:56.820 --> 02:04.530 I wish to have a static, stable neighbor relationship between all the pairs. 02:04.950 --> 02:06.130 How can I do it? 02:06.150 --> 02:07.800 I'll create neighbors. 02:11.520 --> 02:16.860 All of them will have you as the neighbor because they have a static relationship with. 02:19.630 --> 02:19.780 Right? 02:19.840 --> 02:20.030 Right. 02:20.980 --> 02:22.360 They have a static relationship. 02:22.360 --> 02:22.840 With whom? 02:23.800 --> 02:27.430 So they can create neighbor relationship with R1, which will not go down. 02:30.410 --> 02:38.090 Today the every spoke has a static entry in the addressed to mapping private to public mapping which 02:38.090 --> 02:42.020 says where the R1 where R1 is and then you can send traffic to that guy. 02:42.200 --> 02:48.540 The only one issue is IP sends traffic multicast traffic will be sent out. 02:48.590 --> 02:54.380 192 168.1. let's say from R3 1.3. 02:54.410 --> 02:56.570 What is the destination of this packet going to be? 02:58.370 --> 03:02.240 It's a yellow packet is going to be on 224. 03:05.000 --> 03:05.960 That's okay. 03:06.530 --> 03:16.400 The thing is, on top of this, apply On top of this, I will also apply what sources? 03:17.720 --> 03:22.640 How will you know the destination is exactly. 03:23.600 --> 03:28.910 The problem is earlier when it was 1.1 here, you would go to the table and see 1.1. 03:28.910 --> 03:30.930 The public address is this. 03:31.350 --> 03:35.220 Now, the inside address is, what, 220 400 ten? 03:37.170 --> 03:42.480 It doesn't know what the next hop to reach that guy is from the spoke side. 03:42.510 --> 03:45.900 They don't know what the next hop is to go to 220 400 ten. 03:45.930 --> 03:47.610 I have to manually specify it. 03:50.110 --> 03:58.440 For which I will have to go to the spokes, just like the spooks right now know that the map to go to 03:58.440 --> 04:02.970 192 168 1.1 is 151 dot 16 dot one. 04:03.330 --> 04:13.380 I will also tell him listen and map if you have any multicast address, send it to the public address 04:13.380 --> 04:13.890 of. 04:16.380 --> 04:24.840 Now this will be done on all the spokes so that when it runs it knows where to send the hellos to. 04:25.290 --> 04:26.670 They will all send their hellos. 04:26.670 --> 04:27.150 To whom? 04:28.840 --> 04:31.620 So I'll copy this command and paste this on all the spokes. 04:31.890 --> 04:33.390 Let's go to spoke number three. 04:37.590 --> 04:41.900 Interface Tunnel zero spoke number four. 04:49.160 --> 04:52.940 Finally are two interface channel zero and. 04:55.830 --> 04:59.290 Right now it's VPN until 11. 05:00.150 --> 05:00.920 Then 05:06.340 --> 05:08.840 the summer because they don't have space outside. 05:08.840 --> 05:09.030 Right? 05:09.050 --> 05:09.800 So they came here. 05:12.210 --> 05:12.510 Yeah. 05:13.500 --> 05:13.800 So. 05:15.350 --> 05:16.640 You think that's going to be like that? 05:17.510 --> 05:18.020 Yeah. 05:18.590 --> 05:19.480 All multicast. 05:21.180 --> 05:21.710 Multicast. 05:22.730 --> 05:24.320 You can also write something like this. 05:24.320 --> 05:25.160 You can also say IP. 05:27.740 --> 05:28.580 Yes. 05:28.760 --> 05:30.590 The question is, can I do something like this? 05:30.620 --> 05:38.930 IP Nrhp map 220 400 ten and then specify 151 dot 16 dot one. 05:39.110 --> 05:40.100 Absolutely can. 05:41.120 --> 05:41.840 It should work. 05:41.840 --> 05:44.030 But the problem is you will only be supporting IP. 05:44.060 --> 05:45.680 What if tomorrow you want to run OSPF? 05:46.220 --> 05:48.740 Then you'll have to do 005006. 05:48.750 --> 05:49.730 What if you want to do Rip? 05:50.180 --> 05:50.600 You'll have to. 05:50.600 --> 05:54.800 So we just say multicast because we know they're not going to communicate to each other using multicast. 05:54.890 --> 05:56.030 We just tell them all multicast. 05:56.030 --> 05:57.980 Just go up there to the hub. 05:58.820 --> 06:05.270 Again, another little small little issue on the up side is how does the hub deal with it? 06:06.950 --> 06:07.430 I'm fine. 06:07.430 --> 06:09.260 Yes, I sent from these guys. 06:09.260 --> 06:10.310 I'm sending it to the hub. 06:10.340 --> 06:12.170 The hub needs to reply to all of them. 06:13.100 --> 06:14.000 Who does it send it to? 06:17.180 --> 06:19.520 Who does the hub send it to first? 06:19.550 --> 06:21.110 There is two challenges in this one. 06:21.140 --> 06:24.710 First of all, the addresses are dynamic. 06:24.740 --> 06:26.840 Tomorrow, another hub can come in with a different address. 06:26.840 --> 06:31.400 So I cannot have statically yes, all of them will be pointing to the hub, but the hub has to point 06:31.400 --> 06:32.030 towards everyone. 06:32.180 --> 06:32.840 Everybody else. 06:32.840 --> 06:34.520 Right on the hub. 06:34.520 --> 06:35.390 I'll use this command. 06:35.390 --> 06:35.870 Check this out. 06:35.870 --> 06:36.950 This is very interesting. 06:38.060 --> 06:43.040 I'll go to the hub interface, Channel zero IP and map multicast. 06:43.070 --> 06:50.780 My multicast, the hubs multicast should go to the all people, everybody who has registered to me dynamically. 06:54.620 --> 07:01.760 People who have come up and registered to me dynamically, which are who if you check your IP and all 07:01.760 --> 07:07.190 these addresses, my multicast will be sent all of them separately. 07:09.820 --> 07:15.760 Making sure that from the spokes each of them sends their multicast to the hub. 07:16.450 --> 07:23.470 The hub, in turn, does what sends to all the dynamically learned peers, which is to all of them. 07:24.040 --> 07:25.480 Now you can run your. 07:27.500 --> 07:27.990 How would you. 07:30.560 --> 07:33.170 Not individual Hello packets are not individual. 07:33.980 --> 07:35.300 Same hellos go everywhere. 07:36.950 --> 07:37.160 Hello. 07:37.160 --> 07:40.970 Packet has what information autonomous system number and k values. 07:41.660 --> 07:42.680 That's all right. 07:43.220 --> 07:47.250 Returned to a broadcast multicast address 220 400 ten. 07:47.410 --> 07:47.570 Yes. 07:48.140 --> 07:51.740 So the reply to be to the one who generated the packet, right? 07:52.150 --> 07:52.730 Not. 07:52.760 --> 07:53.960 Yeah, it would be. 07:55.250 --> 07:56.450 It goes to all four. 07:56.720 --> 08:00.080 Who are they replying to if are to generated. 08:00.740 --> 08:01.010 Yeah. 08:01.340 --> 08:11.090 His R2 packet goes where to hop in a normal situation goes in a normal situation if which normal situation. 08:11.960 --> 08:18.090 If there is a switch in the middle you have R1, R2. 08:18.260 --> 08:18.670 Yeah. 08:19.310 --> 08:21.590 I want packet, it goes to the multicast. 08:21.710 --> 08:22.100 Yeah. 08:22.490 --> 08:25.740 And the reply is also a multicast. 08:26.580 --> 08:29.110 R2 is ideally supposed to go. 08:29.610 --> 08:30.600 Not really like that. 08:31.260 --> 08:32.730 What if you have a switch in the middle? 08:33.660 --> 08:34.470 Who's talking? 08:36.270 --> 08:40.110 Question What if you have a switch in the middle and you're running? 08:43.830 --> 08:48.540 We will still send out that one hello, which will be multicast and go to both of them. 08:50.130 --> 08:53.910 It doesn't have to be a reply, right. 08:53.940 --> 08:55.350 So multicast is like a broadcast. 08:55.350 --> 08:57.930 It goes to the switch, it broadcasts out to everybody else. 08:58.890 --> 08:59.910 It's the same way here. 08:59.910 --> 09:01.770 Now here is a little better than that. 09:01.770 --> 09:02.130 Why? 09:02.160 --> 09:05.700 Because the hub will send it to all the dynamic peers. 09:07.380 --> 09:09.630 The dynamic peers will individually reply. 09:09.630 --> 09:10.110 To whom? 09:11.960 --> 09:14.150 To them individually. 09:14.150 --> 09:19.770 Reply back to the hub point to point network goes to to the not to the other. 09:19.970 --> 09:24.230 Not to the other updates go direct updates. 09:24.230 --> 09:27.640 They reply acknowledgement to the what updates is sending. 09:27.650 --> 09:29.450 The acknowledgement is are unicast. 09:31.130 --> 09:37.100 So how would that work Unicast They know already what the mappings are to the hub and he knows what 09:37.100 --> 09:38.600 the mappings are to all the spokes. 09:38.600 --> 09:44.120 That is exactly why I only create the neighbor relationship between the hub and the spokes not spoke 09:44.120 --> 09:44.540 to spoke. 09:47.290 --> 09:50.290 Because the mappings between the hubs and the spokes are resolved. 09:50.530 --> 09:55.840 I will create the neighbors from up to the spokes from one half to all the spokes. 09:56.950 --> 09:57.490 Correct. 09:59.080 --> 10:01.630 Let's run the network. 10:01.630 --> 10:03.970 192168.1.0. 10:04.300 --> 10:05.500 No Auto Summary. 10:07.410 --> 10:07.890 Network. 10:07.920 --> 10:09.210 Ten 000. 10:10.970 --> 10:11.260 Right. 10:11.270 --> 10:11.930 Copy this. 10:11.930 --> 10:12.590 Everywhere. 10:19.130 --> 10:19.960 Same network, right? 10:19.970 --> 10:22.870 Everybody has the same network on 92 168.1.. 10:24.820 --> 10:32.530 Network, ten 000, no auto, copy it and paste it on all the guys. 10:33.130 --> 10:34.000 Let's go to R2. 10:43.150 --> 10:46.180 Then neighbor up. 10:47.080 --> 10:47.470 We'll see. 10:47.470 --> 10:49.870 The neighbor is only up from one side, not the others 10:52.660 --> 10:53.250 neighbors. 10:54.760 --> 11:00.550 That's because when you paste, when you are running it, the he sends it from the other one side. 11:00.550 --> 11:01.780 The other guy receives the hello. 11:01.780 --> 11:02.680 He's not sending his own. 11:02.680 --> 11:03.100 Hello. 11:03.130 --> 11:04.240 There is a conflict. 11:04.750 --> 11:06.940 It happens every time you configure it. 11:06.940 --> 11:07.720 It will happen. 11:07.900 --> 11:10.930 The way for it to work is you shut down the tunnel. 11:12.650 --> 11:13.340 From where? 11:13.790 --> 11:14.540 From the hub. 11:15.410 --> 11:17.090 Then on all the spokes. 11:29.100 --> 11:29.400 Correct. 11:30.150 --> 11:31.740 Bring it back from the Hub. 11:32.550 --> 11:33.960 Starting from the hub. 11:33.990 --> 11:34.950 Bring back the tunnel. 11:35.670 --> 11:41.100 So now when someone will register, it will know that he is supposed to send the multicast to him. 11:41.700 --> 11:44.070 It doesn't work before because they have already registered. 11:44.970 --> 11:46.950 So they are already registered. 11:46.950 --> 11:48.030 I don't want them to now. 11:48.030 --> 11:51.360 I want them to register because now I know where to send my dynamic entries to. 11:52.440 --> 11:52.800 Right. 11:52.800 --> 11:53.580 So I'll go here. 11:53.580 --> 11:57.420 I'll say no and I'll wait for them to come here and register. 11:57.960 --> 11:58.590 No, shut. 12:06.070 --> 12:09.340 River relationships will come up on all of them. 12:14.710 --> 12:15.390 Zap. 12:15.780 --> 12:16.680 Zap enables. 12:20.370 --> 12:21.830 So happy neighbor. 12:28.900 --> 12:30.190 Our is not yet. 12:31.750 --> 12:35.320 R4 is R5. 12:35.770 --> 12:36.640 Yes. 12:39.370 --> 12:41.860 Except for R2 because it came up too quickly. 12:43.480 --> 12:43.920 Shut it. 12:43.930 --> 12:44.650 And no, Shut again. 12:45.460 --> 12:46.030 Wait for it. 12:47.440 --> 12:49.240 The registered register itself again. 12:56.700 --> 12:58.690 I have a conflict. 12:58.690 --> 13:00.580 I have two statements saying the same thing. 13:01.870 --> 13:03.700 You could either that one or this one. 13:17.290 --> 13:19.480 Okay, one neighbor is up. 13:19.480 --> 13:25.330 So if you see our one right now, show IP route ten, one, ten, two, ten, three, ten, four, ten, 13:25.330 --> 13:25.630 five. 13:30.780 --> 13:31.740 We'll do this until now. 13:33.000 --> 13:34.890 There is still a small little problem. 13:35.040 --> 13:35.950 Let's do that too. 13:35.970 --> 13:36.570 I have to. 13:36.600 --> 13:37.350 Couple of minutes. 13:37.740 --> 13:42.720 If you check R2 right now and you check your route, you only receive 10.1. 13:45.340 --> 13:46.770 You don't deceive the others. 13:46.780 --> 13:47.530 Why? 13:50.620 --> 13:51.640 The neighbors with are one. 13:54.820 --> 13:55.600 Why is that? 13:56.830 --> 13:58.540 This is from your Ccnp days. 13:58.870 --> 14:00.070 You guys should know this. 14:01.850 --> 14:05.310 Yes, yes, yes, that's it. 14:05.320 --> 14:06.070 Just don't say it. 14:06.070 --> 14:07.090 I want others to see it. 14:08.080 --> 14:08.980 I know you got it. 14:10.690 --> 14:11.770 I have a neighbor with this. 14:11.770 --> 14:12.610 I'm a neighbor with this. 14:12.610 --> 14:13.750 I'm a neighbor with this. 14:14.920 --> 14:17.950 Whatever information I give him, he's supposed to forward to R3. 14:18.370 --> 14:22.180 Whatever information R4 gives him is supposed to forward to R3 and vice versa. 14:24.350 --> 14:30.710 The problem with this part is what they're getting all this information not from different interfaces, 14:30.710 --> 14:32.480 but from the same interface. 14:34.880 --> 14:37.710 They are receiving all the information from the same interface. 14:37.830 --> 14:39.540 What does Split Horizon say? 14:39.570 --> 14:44.670 It says if you receive an update from the same interface, you are not supposed to forward it out back 14:44.670 --> 14:45.900 from the same interface. 14:46.830 --> 14:55.890 So when R1 is receiving the update from R2, he is not forwarding it to R3, but ten .1.1.0 is behind 14:55.890 --> 15:01.650 R1 and it is not receiving it, so he is giving it out to R2, R3 and R4. 15:01.800 --> 15:08.010 So when you go to R2, R3, R4, you will see our 10.1, but you will not see the other updates. 15:08.820 --> 15:09.900 How do I fix it? 15:12.240 --> 15:13.920 Go to Interface Channel zero. 15:17.520 --> 15:17.700 No. 15:18.390 --> 15:19.320 Split Horizon. 15:21.120 --> 15:22.410 Wait for it to sync again. 15:24.890 --> 15:25.480 Sings again. 15:25.490 --> 15:28.340 You go to the Piers Show IP route. 15:31.920 --> 15:32.640 Everything is here. 15:32.640 --> 15:34.980 If you go ten, three, three, three with a source of ten. 15:34.980 --> 15:35.680 Two, two, two. 15:36.270 --> 15:38.610 Done spoke to spoke communication. 15:44.400 --> 15:46.320 This is dmvpn phase one. 15:47.910 --> 15:49.260 Why is it phase one? 15:51.250 --> 15:59.500 Like you know obviously with IPsec is phase one to apply IPsec just apply copy the protection and paste 15:59.500 --> 16:00.070 it everywhere. 16:00.280 --> 16:03.550 It's phase one because the next hop is always what 16:06.730 --> 16:07.750 it will be. 16:07.930 --> 16:13.870 R1 because everybody is learning the routes from R1, so the next hop will always be R1. 16:13.900 --> 16:16.090 That means the traffic will all go through where. 16:18.900 --> 16:20.220 Move back to move back traffic. 16:21.090 --> 16:24.300 It doesn't mean I can still go to 192 168 1.3. 16:24.420 --> 16:28.680 I can still go to 1.4, but I will when I go to 10.1. 16:28.680 --> 16:29.220 10.2. 16:29.220 --> 16:29.730 10.3. 16:29.730 --> 16:30.420 10.4. 16:30.420 --> 16:38.460 Since I learned those addresses from our one, my next stop will always be our one to go to those networks. 16:38.460 --> 16:41.820 So all my traffic will always flow through our one and go to R2. 16:41.820 --> 16:43.410 R3, r4 Dmvpn. 16:43.440 --> 16:44.280 Yes. 16:44.610 --> 16:45.240 Spoke two spoke. 16:45.240 --> 16:48.630 Communication is possible, but everything is going through the hub. 16:48.630 --> 16:49.380 So phase one. 16:51.610 --> 16:54.200 There is to is scope to scope, direct communication. 16:54.590 --> 16:58.160 We'll do that tomorrow and we'll have a small recap of this too. 16:58.190 --> 16:59.020 This was too quick. 16:59.030 --> 16:59.570 Yes. 17:04.050 --> 17:04.380 Yeah. 17:08.640 --> 17:09.140 No, no, no. 17:09.140 --> 17:10.040 That's just the first time. 17:10.670 --> 17:11.540 Just the first time. 17:11.900 --> 17:13.670 If another guy comes in, he registers himself. 17:13.670 --> 17:14.120 It's fine. 17:15.550 --> 17:18.910 Why do you have to shut the tunnel and bring it back up again? 17:18.940 --> 17:21.370 See, when you run for the first time. 17:21.370 --> 17:21.790 Right? 17:22.750 --> 17:23.650 Tries to do what? 17:23.680 --> 17:25.520 Send out multicast addresses. 17:25.540 --> 17:28.270 But the thing is, he already has those people registered. 17:28.960 --> 17:29.920 Could you be more specific? 17:30.870 --> 17:40.230 I to all these public IPS, R2, R3, R4, R5 are registered in the table, right in the table. 17:40.230 --> 17:45.420 So when you run that command, it's difficult for him to go back to the old table and he should have 17:45.420 --> 17:50.370 fresh entries for what is the map multicast command. 17:51.030 --> 17:56.610 Send your multicast traffic to all the dynamically run players, but to the new dynamically learned 17:56.610 --> 17:57.930 players, not the old ones. 17:59.740 --> 18:00.960 It's supposed to work. 18:02.730 --> 18:03.930 It should, but it doesn't. 18:04.650 --> 18:07.210 That's a flaw we already have. 18:07.210 --> 18:09.750 But those are old entries which are before the command. 18:10.620 --> 18:16.590 Either you use the command first and then enter and then let them register, or if you already have 18:16.590 --> 18:21.240 them registered and you're using the command later, then you'll have to make them freshly register 18:21.240 --> 18:23.700 themselves once they're registered. 18:24.480 --> 18:25.110 It should work. 18:26.400 --> 18:27.960 By theory it should, but it doesn't. 18:28.920 --> 18:29.820 There's a design flaw. 18:29.820 --> 18:30.760 Whoever has made it. 18:30.790 --> 18:33.130 He couldn't fix the two communications. 18:33.820 --> 18:37.300 So for it to work, it has to be fresh registrations. 18:37.360 --> 18:42.130 It's not a problem because now if someone else registered, if someone else registers will come. 18:42.130 --> 18:47.480 And this we have an IP we have to run.