WEBVTT 1 00:00.000 --> 00:03.840 Alright, let's go ahead and go through this topology challenge together. 2 00:03.840 --> 00:07.590 It's going to be really important that we take the time to pause this video if 3 00:07.590 --> 00:08.000 we haven't 4 00:08.000 --> 00:09.240 done this challenge yet. 5 00:09.240 --> 00:13.080 Just go through each one of these questions and make sure that you can quickly 6 00:13.080 --> 00:13.520 answer, 7 00:13.520 --> 00:16.940 you don't necessarily have to sketch it all out, but hey, you know, maybe it 8 00:16.940 --> 00:17.560 makes sense 9 00:17.560 --> 00:21.680 to grab a piece of paper and a pencil, sketch out the topology and follow along 10 00:21.680 --> 00:21.960 to make 11 00:21.960 --> 00:27.400 sure that we know all of the operational aspects of Lisp. 12 00:27.400 --> 00:31.240 So starting with number one here, they're color coded and they all have a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:27.400 --> 00:31.240 So starting with number one here, they're color coded and they all have a 13 00:31.240 --> 00:31.920 number. 14 00:31.920 --> 00:34.960 So we're looking at number one scenario over here. 15 00:34.960 --> 00:38.360 Number one says follow the green arrow, which represents a traffic flow between 16 00:38.360 --> 00:39.680 R1 and R3 17 00:39.680 --> 00:42.640 and identify the ETR and the ITR. 18 00:42.640 --> 00:47.510 Well remember, all of these edge routers, router 1, router 3, router 2, they 19 00:47.510 --> 00:48.360 are connected 20 00:48.360 --> 00:54.470 to this Lisp site over here and they all have their own Lisp sites and they set 21 00:54.470 --> 00:54.880 at the 22 00:54.880 --> 00:57.380 edge of the network. 23 00:57.380 --> 01:00.800 So these are going to be known as our Lisp tunneling routers and depending on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 23 00:57.380 --> 01:00.800 So these are going to be known as our Lisp tunneling routers and depending on 24 01:00.800 --> 01:01.580 the direction 25 01:01.580 --> 01:07.020 of traffic flow, they're either an ingress tunneling router, the ITR or the E 26 01:07.020 --> 01:08.060 gress tunnel 27 01:08.060 --> 01:10.660 router, the ETR. 28 01:10.660 --> 01:16.180 So is it always going to be the R1 is the ITR and R3 is the ETR? 29 01:16.180 --> 01:20.490 Well no, because as soon as return traffic comes back through, we're going to 30 01:20.490 --> 01:21.060 find those 31 01:21.060 --> 01:22.580 roles reverse. 32 01:22.580 --> 01:27.000 And so this is a term that is relative to the traffic flow. 33 01:27.000 --> 01:32.210 It's not always going to be that R1 is an ITR or R3 is always an ETR, but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 33 01:27.000 --> 01:32.210 It's not always going to be that R1 is an ITR or R3 is always an ETR, but 34 01:32.210 --> 01:33.380 rather depending 35 01:33.380 --> 01:37.280 on the scenario and the traffic flow we're talking about, at that point we can 36 01:37.280 --> 01:37.980 lock in the 37 01:37.980 --> 01:41.940 role for that specific scenario. 38 01:41.940 --> 01:45.470 So once again we sometimes will refer to these as XTRs just because they can 39 01:45.470 --> 01:46.260 serve in either 40 01:46.260 --> 01:47.780 capacity. 41 01:47.780 --> 01:53.690 So number two, subnet A over here, so we're on number two, subnet A is being 42 01:53.690 --> 01:54.980 registered via 43 01:54.980 --> 01:56.660 the Lisp control plane. 44 01:56.660 --> 02:00.480 What is the EID and what device will serve as the R lock for this registration WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 01:56.660 --> 02:00.480 What is the EID and what device will serve as the R lock for this registration 45 02:00.480 --> 02:01.260 and what device 46 02:01.260 --> 02:04.380 performed this registration? 47 02:04.380 --> 02:07.340 So let's just kind of start from the beginning here. 48 02:07.340 --> 02:13.200 So remember, the goal of Lisp is to reduce the routing table sizes of all of 49 02:13.200 --> 02:14.460 these routers 50 02:14.460 --> 02:17.220 that are out in the underlay. 51 02:17.220 --> 02:21.440 And so we're going to instead put all of the mappings down here and give 52 02:21.440 --> 02:22.660 everybody access 53 02:22.660 --> 02:25.420 to be able to pull the information as needed. 54 02:25.420 --> 02:29.420 But in order for us to have this database of information, those EIDs and R 55 02:29.420 --> 02:30.220 locks must be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 02:29.420 --> 02:30.220 locks must be 56 02:30.220 --> 02:31.220 registered. 57 02:31.220 --> 02:33.980 So first of all, what is an EID? 58 02:33.980 --> 02:37.540 The EID is the subnet. 59 02:37.540 --> 02:39.700 That is our endpoint identifier. 60 02:39.700 --> 02:43.700 And yeah, it could be a slash 32, at that point it does represent a host. 61 02:43.700 --> 02:47.340 But either way, it is a subnet in our case and so specifically it's going to be 62 02:47.340 --> 02:48.260 subnet A 63 02:48.260 --> 02:50.020 with this scenario. 64 02:50.020 --> 02:52.540 Next is what device will serve as the R lock? 65 02:52.540 --> 02:56.530 Well, the R lock stands for the routing locator and that's ultimately going to 66 02:56.530 --> 02:57.940 be a some 67 02:57.940 --> 03:02.650 kind of reachable address, usually loop back address on the edge device that is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 02:57.940 --> 03:02.650 kind of reachable address, usually loop back address on the edge device that is 68 03:02.650 --> 03:03.380 performing 69 03:03.380 --> 03:06.440 the registration, which ties into the last question of which device is 70 03:06.440 --> 03:07.140 performing this 71 03:07.140 --> 03:08.140 registration. 72 03:08.140 --> 03:11.780 Well, router three is going to perform the registration because it's the one 73 03:11.780 --> 03:12.380 that has 74 03:12.380 --> 03:17.860 a route to this subnet because it has a route and it's local routing table. 75 03:17.860 --> 03:20.580 It's going to perform this registration. 76 03:20.580 --> 03:25.200 So ultimately, the arrow kind of comes from here and the registration is 77 03:25.200 --> 03:26.180 performed via 78 03:26.180 --> 03:30.460 R3 and R3 will insert itself as the R lock. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 78 03:26.180 --> 03:30.460 R3 and R3 will insert itself as the R lock. 79 03:30.460 --> 03:34.990 So again, it's going to be an IP address, probably it's loop back zero address 80 03:34.990 --> 03:35.420 or some 81 03:35.420 --> 03:39.340 loop back address that is used that again, we want to make sure it's reachable. 82 03:39.340 --> 03:42.970 If we use, for example, the IP address for this physical link here and this 83 03:42.970 --> 03:43.660 physical link 84 03:43.660 --> 03:47.880 goes down, well, that's no good because we actually have a path through another 85 03:47.880 --> 03:48.780 connection. 86 03:48.780 --> 03:53.090 This is why we like to use a loop back so that if this link goes down or this 87 03:53.090 --> 03:53.740 link goes 88 03:53.740 --> 03:58.000 down for that matter as long as they both don't go down, we do have a path to 89 03:58.000 --> 03:58.620 get to that 90 03:58.620 --> 04:01.460 loop back address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 03:58.620 --> 04:01.460 loop back address. 91 04:01.460 --> 04:06.260 So the device with the route performs the registration and it is the R lock. 92 04:06.260 --> 04:10.980 So again, this is our EID and R lock mapping that gets formed. 93 04:10.980 --> 04:15.200 Number three, a packet, which is the blue arrow over here, so our number three, 94 04:15.200 --> 04:15.780 this packet 95 04:15.780 --> 04:21.630 has just arrived on router two destined for subnet C. What device will send 96 04:21.630 --> 04:22.340 back the map 97 04:22.340 --> 04:23.340 response? 98 04:23.340 --> 04:27.440 So notice, by the way, if we follow the arrow, we notice that we are performing 99 04:27.440 --> 04:28.900 a map request. 100 04:28.900 --> 04:33.860 There are very specific message types in the world of Lisp and a map request is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 04:28.900 --> 04:33.860 There are very specific message types in the world of Lisp and a map request is 101 04:33.860 --> 04:34.180 one 102 04:34.180 --> 04:35.180 of those. 103 04:35.180 --> 04:40.080 The other one is going to be the map reply and the map reply is going to come 104 04:40.080 --> 04:40.900 from a certain 105 04:40.900 --> 04:41.900 device. 106 04:41.900 --> 04:47.400 Now, we pointed out earlier, we might think that the database here, our MRMS 107 04:47.400 --> 04:48.260 device, that 108 04:48.260 --> 04:52.740 this is going to send back the reply, but that's not actually how it works. 109 04:52.740 --> 05:00.610 We are asking for subnet C here and so the R MRMS is going to push that map WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 04:52.740 --> 05:00.610 We are asking for subnet C here and so the R MRMS is going to push that map 110 05:00.610 --> 05:01.780 request to 111 05:01.780 --> 05:05.660 router one, knowing that this is where subnet C lives. 112 05:05.660 --> 05:12.880 This allows router one to send back the map reply and so the answer is router 113 05:12.880 --> 05:13.660 one. 114 05:13.660 --> 05:16.220 Router one will actually send back this map reply. 115 05:16.220 --> 05:21.150 Now something to keep in mind is that this option can be configured around, so 116 05:21.150 --> 05:22.020 we could actually 117 05:22.020 --> 05:26.470 configure the MRMS to perform direct replies if we so desire and that is 118 05:26.470 --> 05:27.660 something that we 119 05:27.660 --> 05:30.260 can look at with SDA as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 119 05:27.660 --> 05:30.260 can look at with SDA as well. 120 05:30.260 --> 05:35.400 But either way, by default, Lisp is going to send that map reply from the 121 05:35.400 --> 05:36.420 destination 122 05:36.420 --> 05:40.060 device rather than from the MRMS. 123 05:40.060 --> 05:45.240 So number four, a packet with this red arrow over here, number four, if that's 124 05:45.240 --> 05:46.060 red, I think 125 05:46.060 --> 05:47.580 it's red enough. 126 05:47.580 --> 05:52.550 This packet is just arrived on router three and it's destined for subnet G. So 127 05:52.550 --> 05:53.020 a couple 128 05:53.020 --> 05:54.020 of points about this. 129 05:54.020 --> 05:58.220 So first of all, we can look around and see, I don't see subnet G anywhere. 130 05:58.220 --> 06:01.420 So that's a pretty big clue as to what's happening. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 05:58.220 --> 06:01.420 So that's a pretty big clue as to what's happening. 131 06:01.420 --> 06:04.060 But either way, what device will send back the response? 132 06:04.060 --> 06:09.180 We see it sending a map request here and what response type will it be? 133 06:09.180 --> 06:13.720 So in this case, the MRMS is going to send back a map reply, but it's 134 06:13.720 --> 06:15.940 specifically a negative 135 06:15.940 --> 06:18.420 map reply. 136 06:18.420 --> 06:23.120 The negative part says that we don't have an entry and if the entry doesn't 137 06:23.120 --> 06:23.780 exist in 138 06:23.780 --> 06:28.620 the Lisp on the Lisp database here, then it just must not exist. 139 06:28.620 --> 06:32.400 Because as soon as a new subnet shows up, let's say, subnet G showed up over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 139 06:28.620 --> 06:32.400 Because as soon as a new subnet shows up, let's say, subnet G showed up over 140 06:32.400 --> 06:33.020 here on router 141 06:33.020 --> 06:37.660 two, well, we would perform the registration and it would know about it. 142 06:37.660 --> 06:41.980 The fact that it doesn't know about it implies that the subnet exists outside 143 06:41.980 --> 06:42.820 of the Lisp 144 06:42.820 --> 06:45.380 space somewhere up here. 145 06:45.380 --> 06:51.140 So part two of this question, where will the packet be forwarded or will it be 146 06:51.140 --> 06:52.220 dropped? 147 06:52.220 --> 06:54.660 Unfortunately, it's not going to get dropped. 148 06:54.660 --> 06:57.100 We don't want to be dropping our frames. 149 06:57.100 --> 07:03.580 Instead, we want to assume, probably properly, that subnet G lives out here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 149 06:57.100 --> 07:03.580 Instead, we want to assume, probably properly, that subnet G lives out here. 150 07:03.580 --> 07:08.050 Now we don't know this for sure, but we're going to treat this as sort of our 151 07:08.050 --> 07:09.540 default route 152 07:09.540 --> 07:14.490 to say that if we don't see a subnet here in the Lisp domain, then it must 153 07:14.490 --> 07:15.340 exist outside 154 07:15.340 --> 07:17.100 of the Lisp domain. 155 07:17.100 --> 07:23.860 So I'm going to receive the negative map reply coming back here. 156 07:23.860 --> 07:30.540 And router three is therefore going to send this packet, tunnel it to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 156 07:23.860 --> 07:30.540 And router three is therefore going to send this packet, tunnel it to the 157 07:30.540 --> 07:31.900 nearest proxy 158 07:31.900 --> 07:33.420 egress tunnel router. 159 07:33.420 --> 07:36.540 So this is the PETR in this case. 160 07:36.540 --> 07:40.280 And router 10 will then check its routing table and perform the appropriate 161 07:40.280 --> 07:40.980 operation. 162 07:40.980 --> 07:43.380 Now, router 10 doesn't have a route. 163 07:43.380 --> 07:47.840 Well, it's connected to the outside world, so at that point it would be dropped 164 07:47.840 --> 07:47.940 . 165 07:47.940 --> 07:54.700 But again, let's assume here that G does exist out here in this space. 166 07:54.700 --> 08:01.070 And router 10 will therefore check its routing table and find that we have a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 166 07:54.700 --> 08:01.070 And router 10 will therefore check its routing table and find that we have a 167 08:01.070 --> 08:01.700 path in that 168 08:01.700 --> 08:02.700 direction. 169 08:02.700 --> 08:07.060 Now when the return traffic comes back, then router 10 will serve as the proxy 170 08:07.060 --> 08:07.620 ingress 171 08:07.620 --> 08:09.380 tunneling router. 172 08:09.380 --> 08:12.700 And then the return traffic will come back. 173 08:12.700 --> 08:16.130 So once again, we see that these roles flip flop depending on the direction of 174 08:16.130 --> 08:16.780 traffic. 175 08:16.780 --> 08:20.910 But let's make sure we understand the value and the really ultimately what we 176 08:20.910 --> 08:21.820 're getting 177 08:21.820 --> 08:25.940 out of this negative map reply and what we do with that information, which is 178 08:25.940 --> 08:26.380 to send 179 08:26.380 --> 08:28.620 it to the proxy ETR. 180 08:28.620 --> 08:33.660 So this in a high level is really how Lisp operates. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 180 08:28.620 --> 08:33.660 So this in a high level is really how Lisp operates. 181 08:33.660 --> 08:39.300 It's all about reducing the load of those routers in the middle, routers 5, 17, 182 08:39.300 --> 08:39.540 and really 183 08:39.540 --> 08:43.820 even the XTRs there at the edge, they don't have to have the full internet 184 08:43.820 --> 08:45.160 routing table. 185 08:45.160 --> 08:48.580 They just need to know what any local routes might be. 186 08:48.580 --> 08:52.170 And they need to know where all of the R-locks are, which are again going to be 187 08:52.170 --> 08:52.700 loopback 188 08:52.700 --> 08:54.740 addresses for all of the routers. 189 08:54.740 --> 08:58.560 But in an environment with even dozens or hundreds of routers, that only 190 08:58.560 --> 08:59.580 amounts to dozens 191 08:59.580 --> 09:04.620 or hundreds of routes rather than hundreds of thousands of routes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 191 08:59.580 --> 09:04.620 or hundreds of routes rather than hundreds of thousands of routes. 192 09:04.620 --> 09:08.660 So we see that there's a tremendous amount of value in building a Lisp space 193 09:08.660 --> 09:09.540 and tunneling 194 09:09.540 --> 09:14.390 our traffic from one end to the other while ensuring number one that processing 195 09:14.390 --> 09:15.580 is very fast, 196 09:15.580 --> 09:18.300 even on lower end routers, so that reduces our latency. 197 09:18.300 --> 09:21.220 But also we still have full reachability to the rest of the internet. 198 09:21.220 --> 09:25.080 So at anyone that's not deploying Lisp, they still get, or we can still 199 09:25.080 --> 09:26.060 communicate with 200 09:26.060 --> 09:27.060 them. 201 09:27.060 --> 09:29.300 I hope there's been informative for you and I'd like to thank you for viewing.