WEBVTT 1 00:00.000 --> 00:02.800 All right, time for another quiz. 2 00:02.800 --> 00:05.240 This time on list and vxland. 3 00:05.240 --> 00:06.440 And this time from the beginning, 4 00:06.440 --> 00:10.720 we can say that there are seven questions, not eight. 5 00:10.720 --> 00:12.680 Question number one, how does list create 6 00:12.680 --> 00:16.600 a pole-based control plane where routes aren't pushed everywhere? 7 00:16.600 --> 00:19.160 Well, one thing we have to consider with traditional routing 8 00:19.160 --> 00:25.040 and the way our networks work is that if I have a route, 9 00:25.040 --> 00:29.360 let's say down here, for subnet A, 10 00:29.360 --> 00:32.440 that I'm going to push that route into the environment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.360 --> 00:32.440 that I'm going to push that route into the environment 11 00:32.440 --> 00:34.200 and it's going to be propagated everywhere. 12 00:34.200 --> 00:37.560 This is, again, the push methodology, 13 00:37.560 --> 00:39.320 where I'm pushing this route everywhere 14 00:39.320 --> 00:43.440 so everybody has every single route in case they need it. 15 00:43.440 --> 00:46.880 And so it creates a scenario where every single route 16 00:46.880 --> 00:48.760 is known in every single routing table 17 00:48.760 --> 00:50.320 within the routing domain. 18 00:50.320 --> 00:53.320 So if we have 1,000 routes, this isn't that big of a deal 19 00:53.320 --> 00:57.520 because most Cisco devices can handle 1,000 routes just fine. 20 00:57.520 --> 00:59.840 But what if we have 100,000 routes? 21 00:59.840 --> 01:04.240 Or, like on the internet, what if we're approaching a million routes? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:59.840 --> 01:04.240 Or, like on the internet, what if we're approaching a million routes? 22 01:04.240 --> 01:05.880 This gets to be problematic. 23 01:05.880 --> 01:09.760 Routers can't process through that many routes very easily. 24 01:09.760 --> 01:11.920 It's going to require a tremendous amount of memory, 25 01:11.920 --> 01:13.680 a tremendous amount of resources, 26 01:13.680 --> 01:17.920 and we want to make our networking environments 27 01:17.920 --> 01:19.840 as efficient as possible. 28 01:19.840 --> 01:21.720 And so this is why Cisco developed LISP 29 01:21.720 --> 01:24.880 was to say, hey, the internet is becoming untenable. 30 01:24.880 --> 01:28.640 The number of routes on the internet approaching a million, 31 01:28.640 --> 01:29.880 that's not good for anybody. 32 01:29.880 --> 01:32.760 We don't want to have to deploy massive routers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:29.880 --> 01:32.760 We don't want to have to deploy massive routers 33 01:32.760 --> 01:34.440 throughout the entire internet 34 01:34.440 --> 01:37.920 so that everybody can have all 1 million routes. 35 01:37.920 --> 01:40.080 Instead, let's create a scenario 36 01:40.080 --> 01:44.480 where we learn routes on an as needed basis. 37 01:44.480 --> 01:47.720 And that is the idea of this pull-based mechanism. 38 01:47.720 --> 01:49.480 So here's how this works. 39 01:49.480 --> 01:52.840 Remember, if we've got a router here, 40 01:52.840 --> 01:57.040 we've got a packet coming in that's destined for subnet A. 41 01:57.040 --> 01:59.560 Now, if this router doesn't have a route for A, 42 01:59.560 --> 02:01.240 it doesn't know where A is, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:59.560 --> 02:01.240 it doesn't know where A is, 43 02:01.240 --> 02:05.600 well, it might be able to follow maybe an aggregated route 44 02:05.600 --> 02:06.600 or the default route, 45 02:06.600 --> 02:08.880 but if it doesn't have a default route, 46 02:08.880 --> 02:11.600 then it's just going to have to drop the packet. 47 02:11.600 --> 02:13.480 Well, not so with LISP. 48 02:13.480 --> 02:15.600 When we're creating the LISP environment, 49 02:15.600 --> 02:17.800 we have a control plane mechanism. 50 02:17.800 --> 02:19.600 And let's say we have this environment now 51 02:19.600 --> 02:21.440 with 100,000 routes. 52 02:21.440 --> 02:24.520 Well, these 100,000 routes no longer need to be known 53 02:24.520 --> 02:25.360 by everybody. 54 02:25.360 --> 02:27.600 We're not going to push them all over the place 55 02:27.600 --> 02:29.920 and make sure everybody has them just in case. 56 02:29.920 --> 02:32.240 This in-case methodology WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 56 02:29.920 --> 02:32.240 This in-case methodology 57 02:32.240 --> 02:34.400 is no longer what we're going to go with. 58 02:34.400 --> 02:37.600 Instead, we're going to share those 100,000 routes 59 02:37.600 --> 02:39.440 with the control plane. 60 02:39.440 --> 02:42.480 And now we can embrace this as needed concept 61 02:42.480 --> 02:46.240 where I go out to the control plane 62 02:46.240 --> 02:50.200 and I pull the routes that I need. 63 02:50.200 --> 02:52.840 So I find out where A lives 64 02:52.840 --> 02:57.400 and then I can send it on towards the rest of the network. 65 02:57.400 --> 03:02.600 Now, if I'm going to send this into the network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 02:57.400 --> 03:02.600 Now, if I'm going to send this into the network 66 03:02.600 --> 03:04.280 with a destination of A, 67 03:04.280 --> 03:09.640 but these devices in here don't have 100,000 routes 68 03:09.640 --> 03:12.240 and they also don't know where A lives, 69 03:12.240 --> 03:14.440 well, then how does it get to the other side? 70 03:14.440 --> 03:16.800 Well, then that's where the concept 71 03:16.800 --> 03:18.600 of a tunnel comes into play. 72 03:18.600 --> 03:21.480 And so LISP has two planes of operation. 73 03:21.480 --> 03:22.800 We have the control plane. 74 03:22.800 --> 03:26.600 We also have a data plane of operation here. 75 03:26.600 --> 03:29.600 And this tunnel mechanism is going to be established 76 03:29.600 --> 03:34.200 to the remote device that hosts A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 76 03:29.600 --> 03:34.200 to the remote device that hosts A 77 03:34.200 --> 03:36.200 or at least has a path to A. 78 03:36.200 --> 03:37.800 And so these devices in the middle, 79 03:37.800 --> 03:39.480 they're part of the underlay 80 03:39.480 --> 03:41.360 and what does the underlay have to know? 81 03:41.360 --> 03:43.000 The underlay just has to know how to get 82 03:43.000 --> 03:45.240 to the tunnel destinations. 83 03:45.240 --> 03:46.920 And so instead of 100,000 routes, 84 03:46.920 --> 03:49.920 maybe it has 100 routes or 1,000 routes, 85 03:49.920 --> 03:51.920 something very manageable. 86 03:51.920 --> 03:54.760 And so I don't have to worry about them needing 87 03:54.760 --> 03:56.240 to look at destination A. 88 03:56.240 --> 03:58.360 They look at the outer IP header. 89 03:58.360 --> 04:02.120 And because of LISP, we now have this underlay WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 03:58.360 --> 04:02.120 And because of LISP, we now have this underlay 90 04:02.120 --> 04:04.480 that manages far fewer routes 91 04:04.480 --> 04:08.360 and now we can have much smaller routers in the middle 92 04:08.360 --> 04:10.760 that are very quickly forwarding traffic, 93 04:10.760 --> 04:12.320 which is the goal of LISP. 94 04:12.320 --> 04:15.120 All right, question number two. 95 04:15.120 --> 04:19.560 So why isn't the LISP tunneling mechanism used in Cisco SDA? 96 04:19.560 --> 04:22.480 As we mentioned there, SDA, 97 04:22.480 --> 04:26.680 or as we have mentioned many times, SDA or SD access, 98 04:26.680 --> 04:30.920 this is going to use LISP for the control plane mechanism, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 04:26.680 --> 04:30.920 this is going to use LISP for the control plane mechanism, 99 04:30.920 --> 04:35.720 but LISP at the data plane, we're not going to use this. 100 04:35.720 --> 04:37.800 We love the pole methodology 101 04:37.800 --> 04:39.720 and we want to use the pole methodology 102 04:39.720 --> 04:42.520 throughout our SDA campus fabric. 103 04:42.520 --> 04:45.920 So why aren't we using the data plane of LISP? 104 04:45.920 --> 04:48.120 Well, the reason for that is because 105 04:48.120 --> 04:51.320 the tunnels are layer three baits. 106 04:51.320 --> 04:55.720 And if I'm going to communicate between two access closets, 107 04:55.720 --> 04:58.560 so access closet one and access closet two, 108 04:58.560 --> 05:01.680 if I'm going to make them layer three segmented, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 108 04:58.560 --> 05:01.680 if I'm going to make them layer three segmented, 109 05:01.680 --> 05:06.200 then I could just do that with a layer three access topology. 110 05:06.200 --> 05:09.240 I don't require SD access in order to do that. 111 05:09.240 --> 05:11.360 What I'm trying to do is make it 112 05:11.360 --> 05:13.920 so that we have layer two everywhere. 113 05:13.920 --> 05:17.080 And with an SDA fabric, I can accomplish that, 114 05:17.080 --> 05:19.920 but not with the LISP data plane. 115 05:19.920 --> 05:22.800 Instead, I'm going to need something layer two driven. 116 05:22.800 --> 05:24.360 This is layer three driven. 117 05:24.360 --> 05:27.000 I need a layer two tunneling mechanism 118 05:27.000 --> 05:30.800 in order to get from access closet one to access closet two, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 05:27.000 --> 05:30.800 in order to get from access closet one to access closet two, 119 05:30.800 --> 05:34.040 and that is going to be where I use VXLAN. 120 05:34.040 --> 05:38.200 So SD access is a combination of LISP at the control plane, 121 05:38.200 --> 05:40.360 VXLAN at the data plane, 122 05:40.360 --> 05:43.680 and let's not forget Cisco trussec at the policy plane. 123 05:43.680 --> 05:46.240 All right, next question. 124 05:46.240 --> 05:48.080 Identify each of the LISP roles 125 05:48.080 --> 05:49.800 that match to the following descriptions. 126 05:49.800 --> 05:51.280 So we've got a lot of LISP roles. 127 05:51.280 --> 05:52.680 We should absolutely have a sense 128 05:52.680 --> 05:55.080 of which type of device is doing what 129 05:55.080 --> 05:57.120 inside of the LISP framework. 130 05:57.120 --> 06:00.440 So number one here, forming the LISP tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 05:57.120 --> 06:00.440 So number one here, forming the LISP tunnels. 131 06:00.440 --> 06:02.560 Well, that would be that edge device 132 06:02.560 --> 06:05.640 going to the other edge device and forming this tunnel, 133 06:05.640 --> 06:07.280 and it's not talking about 134 06:07.280 --> 06:09.640 the different underlay devices in here. 135 06:09.640 --> 06:10.960 So when we're talking about this, 136 06:10.960 --> 06:12.280 these are known as, 137 06:12.280 --> 06:14.720 which sometimes referred to as an XTR, 138 06:14.720 --> 06:17.600 but specifically it would be an egress tunneling router 139 06:17.600 --> 06:19.760 or an ingress tunneling router. 140 06:19.760 --> 06:21.520 The reason why we say XTR here 141 06:21.520 --> 06:24.240 is because if traffic is flowing this way, 142 06:24.240 --> 06:26.520 this would be the ingress tunneling router, 143 06:26.520 --> 06:29.200 and the other side would be the egress tunneling router. 144 06:29.200 --> 06:31.320 But naturally, if the packet's going the other way, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 06:29.200 --> 06:31.320 But naturally, if the packet's going the other way, 145 06:31.320 --> 06:33.200 then we have to flip those roles, 146 06:33.200 --> 06:34.360 which isn't the most, 147 06:34.360 --> 06:38.560 it creates a little bit of inconsistency, 148 06:38.560 --> 06:40.640 sometimes not the most convenient thing, 149 06:40.640 --> 06:41.640 but at the same time, 150 06:41.640 --> 06:44.920 that's why we have a term here we can use the XTR. 151 06:44.920 --> 06:47.440 Now, next, the IP address of the host or subnet, 152 06:47.440 --> 06:51.160 this is known as an endpoint identifier or an EID. 153 06:51.160 --> 06:56.000 And keep in mind that this device over here at the far end 154 06:56.000 --> 06:57.920 is going to have a destination 155 06:57.920 --> 07:01.680 or really an identity point that we know the EID WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 155 06:57.920 --> 07:01.680 or really an identity point that we know the EID 156 07:01.680 --> 07:02.440 it belongs to. 157 07:02.440 --> 07:04.920 I've got an EID out here, for example, 158 07:04.920 --> 07:07.000 and that's going to be known as the routing locator 159 07:07.000 --> 07:08.440 or the R-lock. 160 07:08.440 --> 07:11.760 So the concept of splitting off the routing locator 161 07:11.760 --> 07:12.960 from the endpoint identifier, 162 07:12.960 --> 07:16.920 this is where this locator ID separation, 163 07:16.920 --> 07:20.080 the LIS of Lisp, that's where that comes from, 164 07:20.080 --> 07:23.600 is now I'm no longer routing towards the endpoint identifier, 165 07:23.600 --> 07:26.360 I'm really routing towards the R-lock. 166 07:26.360 --> 07:28.440 Now, what receives registration? 167 07:28.440 --> 07:29.840 I will say these two right here, 168 07:29.840 --> 07:32.400 this is going to be what trips us up the most, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 168 07:29.840 --> 07:32.400 this is going to be what trips us up the most, 169 07:32.400 --> 07:34.480 receiving registrations for new networks, 170 07:34.480 --> 07:36.960 this is known as the map server, 171 07:36.960 --> 07:40.600 whereas receiving the pull requests, essentially, 172 07:40.600 --> 07:42.200 to find out, hey, where in the world 173 07:42.200 --> 07:44.040 are these endpoint identifiers, 174 07:44.040 --> 07:46.920 this is the responsibility of the map resolver. 175 07:46.920 --> 07:49.880 In a lot of situations, especially small deployments, 176 07:49.880 --> 07:54.120 and yes, in SDXs, these two devices get combined into one, 177 07:54.120 --> 07:56.720 in fact, an SDXs, this gets combined 178 07:56.720 --> 07:59.000 into the control plane node, 179 07:59.000 --> 08:02.320 and we just have a single device doing both operations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 07:59.000 --> 08:02.320 and we just have a single device doing both operations. 180 08:02.320 --> 08:04.120 But in large Lisp deployments, 181 08:04.120 --> 08:07.160 these get deployed as individual devices. 182 08:07.160 --> 08:08.280 For the sake of scaling out, 183 08:08.280 --> 08:10.600 we might see many of these devices, 184 08:10.600 --> 08:12.880 but ultimately we should try to keep track 185 08:12.880 --> 08:16.040 of which device is responsible for which operation. 186 08:16.040 --> 08:19.120 Lastly, sharing routes with non- Lisp networks, 187 08:19.120 --> 08:21.800 that would be the responsibility of the proxy, 188 08:21.800 --> 08:26.800 ITR or ETR, and so, as with all things, 189 08:26.800 --> 08:30.440 not everybody in the world is using Lisp, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 08:26.800 --> 08:30.440 not everybody in the world is using Lisp, 190 08:30.440 --> 08:32.520 and so we've got this whole Lisp domain 191 08:32.520 --> 08:35.800 that consists of the underlay and edge devices here 192 08:35.800 --> 08:39.360 that have all kinds of networks that are hanging off of them, 193 08:39.360 --> 08:42.640 but eventually we might have to go out of the Lisp domain, 194 08:42.640 --> 08:44.840 and so that would be a device that sits here, 195 08:44.840 --> 08:49.160 known as the proxy, again, ETR, ITR, XTR, 196 08:49.160 --> 08:50.520 whatever we wanna call it. 197 08:50.520 --> 08:53.880 So the proxy XTR here is going to be responsible 198 08:53.880 --> 08:57.400 not only for advertising our Lisp routes 199 08:57.400 --> 08:58.800 into the rest of the world, 200 08:58.800 --> 09:01.440 'cause we do have to convert back to a push mindset, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 200 08:58.800 --> 09:01.440 'cause we do have to convert back to a push mindset, 201 09:01.440 --> 09:05.040 so I'm gonna have to push those routes out of the Lisp world, 202 09:05.040 --> 09:07.320 and then I have to worry about bringing traffic in 203 09:07.320 --> 09:09.160 and sending traffic out, and again, 204 09:09.160 --> 09:11.560 into and out of the Lisp domain. 205 09:11.560 --> 09:13.560 So that is how the Lisp roles come together. 206 09:13.560 --> 09:17.120 Let's make sure we have a sense of what all of these roles 207 09:17.120 --> 09:20.180 and responsibilities are and how it all comes together. 208 09:20.180 --> 09:24.220 Question number four, how many bytes of overhead are added 209 09:24.220 --> 09:27.240 when using VX land to carry layer two frames? 210 09:27.240 --> 09:28.760 Well, the best way to figure this out 211 09:28.760 --> 09:31.520 is to really again map everything out here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 211 09:28.760 --> 09:31.520 is to really again map everything out here, 212 09:31.520 --> 09:35.520 and what we find is that we have our 1,500 potentially, 213 09:35.520 --> 09:39.520 the max payload for standard frames, 1,500 bytes, 214 09:39.520 --> 09:43.240 that doesn't include the Ethernet header here. 215 09:43.240 --> 09:48.240 And so our Ethernet header is going to be an extra 14 bytes, 216 09:48.240 --> 09:53.360 and then we have to have a VX land header in here, 217 09:53.360 --> 09:55.120 and that is only eight bytes. 218 09:55.120 --> 09:58.640 Then we place this into UDP, which is another eight bytes, 219 09:58.640 --> 10:02.600 and then of course we need an outer IP header, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 219 09:58.640 --> 10:02.600 and then of course we need an outer IP header, 220 10:02.600 --> 10:04.840 and so that's going to be 20 bytes. 221 10:04.840 --> 10:08.560 Now again, Ethernet, yeah, we do have another Ethernet header 222 10:08.560 --> 10:11.760 to add on here in the FCS at the end, 223 10:11.760 --> 10:15.000 but these don't count towards layer two MTU. 224 10:15.000 --> 10:18.040 The fact that we have an Ethernet header inside, 225 10:18.040 --> 10:20.880 though that does count because now it's part 226 10:20.880 --> 10:23.760 of the overall payload. 227 10:23.760 --> 10:26.640 So how much do we have to worry about here? 228 10:26.640 --> 10:30.560 Well, you know, this is 16 plus 14 is 30 plus 20, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 228 10:26.640 --> 10:30.560 Well, you know, this is 16 plus 14 is 30 plus 20, 229 10:30.560 --> 10:32.640 that would be 50 bytes. 230 10:32.640 --> 10:35.800 With a slight caveat that if we want to include 231 10:35.800 --> 10:39.880 the plus four bytes for our VLAN tags, 232 10:39.880 --> 10:44.880 then we would have to consider this as a 54 byte increase. 233 10:44.880 --> 10:47.360 But this is typically not used. 234 10:47.360 --> 10:49.240 We typically don't worry about this 235 10:49.240 --> 10:52.480 because we don't usually need to carry the VLAN ID, 236 10:52.480 --> 10:55.440 and nor do we want to, as we talked about quite a bit, 237 10:55.440 --> 10:58.680 but at the same time, just be aware it's either 50 or 54 bytes, 238 10:58.680 --> 11:01.680 depending on when, whether we are carrying the tag. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 238 10:58.680 --> 11:01.680 depending on when, whether we are carrying the tag. 239 11:01.680 --> 11:06.520 Next question, what is the glue that connects layer two domains 240 11:06.520 --> 11:09.880 between V-tips and how many identifiers can be used? 241 11:09.880 --> 11:11.760 There's a lot to unpack with this question, 242 11:11.760 --> 11:13.400 to make sure we understand the concepts here. 243 11:13.400 --> 11:16.920 So VXLAN is going to form a tunnel 244 11:16.920 --> 11:19.720 from one device to another, 245 11:19.720 --> 11:21.080 and these devices have names, 246 11:21.080 --> 11:23.360 they are known as VXLAN tunnel endpoints 247 11:23.360 --> 11:24.840 or virtual tunnel endpoints, 248 11:24.840 --> 11:27.480 that would be the V-type concept. 249 11:27.480 --> 11:29.880 So we're talking about multiple V-tips 250 11:29.880 --> 11:32.320 and forming a VXLAN tunnel between them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 250 11:29.880 --> 11:32.320 and forming a VXLAN tunnel between them. 251 11:32.320 --> 11:35.720 Now, typically what happens here is we extend this down 252 11:35.720 --> 11:37.400 into a layer two domain, 253 11:37.400 --> 11:42.400 and so maybe this is 10.100.0/24, 254 11:42.400 --> 11:45.280 and so we have a host here, that's .1, 255 11:45.280 --> 11:47.480 we have a host over here, that's .2. 256 11:47.480 --> 11:49.560 That's part of the same broadcast domain, 257 11:49.560 --> 11:51.880 and VXLAN is the reason for that 258 11:51.880 --> 11:53.400 because it carries layer two, 259 11:53.400 --> 11:55.000 and so we can use that dotted line 260 11:55.000 --> 11:57.680 to show that yes, .1 and .2 261 11:57.680 --> 12:00.680 are both part of the same layer two domain, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 261 11:57.680 --> 12:00.680 are both part of the same layer two domain, 262 12:00.680 --> 12:03.880 even though this whole world up here is layer three. 263 12:03.880 --> 12:06.720 VXLAN is tunneling layer two through that. 264 12:06.720 --> 12:08.360 So let's go back to the question here, 265 12:08.360 --> 12:10.920 what's the glue that connects the two domains? 266 12:10.920 --> 12:12.800 Technically we could say VXLAN, 267 12:12.800 --> 12:14.200 but really what we're looking for here 268 12:14.200 --> 12:16.360 is that virtual network identifier, 269 12:16.360 --> 12:19.960 which is usually referred to as a VNI or possibly a VNI. 270 12:19.960 --> 12:22.360 So the VNI is an identifier, 271 12:22.360 --> 12:26.320 and importantly it's a 24-bit identifier. 272 12:26.320 --> 12:30.720 So 24-bits gives us a whole lot of values, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 272 12:26.320 --> 12:30.720 So 24-bits gives us a whole lot of values, 273 12:30.720 --> 12:35.720 supports up to 16.7 million different identifiers, 274 12:35.720 --> 12:38.040 that's two to the 24th power, 275 12:38.040 --> 12:40.040 and we no longer need to worry now 276 12:40.040 --> 12:42.400 about running out of VLANs in our space 277 12:42.400 --> 12:45.560 because now we can support 4,000 VLANs here, 278 12:45.560 --> 12:47.840 we can support 4,000 VLANs here, 279 12:47.840 --> 12:52.840 and I can even glue together VLAN 101 with VLAN 511 280 12:52.840 --> 12:55.080 if I so desire. 281 12:55.080 --> 13:00.080 It basically means that VLAN IDs are now local concepts. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 281 12:55.080 --> 13:00.080 It basically means that VLAN IDs are now local concepts. 282 13:00.080 --> 13:06.680 So the VNI, this is what is globally significant. 283 13:06.680 --> 13:09.200 I can't repeat the use of the VNI 284 13:09.200 --> 13:13.040 because if I do then our switches are going to get confused, 285 13:13.040 --> 13:14.920 but because again, in theory, 286 13:14.920 --> 13:18.680 I'm not carrying the VLAN tag here. 287 13:18.680 --> 13:20.560 In fact, I'm not carrying the VLAN tag 288 13:20.560 --> 13:25.440 means that as long as a packet comes in on VLAN 101, 289 13:25.440 --> 13:28.240 I strip off 101, I just send that packet across 290 13:28.240 --> 13:30.480 with this VNI, this switch receives it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 290 13:28.240 --> 13:30.480 with this VNI, this switch receives it 291 13:30.480 --> 13:32.960 and knows to send it out VLAN 511, 292 13:32.960 --> 13:34.680 that's why we can get away with this. 293 13:34.680 --> 13:37.920 And again, the VNI is the glue that holds it all together. 294 13:37.920 --> 13:40.160 Question number six, 295 13:40.160 --> 13:43.160 how does VXLAN natively perform learning 296 13:43.160 --> 13:46.480 for remote endpoints and how does it perform learning 297 13:46.480 --> 13:49.160 in Cisco SD Access? 298 13:49.160 --> 13:53.200 So how do we go about learning things with VXLAN? 299 13:53.200 --> 13:58.200 VXLAN is a data plane only protocol. 300 13:58.200 --> 14:02.920 What this means is that it doesn't have a mechanism WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 300 13:58.200 --> 14:02.920 What this means is that it doesn't have a mechanism 301 14:02.920 --> 14:07.920 for sharing, learning and different identifiers. 302 14:07.920 --> 14:12.520 So the concept of proactively learning requires 303 14:13.320 --> 14:16.800 a control plane where we share something with each other, 304 14:16.800 --> 14:19.600 share routes, share MAC addresses, it doesn't matter. 305 14:19.600 --> 14:23.320 There's sharing is going to require control plane operation 306 14:23.320 --> 14:25.480 and we just set its data plane only. 307 14:25.480 --> 14:30.040 So it can't proactively learn, but it can reactively learn. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 307 14:25.480 --> 14:30.040 So it can't proactively learn, but it can reactively learn. 308 14:30.040 --> 14:33.320 And so the way we reactively learn 309 14:33.320 --> 14:37.400 is to rely on flood and learn. 310 14:37.400 --> 14:40.360 It's exactly how we learn at layer two. 311 14:40.360 --> 14:43.760 So it fits well with VXLAN, which is a layer two concept. 312 14:43.760 --> 14:47.080 So I'm going to have VXLAN tunnels 313 14:47.080 --> 14:51.000 to all these other devices here, or these other V-tips. 314 14:51.000 --> 14:54.360 And when I receive a packet of the destination I don't know, 315 14:54.360 --> 14:57.440 I'm going to have to flood this out. 316 14:57.440 --> 14:59.520 And because this is a layer three domain in here, 317 14:59.520 --> 15:02.120 I flood it out using multicast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 317 14:59.520 --> 15:02.120 I flood it out using multicast. 318 15:02.120 --> 15:05.360 So I multicast it, I send it out to all of these other V-tips, 319 15:05.360 --> 15:08.640 one of them, well, actually all of them 320 15:08.640 --> 15:10.480 are going to forward it out all of their ports 321 15:10.480 --> 15:13.120 because it becomes a broadcast at that point. 322 15:13.120 --> 15:17.360 Now one of them actually has the host attached. 323 15:17.360 --> 15:21.280 And so hopefully we receive a packet back. 324 15:21.280 --> 15:26.280 And because we receive the packet back, now we can learn, 325 15:26.280 --> 15:28.040 hey, next time I get a packet in, 326 15:28.040 --> 15:31.040 I'm just going to send it directly to this other switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 326 15:28.040 --> 15:31.040 I'm just going to send it directly to this other switch. 327 15:31.040 --> 15:33.040 So VXLAN does figure it out eventually, 328 15:33.040 --> 15:35.480 and it figures it out thanks to flooding and learning. 329 15:35.480 --> 15:38.760 But it does not proactively share information. 330 15:38.760 --> 15:39.880 Now does this work? 331 15:39.880 --> 15:41.840 Of course, is it efficient? 332 15:41.840 --> 15:42.960 Of course not. 333 15:42.960 --> 15:45.160 And so we'd really rather be efficient 334 15:45.160 --> 15:47.600 and establish something at the control plane. 335 15:47.600 --> 15:49.320 VXLAN supports many options. 336 15:49.320 --> 15:51.800 It supports multi protocol BGP. 337 15:51.800 --> 15:56.040 Cisco ACI uses that console of Oracle protocol or Koop. 338 15:56.040 --> 15:59.120 And then importantly in SDA, 339 15:59.120 --> 16:01.920 this is where we're going to use Lisp. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 339 15:59.120 --> 16:01.920 this is where we're going to use Lisp. 340 16:01.920 --> 16:03.800 Lisp at the control plane. 341 16:03.800 --> 16:05.320 We don't use Lisp at the data plane. 342 16:05.320 --> 16:08.040 We use VXLAN, but VXLAN doesn't have a control plane, 343 16:08.040 --> 16:09.760 so we need one, and so we use Lisp, 344 16:09.760 --> 16:12.360 and it all works out really well in the end. 345 16:12.360 --> 16:16.760 So that is how we perform not only native learning, 346 16:16.760 --> 16:19.400 but also how we perform proactive learning 347 16:19.400 --> 16:21.460 in software defined access. 348 16:21.460 --> 16:25.760 All right, question number seven, the last one. 349 16:25.760 --> 16:30.000 Match the Lisp roles with the SD access node types. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 349 16:25.760 --> 16:30.000 Match the Lisp roles with the SD access node types. 350 16:30.000 --> 16:33.280 So remember, software defined access, it's using Lisp, 351 16:33.280 --> 16:34.760 but it's going to use its own terms. 352 16:34.760 --> 16:37.040 It doesn't want to use Lisp terms. 353 16:37.040 --> 16:39.800 That's more of a service provider concept. 354 16:39.800 --> 16:44.560 Instead, Cisco developed a bunch of SDA terms, 355 16:44.560 --> 16:45.760 and we're going to use those, 356 16:45.760 --> 16:48.200 even though they're really code 357 16:48.200 --> 16:50.280 for what we're running underneath. 358 16:50.280 --> 16:51.540 And what we're running underneath 359 16:51.540 --> 16:53.920 is indeed Lisp and VXLAN. 360 16:53.920 --> 16:55.680 So the control plane node. 361 16:55.680 --> 16:58.880 From a Lisp perspective, this is going to run that MSMR, 362 16:58.880 --> 17:01.760 the map server, map resolver here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 362 16:58.880 --> 17:01.760 the map server, map resolver here. 363 17:01.760 --> 17:04.600 The MSMR is going to run on the same device 364 17:04.600 --> 17:05.880 like we indicated, 365 17:05.880 --> 17:08.240 and it's going to run on the control plane node. 366 17:08.240 --> 17:10.400 All my fabric edge nodes here, 367 17:10.400 --> 17:13.320 these are going to be the XTRs, 368 17:13.320 --> 17:15.840 and when the, I'll just say XTR, 369 17:15.840 --> 17:18.280 when the fabric edge node receives a packet, 370 17:18.280 --> 17:22.760 it's going to pull the as needed route down 371 17:22.760 --> 17:24.360 to the endpoint identifier, 372 17:24.360 --> 17:25.960 and it's going to form a tunnel 373 17:25.960 --> 17:28.940 across to the other fabric edge node. 374 17:28.940 --> 17:32.400 The fabric border node is going to be the proxy XTR. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 374 17:28.940 --> 17:32.400 The fabric border node is going to be the proxy XTR. 375 17:33.560 --> 17:36.080 It's going to serve the device that again, 376 17:36.080 --> 17:39.600 advertises, pushes the Lisp routes, 377 17:39.600 --> 17:41.720 in our case the SDA routes, 378 17:41.720 --> 17:43.600 out of the SDA environment, 379 17:43.600 --> 17:47.920 it also handles traffic into and out of SDA. 380 17:47.920 --> 17:49.760 So that brings us to the end of our review 381 17:49.760 --> 17:51.280 on virtualization technologies. 382 17:51.280 --> 17:54.200 Again, the quizzes and the challenges were designed 383 17:54.200 --> 17:58.000 to make it so that we could maybe remember certain details 384 17:58.000 --> 17:59.840 about how all of this comes together. 385 17:59.840 --> 18:03.040 But when it's time to review how to do the configuration WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 385 17:59.840 --> 18:03.040 But when it's time to review how to do the configuration 386 18:03.040 --> 18:06.720 for a GRE or IPSec and recursive routing, 387 18:06.720 --> 18:09.040 then be sure to go back to those individual skills 388 18:09.040 --> 18:11.960 and perform the lab in those skills. 389 18:11.960 --> 18:14.560 We can do it now or do it at the end of the course, 390 18:14.560 --> 18:16.040 but either way it's going to be very important 391 18:16.040 --> 18:18.240 that we take some amount of time 392 18:18.240 --> 18:21.480 to review the configuration of those technologies as well. 393 18:21.480 --> 18:22.760 I hope this has been informative for you, 394 18:22.760 --> 18:24.720 and I'd like to thank you for viewing.