WEBVTT 1 00:00.000 --> 00:04.280 As we dive into this conversation about software defined access, it's important 2 00:04.280 --> 00:08.000 for us to think back to our earlier conversations about network architecture. 3 00:08.000 --> 00:12.480 The software defined access is supposed to be solving some of the problems that 4 00:12.480 --> 00:16.000 we've had for a long time with our traditional network architectures. 5 00:16.000 --> 00:19.000 We just didn't have technology that could do it any better. 6 00:19.000 --> 00:22.000 And the idea here is that now we do have that technology. 7 00:22.000 --> 00:25.000 And so let's go ahead and start taking advantage of it. 8 00:25.000 --> 00:30.120 And so let's think back to those challenges when we talk about our access layer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 8 00:25.000 --> 00:30.120 And so let's think back to those challenges when we talk about our access layer 9 00:30.120 --> 00:31.000 designs. 10 00:31.000 --> 00:37.000 We had to, first of all, choose between layer 2 and layer 3. 11 00:37.000 --> 00:42.000 And both of these architecture types came with challenges. 12 00:42.000 --> 00:46.830 So when we look at layer 2, layer 2 is how a lot of our organizations deploy 13 00:46.830 --> 00:48.000 the access layer. 14 00:48.000 --> 00:53.720 But we have to have a conversation about our redundancy versus the loops in our 15 00:53.720 --> 00:58.000 environment, recognizing that every loop that we create adds redundancy and 16 00:58.000 --> 00:58.000 that's good. 17 00:58.000 --> 01:03.000 But it also creates the possibility of an actual network loop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 17 00:58.000 --> 01:03.000 But it also creates the possibility of an actual network loop. 18 01:03.000 --> 01:09.000 And so we're relying on spanning tree in order to offer us loop prevention. 19 01:09.000 --> 01:14.670 So we think about STP loops, but we also think about the fact that we have to 20 01:14.670 --> 01:18.000 deploy spanning tree protocol policy. 21 01:18.000 --> 01:22.620 So we think about defining the spanning tree roots and the priorities and the 22 01:22.620 --> 01:26.000 costs and deploying things like root guard and BPU guard. 23 01:26.000 --> 01:30.000 This is a mission critical part of deploying layer 2 to the edge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 24 01:30.000 --> 01:32.000 And we have to be very intentional about this. 25 01:32.000 --> 01:38.000 And what we find eventually is that layer 2 just runs into scaling issues. 26 01:38.000 --> 01:42.000 We can't build massive layer 2 networks. 27 01:42.000 --> 01:45.000 Not only do we have issues from a subnetting perspective. 28 01:45.000 --> 01:50.000 For example, we might have to explore going from a slash 24 to a slash 23. 29 01:50.000 --> 01:54.000 And now we have 512 IP addresses in there. 30 01:54.000 --> 01:57.000 Or we go to a slash 22 and we have over a thousand. 31 01:57.000 --> 01:59.000 So that's from an IP perspective. 32 01:59.000 --> 02:04.000 But we also have an issue at layer 2 from a broadcast perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:59.000 --> 02:04.000 But we also have an issue at layer 2 from a broadcast perspective. 33 02:04.000 --> 02:08.970 And so things start to get really dicey as we scale out to very large 34 02:08.970 --> 02:13.000 organizational networks that are built on layer 2. 35 02:13.000 --> 02:17.750 And so we might think about layer 3 and saying, hey, let's create a layer 3 36 02:17.750 --> 02:22.000 access layer design to solve some of these problems, which is wonderful. 37 02:22.000 --> 02:27.000 From a scaling perspective, I can scale up to as large of networks as I want. 38 02:27.000 --> 02:29.000 I don't have to worry about spanning tree loops. 39 02:29.000 --> 02:32.000 All of this is wonderful from a layer 3 perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 02:29.000 --> 02:32.000 All of this is wonderful from a layer 3 perspective. 40 02:32.000 --> 02:36.000 However, now I need to manage routing protocols. 41 02:36.000 --> 02:43.560 So I've got to run OSPF or EIGRP in my network all the way down to the access 42 02:43.560 --> 02:47.000 layer, which can add complexity. 43 02:47.000 --> 02:50.000 We also have flexibility limitations. 44 02:50.000 --> 02:57.050 So our flexibility is overall down because there's no subnet sharing among my 45 02:57.050 --> 02:59.000 access closets. 46 02:59.000 --> 03:04.040 Because I'm now layer 3 segmented, I don't have the luxury of extending the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 46 02:59.000 --> 03:04.040 Because I'm now layer 3 segmented, I don't have the luxury of extending the 47 03:04.040 --> 03:06.000 same subnet everywhere. 48 03:06.000 --> 03:09.850 And so if I have printers that need to be on the same subnet, well, that's just 49 03:09.850 --> 03:13.000 not going to be an option, which is why we say our flexibility is lower. 50 03:13.000 --> 03:17.630 Even if we don't need this function, the day we deploy our network, we might 51 03:17.630 --> 03:19.000 one day need it. 52 03:19.000 --> 03:24.450 And flexibility is going to be what drives our capabilities when it comes to 53 03:24.450 --> 03:27.000 making quick network changes. 54 03:27.000 --> 03:32.000 And we also have to concern ourselves with layer 3 wireless roaming. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 03:27.000 --> 03:32.000 And we also have to concern ourselves with layer 3 wireless roaming. 55 03:32.000 --> 03:37.430 Within an access layer design, we typically have wireless access points, and we 56 03:37.430 --> 03:41.360 want to be able to roam from access point to access point in the same physical 57 03:41.360 --> 03:42.000 space. 58 03:42.000 --> 03:47.190 Well, if now I have layer 3 between my access closets, I'm going to have to 59 03:47.190 --> 03:50.000 perform layer 3 rooms short of potentially. 60 03:50.000 --> 03:55.830 We can get around this with wireless lane controllers, and especially talking 61 03:55.830 --> 03:58.000 about our capwap tunnels. 62 03:58.000 --> 04:02.790 So this can help us in this scenario, but if we're not using Cisco wireless WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 03:58.000 --> 04:02.790 So this can help us in this scenario, but if we're not using Cisco wireless 63 04:02.790 --> 04:07.080 lane controllers on premise, for example, well, then we're going to have to 64 04:07.080 --> 04:09.000 deal with layer 3 wireless roaming. 65 04:09.000 --> 04:14.950 So these are challenges that we have just in the operation and scaling of our 66 04:14.950 --> 04:17.000 access layer designs. 67 04:17.000 --> 04:21.000 But this goes beyond just talking about layer 2 and layer 3 challenges. 68 04:21.000 --> 04:26.370 We also have additional challenges around management of our campus infrast 69 04:26.370 --> 04:31.520 ructures, because when we think about a very large campus architecture with lots WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 04:26.370 --> 04:31.520 ructures, because when we think about a very large campus architecture with lots 70 04:31.520 --> 04:38.000 of access layer closets, we have an enormous number of access layer switches. 71 04:38.000 --> 04:43.820 So our access switch count can be very high, which leads to maybe not always 72 04:43.820 --> 04:49.000 doing the right things when it comes to managing our switches. 73 04:49.000 --> 04:54.000 For example, how much do we manage our iOS XC versions? 74 04:54.000 --> 04:58.780 In a perfect world, we'd be running the exact same version of code on all of 75 04:58.780 --> 05:00.000 our switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 76 05:00.000 --> 05:05.060 So this is important from an operational perspective, making sure we're not 77 05:05.060 --> 05:09.000 running into major bugs. We want to find a stable version and stick with it. 78 05:09.000 --> 05:13.560 But it's also important from a security perspective, because we want to find a 79 05:13.560 --> 05:16.000 version of code that we feel is secure. 80 05:16.000 --> 05:21.430 And if I have a known security issue on a particular version of code, I need to 81 05:21.430 --> 05:24.000 make sure it's not running in my environment. 82 05:24.000 --> 05:28.020 But if I have hundreds of access layer switches, it's very difficult to make 83 05:28.020 --> 05:31.000 sure that all of them are running the correct code. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 83 05:28.020 --> 05:31.000 sure that all of them are running the correct code. 84 05:31.000 --> 05:35.000 We also have the problem of configuration sprawl. 85 05:35.000 --> 05:40.280 It's easy for me to deploy configurations where it makes sense to do so, and 86 05:40.280 --> 05:44.120 then kind of forget to go back later and remove some of those configurations, 87 05:44.120 --> 05:51.400 making sure that our standards are being enforced across all of our campus 88 05:51.400 --> 05:52.000 buildings, 89 05:52.000 --> 05:57.590 and also all of our access layer closets that they all have very similar 90 05:57.590 --> 05:59.000 configurations. 91 05:59.000 --> 06:05.880 But this conversation also goes in the direction of talking about different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 05:59.000 --> 06:05.880 But this conversation also goes in the direction of talking about different 92 06:05.880 --> 06:08.000 hardware versions. 93 06:08.000 --> 06:13.850 Again, in a perfect world, we would ideally deploy the exact same version of 94 06:13.850 --> 06:17.000 hardware to all of our access closets. 95 06:17.000 --> 06:22.520 So, as hardware gets retired from a staggered perspective, I might replace some 96 06:22.520 --> 06:28.720 hardware with a new type of hardware, but then by the time I replace other clos 97 06:28.720 --> 06:32.170 ets, even newer version of hardware is out, and we have lots of these different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 97 06:28.720 --> 06:32.170 ets, even newer version of hardware is out, and we have lots of these different 98 06:32.170 --> 06:33.000 hardware versions. 99 06:33.000 --> 06:37.070 This can be difficult not only from a code management perspective like we just 100 06:37.070 --> 06:41.000 talked about, but also from a configuration management perspective. 101 06:41.000 --> 06:46.030 We think about configurations such as quality of service, especially quality of 102 06:46.030 --> 06:51.000 service tends to differ greatly between our different hardware platforms. 103 06:51.000 --> 06:56.750 And so if I have 90/200s in some parts of my network and 9300s in other parts 104 06:56.750 --> 07:02.830 and maybe even some more legacy 38/50s, well, how do I make sure that QOS is an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 104 06:56.750 --> 07:02.830 and maybe even some more legacy 38/50s, well, how do I make sure that QOS is an 105 07:02.830 --> 07:08.250 end-to-end configuration that works well from end to end when I have so many 106 07:08.250 --> 07:10.000 different versions of hardware in my network? 107 07:10.000 --> 07:15.750 And a big part of managing any network is going to be my ability to see what's 108 07:15.750 --> 07:17.000 happening. 109 07:17.000 --> 07:23.130 So my visibility into network operations, understanding what's happening, if 110 07:23.130 --> 07:27.920 there's a problem, how quickly can we identify it, and then we want to be able 111 07:27.920 --> 07:31.000 to quickly troubleshoot any issues. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 111 07:27.920 --> 07:31.000 to quickly troubleshoot any issues. 112 07:31.000 --> 07:35.720 So visibility and troubleshooting can be very difficult if we have a sudden 113 07:35.720 --> 07:41.480 network outage. Today I might have to log into the CLI and I might have to hop 114 07:41.480 --> 07:45.620 from device to device to device to try to figure out what's going on in this 115 07:45.620 --> 07:46.000 network. 116 07:46.000 --> 07:50.540 And some issues like maybe wireless connectivity issues, they could be a 117 07:50.540 --> 07:54.440 problem with the switch, it could be a problem with the access point, it could 118 07:54.440 --> 07:57.000 even be a problem with our authentication server. 119 07:57.000 --> 08:02.870 And so how quickly can identify issues and for that matter, could we have been WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 119 07:57.000 --> 08:02.870 And so how quickly can identify issues and for that matter, could we have been 120 08:02.870 --> 08:08.000 more proactive in identifying that an issue was going to occur? 121 08:08.000 --> 08:12.420 Maybe we saw that we were running out of bandwidth or maybe we could have seen 122 08:12.420 --> 08:16.000 we were running out of bandwidth on a particular uplink. 123 08:16.000 --> 08:20.750 It's been that way for months and all of a sudden today it's just completely 124 08:20.750 --> 08:26.030 slammed and we've lost network connectivity to a particular access closet. We 125 08:26.030 --> 08:27.000 really should have seen this coming and could have seen it coming. 126 08:27.000 --> 08:31.840 But because we're so busy with everything else, it's really hard to gain the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 126 08:27.000 --> 08:31.840 But because we're so busy with everything else, it's really hard to gain the 127 08:31.840 --> 08:37.000 network visibility required in order to be proactive in preventing issues. 128 08:37.000 --> 08:43.180 Now lastly and arguably the most important aspect in all of this comes back to 129 08:43.180 --> 08:48.600 network security. These days network security cannot be tacked on to a network 130 08:48.600 --> 08:49.000 design. 131 08:49.000 --> 08:54.670 It must be foundationally deployed. We need it in the architecture and in the 132 08:54.670 --> 08:57.000 design from the very beginning. 133 08:57.000 --> 09:10.040 So how do we do that in a local area network type of environment? Well WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 08:57.000 --> 09:10.040 So how do we do that in a local area network type of environment? Well 134 09:10.040 --> 09:10.740 typically we're performing network segmentation for the sake of access control, 135 09:10.740 --> 09:11.000 which is a decent policy. 136 09:11.000 --> 09:15.540 Access control is going to define for us how many devices can talk to what 137 09:15.540 --> 09:20.000 other devices or which devices can communicate with which devices. 138 09:20.000 --> 09:27.000 And typically we're going to perform access control via access control lists. 139 09:27.000 --> 09:30.730 What we're doing access control list get applied access control list gets get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 139 09:27.000 --> 09:30.730 What we're doing access control list get applied access control list gets get 140 09:30.730 --> 09:37.370 applied on a usually an SVI of VLAN interface, which means that this is VLAN 141 09:37.370 --> 09:39.000 based segmentation. 142 09:39.000 --> 09:44.840 And this works well enough in a lot of cases, but it's not particularly 143 09:44.840 --> 09:50.840 granular. I think about it. If we've got a switch here with two SVI's and this 144 09:50.840 --> 09:55.000 SVI connects to this VLAN and this SVI connects to this VLAN. 145 09:55.000 --> 10:01.710 Well at this point my segmentation exists here at the SVI level, meaning that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 09:55.000 --> 10:01.710 Well at this point my segmentation exists here at the SVI level, meaning that 146 10:01.710 --> 10:08.220 if I try to go from this host on one subnet to this host on the other subnet, I 147 10:08.220 --> 10:13.300 can put policy at the SVI's to prevent this and say no that traffic is not 148 10:13.300 --> 10:14.000 allowed. 149 10:14.000 --> 10:19.040 But what if this host here wants to communicate to this host over here? Well 150 10:19.040 --> 10:23.930 logically it looks like they don't hit the switch, but physically these are 151 10:23.930 --> 10:29.990 both attached to physical switch ports. They're both going to hit this switch 152 10:29.990 --> 10:35.700 and yet they're not going to communicate through the SVI because we don't need WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 10:29.990 --> 10:35.700 and yet they're not going to communicate through the SVI because we don't need 153 10:35.700 --> 10:36.000 to route. 154 10:36.000 --> 10:40.690 And because of that we have to get into the complexity of VLAN access control 155 10:40.690 --> 10:45.680 lists, which don't particularly migrate well. And so our segmentation is not 156 10:45.680 --> 10:49.000 only VLAN based, but it's also very static. 157 10:49.000 --> 10:54.660 We're hoping our devices don't move around and for that matter again the 158 10:54.660 --> 10:57.000 granularity is a concern. 159 10:57.000 --> 11:02.070 So we have a lot of challenges and a lot of issues within our traditional WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 159 10:57.000 --> 11:02.070 So we have a lot of challenges and a lot of issues within our traditional 160 11:02.070 --> 11:07.750 network constructs and some of the questions we can ask for example, why are we 161 11:07.750 --> 11:11.000 relying on spanning tree protocol in this day and age. 162 11:11.000 --> 11:14.490 We should have something better than layer two loops in spanning tree protocol, 163 11:14.490 --> 11:16.000 kind of keeping us all together. 164 11:16.000 --> 11:19.940 We also want to know about the fact that we have to manage our devices 165 11:19.940 --> 11:25.000 individually and we've got configuration sprawl and trying to manage all this. 166 11:25.000 --> 11:29.990 Why can't I have one click in an interface that says, check all of my switches, 167 11:29.990 --> 11:32.790 make sure they're all running the right version of code and if they're not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 11:29.990 --> 11:32.790 make sure they're all running the right version of code and if they're not 168 11:32.790 --> 11:34.000 start to push those software upgrades. 169 11:34.000 --> 11:38.350 We also want to talk about these policies, QOS policies, security policies. I 170 11:38.350 --> 11:42.780 want these to be end to end and I want them to be extremely granular. If I say 171 11:42.780 --> 11:47.510 that I want two devices to not be able to talk to each other, well those two 172 11:47.510 --> 11:52.000 devices should not be able to talk to each other and it shouldn't require me to 173 11:52.000 --> 11:55.000 completely redefine my VLAN architecture in order to make that happen. 174 11:55.000 --> 11:59.520 There are so many different questions we can ask and that doesn't even cover 175 11:59.520 --> 12:03.970 half of what we've just talked about here but we do see that the traditional WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 11:59.520 --> 12:03.970 half of what we've just talked about here but we do see that the traditional 176 12:03.970 --> 12:08.000 way of building out our networks is not ideal in the modern era. 177 12:08.000 --> 12:12.210 We need something that can address these challenges and give us a better way of 178 12:12.210 --> 12:13.000 doing things. 179 12:13.000 --> 12:17.440 Naturally we are leading to a conversation around software to find access and 180 12:17.440 --> 12:21.630 Cisco is making the claim that software to find access is going to be able to 181 12:21.630 --> 12:24.000 solve all of these problems for us. 182 12:24.000 --> 12:27.830 As we continue through this conversation hopefully we're going to start to see 183 12:27.830 --> 12:30.000 some of these problems getting addressed.