WEBVTT 1 00:00.000 --> 00:05.500 Overlay networks have really become our go-to for creating better network top 2 00:05.500 --> 00:06.760 ologies. 3 00:06.760 --> 00:11.690 As we've said before, an overlay network is sort of the network that I want 4 00:11.690 --> 00:12.260 when I don't 5 00:12.260 --> 00:13.260 have it. 6 00:13.260 --> 00:16.640 What I have is an underlay network. 7 00:16.640 --> 00:21.260 And so this might be a situation where we've seen that we create an underlay 8 00:21.260 --> 00:22.320 network that 9 00:22.320 --> 00:25.480 consists of maybe a layer three world. 10 00:25.480 --> 00:28.800 So maybe I've got layer three between a bunch of devices, but I really want 11 00:28.800 --> 00:29.680 layer two. 12 00:29.680 --> 00:34.190 And so I create a layer two overlay over that underlay or possibly just a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:29.680 --> 00:34.190 And so I create a layer two overlay over that underlay or possibly just a 13 00:34.190 --> 00:35.520 different logical 14 00:35.520 --> 00:36.520 architecture. 15 00:36.520 --> 00:40.950 So whatever this underlay ultimately looks like, you can have all kinds of 16 00:40.950 --> 00:41.680 different 17 00:41.680 --> 00:46.160 hops in here and different network paths and so on and so forth. 18 00:46.160 --> 00:51.860 But if I create a tunnel from this device to this device, well, now these two 19 00:51.860 --> 00:52.480 devices 20 00:52.480 --> 00:57.600 are directly connected and they can directly share a GRP and OSPF routes. 21 00:57.600 --> 01:01.450 And so if I want these two devices to be effectively connected to one another WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:57.600 --> 01:01.450 And so if I want these two devices to be effectively connected to one another 22 01:01.450 --> 01:02.200 via layer 23 01:02.200 --> 01:06.800 three, well, that's where I create that overlay of what I want. 24 01:06.800 --> 01:12.770 Now we're called a long time ago where we discussed the concept of access layer 25 01:12.770 --> 01:13.800 fabrics. 26 01:13.800 --> 01:19.580 We are finally going to bring this all back around because we have talked about 27 01:19.580 --> 01:20.040 LISP and 28 01:20.040 --> 01:23.040 now we're going to be talking about VXLAN. 29 01:23.040 --> 01:26.610 And the reason why we're talking about these technologies and why they show up 30 01:26.610 --> 01:27.040 on this 31 01:27.040 --> 01:32.270 exam blueprint and inside of this course is because of access fabrics being an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:27.040 --> 01:32.270 exam blueprint and inside of this course is because of access fabrics being an 32 01:32.270 --> 01:33.080 important 33 01:33.080 --> 01:36.040 part of enterprise network design. 34 01:36.040 --> 01:39.960 And so we've talked about LISP and again, we're going to talk about VXLAN. 35 01:39.960 --> 01:44.010 But in order to really understand what VXLAN is trying to accomplish, it helps 36 01:44.010 --> 01:44.480 to know 37 01:44.480 --> 01:47.880 where it came from and why it was developed. 38 01:47.880 --> 01:52.720 And the answer to where it came from is once again, the data center. 39 01:52.720 --> 01:56.830 The data center kind of keeps coming up in these network conversations, even 40 01:56.830 --> 01:57.680 though this 41 01:57.680 --> 01:59.000 is on core. 42 01:59.000 --> 02:02.640 And yes, there is a data center core exam, DC core. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:59.000 --> 02:02.640 And yes, there is a data center core exam, DC core. 43 02:02.640 --> 02:03.640 And hey, guess what? 44 02:03.640 --> 02:08.160 We have that content available on our website here at CBT Nuggets. 45 02:08.160 --> 02:12.000 But at the same time, even though we say, well, data center technology should 46 02:12.000 --> 02:12.440 really 47 02:12.440 --> 02:19.020 be in its own, maybe a pillar of network architecture, at the same time, the 48 02:19.020 --> 02:20.160 data center 49 02:20.160 --> 02:22.200 is part of our network design. 50 02:22.200 --> 02:26.190 So we think back to the hierarchical network model where we've got the core of 51 02:26.190 --> 02:26.920 the network 52 02:26.920 --> 02:31.090 and we know that connects to a distribution block, which connects to our access WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:26.920 --> 02:31.090 and we know that connects to a distribution block, which connects to our access 53 02:31.090 --> 02:31.320 . 54 02:31.320 --> 02:33.840 We've got all kinds of different blocks in here. 55 02:33.840 --> 02:39.500 And one of the important blocks is the data center aggregation, which leads to 56 02:39.500 --> 02:40.160 the data 57 02:40.160 --> 02:41.720 center access layer. 58 02:41.720 --> 02:45.280 So this whole thing over here is our data center. 59 02:45.280 --> 02:47.080 Why is the data center so important? 60 02:47.080 --> 02:51.460 Well, again, we have two things that we host in the data center that are 61 02:51.460 --> 02:52.920 mission critical. 62 02:52.920 --> 02:55.400 Number one is our applications. 63 02:55.400 --> 02:59.600 And it's really hard to run most of our organizations these days if we have no 64 02:59.600 --> 03:01.760 access to our applications. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 64 02:59.600 --> 03:01.760 access to our applications. 65 03:01.760 --> 03:05.410 Not a lot we can do with pencil and paper if we don't have access to what we 66 03:05.410 --> 03:05.880 need on 67 03:05.880 --> 03:07.200 the computers. 68 03:07.200 --> 03:10.440 But the second thing we host is our data. 69 03:10.440 --> 03:15.590 Whether that's files and just file servers or maybe even intellectual property, 70 03:15.590 --> 03:16.360 the massive 71 03:16.360 --> 03:20.470 amount of storage and data that we run in data centers and now run analytics 72 03:20.470 --> 03:21.000 against 73 03:21.000 --> 03:26.000 that data, that is all mission critical for our organizations as well. 74 03:26.000 --> 03:30.970 And so because of the fact that this is so important to our organization, the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 74 03:26.000 --> 03:30.970 And so because of the fact that this is so important to our organization, the 75 03:30.970 --> 03:31.720 data center 76 03:31.720 --> 03:36.400 is considered a highly critical environment. 77 03:36.400 --> 03:43.170 Now when we think of a classical data center architecture, there is strong 78 03:43.170 --> 03:45.000 parallels between 79 03:45.000 --> 03:49.420 the data center, this traditional classic architecture and what we did on the 80 03:49.420 --> 03:49.880 campus 81 03:49.880 --> 03:50.880 side. 82 03:50.880 --> 03:56.320 So we really relied heavily on the same three tier architecture. 83 03:56.320 --> 04:00.310 The idea here was that we'd have a core network block and I would create that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 83 03:56.320 --> 04:00.310 The idea here was that we'd have a core network block and I would create that 84 04:00.310 --> 04:01.120 aggregation 85 04:01.120 --> 04:02.120 block. 86 04:02.120 --> 04:05.280 So let's just do a pair of aggregation switches. 87 04:05.280 --> 04:11.010 And remember the aggregation is very similar to the distribution block on the 88 04:11.010 --> 04:11.920 access layer 89 04:11.920 --> 04:14.600 or on the campus side. 90 04:14.600 --> 04:18.560 And so the idea here is that we're going to connect up via layer three to our 91 04:18.560 --> 04:19.800 core network, 92 04:19.800 --> 04:22.040 over the core of our network. 93 04:22.040 --> 04:25.840 And then we also have an access layer down here. 94 04:25.840 --> 04:31.200 So we've got lots and lots and lots of these access layer switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 94 04:25.840 --> 04:31.200 So we've got lots and lots and lots of these access layer switches. 95 04:31.200 --> 04:34.480 And then we're going to connect down here all of our devices. 96 04:34.480 --> 04:38.160 Now our devices in the data center look a little different than our campus. 97 04:38.160 --> 04:41.800 We don't have phones and access points and said we have servers, we have 98 04:41.800 --> 04:42.840 storage arrays, 99 04:42.840 --> 04:47.490 we have appliances, we have all kinds of things in the data center that we don 100 04:47.490 --> 04:48.120 't really see 101 04:48.120 --> 04:50.360 a whole lot of in the campus. 102 04:50.360 --> 04:53.800 And vice versa, we don't see campus things inside the data center. 103 04:53.800 --> 04:55.360 Very different use cases. 104 04:55.360 --> 04:59.970 But we do see that this strongly parallels having a distribution and access 105 04:59.970 --> 05:00.720 block like WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 105 04:59.970 --> 05:00.720 block like 106 05:00.720 --> 05:04.320 we're used to over on the campus side. 107 05:04.320 --> 05:10.400 So the thing about data centers is that we require layer two everywhere. 108 05:10.400 --> 05:14.220 And we say that we like layer two on the campus side, but we can sometimes get 109 05:14.220 --> 05:15.120 away with layer 110 05:15.120 --> 05:21.630 three out to the campus access layer because layer two isn't really necessary 111 05:21.630 --> 05:22.320 in a lot 112 05:22.320 --> 05:26.050 of situations outside of maybe printers that need to communicate with one 113 05:26.050 --> 05:27.200 another, something 114 05:27.200 --> 05:28.360 like that. 115 05:28.360 --> 05:31.240 But in the data center, this is mission critical. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 115 05:28.360 --> 05:31.240 But in the data center, this is mission critical. 116 05:31.240 --> 05:35.610 We have to have layer two between our servers and our storage especially, but 117 05:35.610 --> 05:36.040 then some 118 05:36.040 --> 05:43.160 appliances and softwares, they also require layer two among each other. 119 05:43.160 --> 05:47.080 And so we need layer two everywhere, which is fine because we built this out 120 05:47.080 --> 05:47.760 with layer 121 05:47.760 --> 05:48.760 two. 122 05:48.760 --> 05:52.840 Now, I say fine, but we still have to worry about things like spanning tree in 123 05:52.840 --> 05:53.840 this topology. 124 05:53.840 --> 05:57.280 We have to worry about first-to-part redundancy protocols and all of the same 125 05:57.280 --> 05:57.920 things that 126 05:57.920 --> 05:59.760 we have to worry about on the campus side. 127 05:59.760 --> 06:04.720 There's one of the reasons why we want to go to a campus access fabric rather WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 05:59.760 --> 06:04.720 There's one of the reasons why we want to go to a campus access fabric rather 128 06:04.720 --> 06:05.440 than having 129 06:05.440 --> 06:09.420 layer three or layer two everywhere and having to decide, we go with something 130 06:09.420 --> 06:10.280 like a fabric, 131 06:10.280 --> 06:13.680 which is, hey, where we're going with this whole conversation as well. 132 06:13.680 --> 06:19.180 Well, when we move over to or when we realize that we run out of space on the 133 06:19.180 --> 06:20.200 aggregation 134 06:20.200 --> 06:25.100 layer, we can't just add a third switch because of spanning tree protocol, 135 06:25.100 --> 06:26.360 because of first-to-part 136 06:26.360 --> 06:31.080 redundancy protocols, because of physical connectivity concerns, this third WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 06:26.360 --> 06:31.080 redundancy protocols, because of physical connectivity concerns, this third 137 06:31.080 --> 06:32.320 switch concept 138 06:32.320 --> 06:33.640 doesn't really exist. 139 06:33.640 --> 06:38.040 But we can't just keep building up and building up aggregation switches. 140 06:38.040 --> 06:41.560 It's going to be port limits and throughput limits on those. 141 06:41.560 --> 06:45.770 So what we do in the data center, again, the classic model, is we bring this 142 06:45.770 --> 06:46.640 together and 143 06:46.640 --> 06:51.760 we refer to this as a pod. 144 06:51.760 --> 06:56.840 And so from here, we can build another pod. 145 06:56.840 --> 07:00.320 And so we've got a pair of aggregation switches over here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 06:56.840 --> 07:00.320 And so we've got a pair of aggregation switches over here. 146 07:00.320 --> 07:05.250 This is layer three to the core, and then we've got our access down here, and 147 07:05.250 --> 07:06.160 it's all going 148 07:06.160 --> 07:08.520 to be built out the same. 149 07:08.520 --> 07:09.600 What's the problem with this? 150 07:09.600 --> 07:13.900 Well, the problem with it is that even though we've got layer two everywhere 151 07:13.900 --> 07:14.600 here on the 152 07:14.600 --> 07:19.600 right on this pod, we've got two different pods now, we see that we have layer 153 07:19.600 --> 07:20.080 three 154 07:20.080 --> 07:23.560 segmentation through the network core. 155 07:23.560 --> 07:28.460 So if this storage array needs to be accessed by this server, we're going to 156 07:28.460 --> 07:29.360 have to have 157 07:29.360 --> 07:33.400 layer three segmentation, which causes a lot of problems. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 157 07:29.360 --> 07:33.400 layer three segmentation, which causes a lot of problems. 158 07:33.400 --> 07:39.300 So this concept of a three tier model and the scaling out via layer three that 159 07:39.300 --> 07:39.760 just 160 07:39.760 --> 07:44.000 doesn't fit very well with our data centers. 161 07:44.000 --> 07:46.920 So there's two problems here. 162 07:46.920 --> 07:52.280 First of all, it's just the layer three segmentation. 163 07:52.280 --> 07:55.960 But second of all, another problem starts to occur as we build out these very 164 07:55.960 --> 07:56.360 large 165 07:56.360 --> 07:58.000 layer two spaces. 166 07:58.000 --> 08:01.100 Because what we might start to do is say, okay, well, we're just going to make WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 166 07:58.000 --> 08:01.100 Because what we might start to do is say, okay, well, we're just going to make 167 08:01.100 --> 08:02.800 the aggregation 168 08:02.800 --> 08:04.400 layer as large as possible. 169 08:04.400 --> 08:08.800 And we're just going to deal with the pain points of having to scale this up as 170 08:08.800 --> 08:09.360 much as 171 08:09.360 --> 08:12.160 we can, but we don't want to create another pod. 172 08:12.160 --> 08:18.610 The other problem we start to run into is that our VLAN identifiers, that 4,000 173 08:18.610 --> 08:19.040 is too 174 08:19.040 --> 08:20.040 much. 175 08:20.040 --> 08:27.960 We need more than 4,000 or 4K here, we'll say, more than 4,000 identifiers. 176 08:27.960 --> 08:31.120 The reason for that is we want to keep our broadcast domain small, we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 176 08:27.960 --> 08:31.120 The reason for that is we want to keep our broadcast domain small, we're 177 08:31.120 --> 08:32.360 deploying small 178 08:32.360 --> 08:36.000 VLANs everywhere, but that starts to add up. 179 08:36.000 --> 08:40.010 And this is especially true in the service provider space, because they 180 08:40.010 --> 08:40.960 typically will 181 08:40.960 --> 08:43.320 assign multiple VLANs per customer. 182 08:43.320 --> 08:47.750 And as they scale up to potentially even just a few hundred, let alone like a 183 08:47.750 --> 08:48.320 thousand 184 08:48.320 --> 08:53.640 or 2,000 customers, we do start to run out of VLANs very, very quickly. 185 08:53.640 --> 08:55.440 So what's the solution to all of this? 186 08:55.440 --> 08:59.520 Well, the solution is to create a combination of two different technologies, 187 08:59.520 --> 09:00.200 the first of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 187 08:59.520 --> 09:00.200 the first of 188 09:00.200 --> 09:03.120 which is that spine leaf architecture. 189 09:03.120 --> 09:06.180 And we've talked about some of this, I understand some of this is review, but 190 09:06.180 --> 09:07.200 again, it's important 191 09:07.200 --> 09:10.320 to really understand where we're coming from here. 192 09:10.320 --> 09:15.770 So the spine leaf architecture changes this classic notion to say, hey, instead 193 09:15.770 --> 09:16.640 of building 194 09:16.640 --> 09:21.970 it out such that we have to rely on layer three, let's go ahead and flip things 195 09:21.970 --> 09:22.520 around 196 09:22.520 --> 09:28.520 a little bit and try to create more of a backbone centric architecture. 197 09:28.520 --> 09:30.320 What exactly does that look like? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 197 09:28.520 --> 09:30.320 What exactly does that look like? 198 09:30.320 --> 09:36.930 Well, what we're saying here is that we want to have our, if we want to think 199 09:36.930 --> 09:37.960 of it, our 200 09:37.960 --> 09:42.370 more aggregation level switches, all we really want them to do is switch 201 09:42.370 --> 09:43.560 traffic between the 202 09:43.560 --> 09:45.240 leaf switches. 203 09:45.240 --> 09:49.800 So you build out your spine and leaf architecture and spines connect to leaf 204 09:49.800 --> 09:50.880 switches, leaf 205 09:50.880 --> 09:54.750 switches connect to spine switches, but we do not connect all of these switches 206 09:54.750 --> 09:55.640 together. 207 09:55.640 --> 09:57.920 Leaf switches don't connect to leaf switches. 208 09:57.920 --> 10:00.440 Spines don't connect to spines. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 208 09:57.920 --> 10:00.440 Spines don't connect to spines. 209 10:00.440 --> 10:03.720 And all of these, by the way, are layer three leaks. 210 10:03.720 --> 10:07.710 And so the idea here is to enable very fast switching from one of these leaf 211 10:07.710 --> 10:08.440 switches to 212 10:08.440 --> 10:10.120 another leaf switch. 213 10:10.120 --> 10:15.640 And furthermore, because it's layer three, we can scale out to potentially 214 10:15.640 --> 10:16.560 hundreds of 215 10:16.560 --> 10:20.960 leaf switches, I mean, the scale of this is absolutely enormous. 216 10:20.960 --> 10:25.640 We're more limited by physical limits, such as ports on the spine switches, as 217 10:25.640 --> 10:26.160 well as 218 10:26.160 --> 10:28.720 just fiber in the data center. 219 10:28.720 --> 10:33.500 And what's interesting about this is that because of that, these switches in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 219 10:28.720 --> 10:33.500 And what's interesting about this is that because of that, these switches in 220 10:33.500 --> 10:34.000 the spine 221 10:34.000 --> 10:38.610 layer are a little bit more dumb, meaning all they care about is bringing a 222 10:38.610 --> 10:40.640 packet in 223 10:40.640 --> 10:42.360 and sending that packet out. 224 10:42.360 --> 10:46.890 They're not responsible for things like spanning tree roots and FHRP and 225 10:46.890 --> 10:48.040 running all of these 226 10:48.040 --> 10:49.040 protocols. 227 10:49.040 --> 10:51.880 They are focused on switching packets. 228 10:51.880 --> 10:55.480 That's all they really care about. 229 10:55.480 --> 11:00.650 So not only is this highly scalable, which is a huge improvement over the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 10:55.480 --> 11:00.650 So not only is this highly scalable, which is a huge improvement over the 230 11:00.650 --> 11:01.640 traditional 231 11:01.640 --> 11:04.520 architecture, it's also highly consistent. 232 11:04.520 --> 11:11.010 There's kind of an interesting side effect to this that every single device is 233 11:11.010 --> 11:11.760 exactly 234 11:11.760 --> 11:14.880 two hops away. 235 11:14.880 --> 11:20.420 So if I have a server over here and a storage array I want to communicate with, 236 11:20.420 --> 11:21.400 well, that 237 11:21.400 --> 11:24.920 could be here, it could be here, it could be all the way out here. 238 11:24.920 --> 11:28.820 And it doesn't matter because I simply have to send my packet up to one of 239 11:28.820 --> 11:29.560 these spine 240 11:29.560 --> 11:30.560 switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 240 11:29.560 --> 11:30.560 switches. 241 11:30.560 --> 11:32.200 That's hop number one. 242 11:32.200 --> 11:37.720 And then hop number two is to get down to the remote leaf switch. 243 11:37.720 --> 11:38.720 And there we go. 244 11:38.720 --> 11:46.160 I don't have to worry about possibly going one, two, three, four, five hops or 245 11:46.160 --> 11:47.960 one, two, 246 11:47.960 --> 11:52.160 I guess that would still be two hops within the same pod. 247 11:52.160 --> 11:54.600 So we don't have to worry about those inconsistencies anymore. 248 11:54.600 --> 11:59.440 It's far more consistent and that creates much better network performance. 249 11:59.440 --> 12:01.960 Well, we still have a problem. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 249 11:59.440 --> 12:01.960 Well, we still have a problem. 250 12:01.960 --> 12:05.480 And we already said that we need this to be layer two everywhere. 251 12:05.480 --> 12:09.040 And we've gotten rid of that because of the layer three. 252 12:09.040 --> 12:10.960 Well, where do we get the layer two from? 253 12:10.960 --> 12:15.180 And that is the second technology, which is VXLAN, which allows us to deploy 254 12:15.180 --> 12:16.560 layer two 255 12:16.560 --> 12:18.880 over layer three. 256 12:18.880 --> 12:25.320 So now I can form a VXLAN tunnel from one of these leaf switches over to the 257 12:25.320 --> 12:26.440 other leaf 258 12:26.440 --> 12:31.730 switch or actually let's say we're communicating to one of those storage arrays WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 258 12:26.440 --> 12:31.730 switch or actually let's say we're communicating to one of those storage arrays 259 12:31.730 --> 12:31.760 . 260 12:31.760 --> 12:37.790 So now I create a layer two tunnel and that carries the entire ethernet frame 261 12:37.790 --> 12:38.560 and through 262 12:38.560 --> 12:42.790 the layer three infrastructure and allows these devices to be layer two 263 12:42.790 --> 12:43.720 connected. 264 12:43.720 --> 12:48.210 Furthermore, we're going to find that VXLAN identifiers solve this problem over 265 12:48.210 --> 12:48.560 here 266 12:48.560 --> 12:52.520 on the right where we're running out of VLAN IDs. 267 12:52.520 --> 13:00.300 As we've said before, VXLANs allow up to 16.7 or so million identifiers far WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 267 12:52.520 --> 13:00.300 As we've said before, VXLANs allow up to 16.7 or so million identifiers far 268 13:00.300 --> 13:00.920 more than 269 13:00.920 --> 13:02.720 the 4000 we get with VLANs. 270 13:02.720 --> 13:09.680 It really comes down to this being 12 bits versus 24 bits for the XLAN. 271 13:09.680 --> 13:14.370 So the spine leaf in the XLAN architecture, this is where the data center is 272 13:14.370 --> 13:15.200 being built 273 13:15.200 --> 13:17.960 out today and how it's being built out today. 274 13:17.960 --> 13:23.570 But this VXLAN technology, it's starting to be used outside of the data center 275 13:23.570 --> 13:24.320 as well. 276 13:24.320 --> 13:29.270 And so we're seeing it actually being deployed into these access fabrics that 277 13:29.270 --> 13:30.120 we deploy on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 277 13:29.270 --> 13:30.120 we deploy on 278 13:30.120 --> 13:31.640 the campus side. 279 13:31.640 --> 13:33.760 So this is why we're studying VXLANs. 280 13:33.760 --> 13:37.170 It's important to know where it came from and why it matters so much and what 281 13:37.170 --> 13:37.640 exactly 282 13:37.640 --> 13:42.340 it's accomplishing, namely this layer two over layer three via tunneling 283 13:42.340 --> 13:43.320 mechanism. 284 13:43.320 --> 13:46.680 But at the end of the day, what we're really going to apply this towards within 285 13:46.680 --> 13:47.160 the world 286 13:47.160 --> 13:51.210 of enterprise networking is seeing that it also enables us to be able to create 287 13:51.210 --> 13:51.640 these 288 13:51.640 --> 13:53.920 access layer types of fabrics.