WEBVTT 0:00:02.900000 --> 0:00:06.820000 Welcome to this video, when I'm going to go over the architectural elements 0:00:06.820000 --> 0:00:10.420000 of intent-based networking. 0:00:10.420000 --> 0:00:15.060000 That's what our topic is in this particular class. 0:00:15.060000 --> 0:00:21.620000 Let's do a quick recap here on what is intent-based networking. 0:00:21.620000 --> 0:00:26.380000 Remember that intent-based networking is this idea where something can 0:00:26.380000 --> 0:00:31.700000 happen like a new application can spin up, a new group of users can come 0:00:31.700000 --> 0:00:37.080000 online, the controller, the SDN controller becomes aware of this. 0:00:37.080000 --> 0:00:42.680000 It has some policy that says, oh, now that this thing has happened, this 0:00:42.680000 --> 0:00:49.500000 trigger event has happened, I want the network to act in this way. 0:00:49.500000 --> 0:00:54.360000 I want a new path created or a new QoS policy created, or some new security 0:00:54.360000 --> 0:00:56.020000 restrictions put in place. 0:00:56.020000 --> 0:01:02.760000 I want to convey my intent to the network. 0:01:02.760000 --> 0:01:06.980000 That is intent-based networking, where the network can dynamically change 0:01:06.980000 --> 0:01:11.940000 what it's doing based on new things coming online, like we're talking 0:01:11.940000 --> 0:01:16.740000 about here. That is the high -level conceptual idea. 0:01:16.740000 --> 0:01:20.080000 Now, what are all the elements, and that's what we're talking about here, 0:01:20.080000 --> 0:01:25.680000 what are all the elements required to fully get as close to that theory 0:01:25.680000 --> 0:01:28.520000 as possible, and that's what we're going to look at. 0:01:28.520000 --> 0:01:31.120000 So in order to get as close to that as possible, we need the following 0:01:31.120000 --> 0:01:33.000000 architectural elements. 0:01:33.000000 --> 0:01:39.140000 I'm going to go through each one of these in just a little bit of detail. 0:01:39.140000 --> 0:01:43.140000 So let's start with instrumentation. 0:01:43.140000 --> 0:01:48.360000 So instrumentation is just a fancy way of saying the collection of data. 0:01:48.360000 --> 0:01:51.820000 So the collection of all the nitty -gritty data that you would need to 0:01:51.820000 --> 0:01:58.180000 know what's going on in the network, from packets going through your interfaces, 0:01:58.180000 --> 0:02:02.300000 quantity of errors, what your CPUs are looking like, what kind of applications 0:02:02.300000 --> 0:02:05.940000 in your network, anything you can possibly think of that you'd want to 0:02:05.940000 --> 0:02:11.680000 know about your network, that is gathered in the instrumentation phase. 0:02:11.680000 --> 0:02:18.000000 So in this world, there are certain things which have been designed to 0:02:18.000000 --> 0:02:19.560000 facilitate this. 0:02:19.560000 --> 0:02:24.120000 So for example, the CalIS 9000 Switching family was designed with software 0:02:24.120000 --> 0:02:26.720000 defined networking in mind. 0:02:26.720000 --> 0:02:31.440000 It has a lot of things it can do, a lot of ways it can interact with controllers 0:02:31.440000 --> 0:02:35.400000 that other existing Cisco platforms couldn't do. 0:02:35.400000 --> 0:02:39.220000 For example, one of the things that's kind of unique to this 9000 Switching 0:02:39.220000 --> 0:02:43.720000 platform is it has a really specialized ASIC called the Unified Access 0:02:43.720000 --> 0:02:47.340000 Dataplane 2.0 ASIC. 0:02:47.340000 --> 0:02:48.640000 What's neat about this? 0:02:48.640000 --> 0:02:56.020000 Well, this ASIC is amazing in the quantity and granularity of data that 0:02:56.020000 --> 0:02:57.840000 it can actually capture. 0:02:57.840000 --> 0:03:02.560000 For example, I have some notes here that says that it can support 384 0:03:02.560000 --> 0:03:06.820000 ,000. Let me just write that down there. 0:03:06.820000 --> 0:03:16.440000 384,000 flexible counters, which can instrument, once again, that's talking 0:03:16.440000 --> 0:03:20.740000 about collecting data, virtually any event that happens in that ship. 0:03:20.740000 --> 0:03:30.800000 It can collect up to 128 ,000 net flow records. 0:03:30.800000 --> 0:03:38.080000 So that UADP chip can really facilitate an instrumentation in how low 0:03:38.080000 --> 0:03:43.920000 level it can get and the quantity of information it can soak up and obtain. 0:03:43.920000 --> 0:03:49.100000 Now, in addition to that, not only do we want to have information or instrumentation 0:03:49.100000 --> 0:03:53.320000 about what's going on in the network, wouldn't it be nice if we could 0:03:53.320000 --> 0:03:57.180000 get some instrumentation data off of our clients that are actually connecting 0:03:57.180000 --> 0:04:02.660000 to the network? Well, there is something called client instrumentation. 0:04:02.660000 --> 0:04:08.780000 For example, we're talking about Apple devices, iOS devices like iPhones, 0:04:08.780000 --> 0:04:13.740000 iPads, Macbooks, things of that neat. 0:04:13.740000 --> 0:04:19.300000 Well, Macbooks don't use iOS, but things that use iOS, well, Apple devices 0:04:19.300000 --> 0:04:22.900000 can actually integrate with Cisco DNA Center. 0:04:22.900000 --> 0:04:28.080000 They can actually provide information about the network. 0:04:28.080000 --> 0:04:30.980000 They can provide, for example, information about what access points they 0:04:30.980000 --> 0:04:35.260000 have visibility to, as well as the signal levels and noise ratios. 0:04:35.260000 --> 0:04:39.780000 They can provide information about why they left the network, why they 0:04:39.780000 --> 0:04:43.360000 disassociated. For example, did they go idle? 0:04:43.360000 --> 0:04:47.820000 So Apple and iOS can provide even more information. 0:04:47.820000 --> 0:04:51.300000 And then you also have sensors such as the Aeronet Wireless Sensor. 0:04:51.300000 --> 0:04:52.420000 This is an example right here. 0:04:52.420000 --> 0:04:57.840000 This is graphic that you see is an example of an Aeronet Wireless Sensor. 0:04:57.840000 --> 0:05:00.340000 And this can be deployed throughout the enterprise. 0:05:00.340000 --> 0:05:03.740000 You can see it just plugs into a wall socket, basically a wall jack, and 0:05:03.740000 --> 0:05:07.920000 reports on the onboarding experience and the availability and performance 0:05:07.920000 --> 0:05:09.660000 of networking services. 0:05:09.660000 --> 0:05:16.220000 It can report back on authentication, authorization, DHCP, DNS, how all 0:05:16.220000 --> 0:05:18.140000 that stuff is doing. 0:05:18.140000 --> 0:05:23.460000 So this can provide you all the, so this is the first part is instrumentation, 0:05:23.460000 --> 0:05:25.040000 gathering of the data. 0:05:25.040000 --> 0:05:30.560000 Now, data just in its pure raw format doesn't do much. 0:05:30.560000 --> 0:05:32.740000 It's overwhelming, it's uncorrelated. 0:05:32.740000 --> 0:05:35.160000 You don't know what the context is. 0:05:35.160000 --> 0:05:38.640000 So it helps to have something after you've done the instrumentation to 0:05:38.640000 --> 0:05:40.960000 make sense of this data. 0:05:40.960000 --> 0:05:46.080000 So the next architectural element we're going to talk about is on device 0:05:46.080000 --> 0:05:54.400000 analytics. So what's happening here is, once again, Cisco 9000 switches 0:05:54.400000 --> 0:05:58.500000 and some other Cisco hardware has the ability to collect all this data. 0:05:58.500000 --> 0:06:01.400000 And now on device analytics is making sense of it. 0:06:01.400000 --> 0:06:05.940000 Taking that data and then populating key performance indicators. 0:06:05.940000 --> 0:06:09.080000 Now key performance indicators are things that you program into the device. 0:06:09.080000 --> 0:06:10.500000 What's important to you? 0:06:10.500000 --> 0:06:11.940000 What do you want to see? 0:06:11.940000 --> 0:06:14.780000 Maybe you want a key performance indicator created on the device that's 0:06:14.780000 --> 0:06:18.620000 measuring the CPU usage, that's measuring the total packets through a 0:06:18.620000 --> 0:06:19.820000 particular interface. 0:06:19.820000 --> 0:06:23.240000 Whatever is important to you, you tell that device what the key performance 0:06:23.240000 --> 0:06:27.880000 indicator is, and then on device analytics will take all the raw data 0:06:27.880000 --> 0:06:31.420000 that was captured during instrumentation. 0:06:31.420000 --> 0:06:34.760000 And populate your KPIs. 0:06:34.760000 --> 0:06:36.700000 So it prioritizes all this stuff. 0:06:36.700000 --> 0:06:42.060000 You see the idea is, if we just took this massive quantity of data that's 0:06:42.060000 --> 0:06:46.520000 being gathered during the instrumentation phase and sent all of that to 0:06:46.520000 --> 0:06:49.240000 the controller, it would overwhelm the controller. 0:06:49.240000 --> 0:06:52.700000 It's too much data, so much of it is stuff that you probably don't even 0:06:52.700000 --> 0:06:58.200000 care about. So on device analytics says, hey, let's just collect, well, 0:06:58.200000 --> 0:07:01.040000 we're going to collect everything during instrumentation, but now let's 0:07:01.040000 --> 0:07:05.480000 just have stuff ready that's of real interest to us. 0:07:05.480000 --> 0:07:13.360000 Okay, so the next step is now we've gathered all this massive data during 0:07:13.360000 --> 0:07:14.580000 instrumentation. 0:07:14.580000 --> 0:07:19.120000 We've prioritized it and sort of formatted it during the on device analytics. 0:07:19.120000 --> 0:07:22.900000 Now we need to get that information, the relevant stuff, the important 0:07:22.900000 --> 0:07:27.920000 stuff, over to the controller so our GUI can display it so we can see 0:07:27.920000 --> 0:07:29.140000 what's going on. 0:07:29.140000 --> 0:07:34.920000 So that process is called telemetry, getting data off the box and over 0:07:34.920000 --> 0:07:39.240000 to the server. Now, what are some legacy forms of telemetry? 0:07:39.240000 --> 0:07:42.420000 Because after all, for a long time, we've had servers that have received 0:07:42.420000 --> 0:07:45.220000 data from the network. 0:07:45.220000 --> 0:07:51.380000 For example, SNMP managers, right, received SMP traps, or maybe they pulled 0:07:51.380000 --> 0:07:57.360000 the SNMP agent to collect the data. 0:07:57.360000 --> 0:08:01.680000 Cyslog messages or Cyslog servers, NetFlow collectors. 0:08:01.680000 --> 0:08:06.940000 So these were all methods of getting data, but a lot of this stuff doesn't 0:08:06.940000 --> 0:08:13.460000 really work in an intent-based networking approach because the quantity 0:08:13.460000 --> 0:08:17.440000 information we want to receive on the controller, the controller has to 0:08:17.440000 --> 0:08:21.580000 have visibility to pretty much almost everything that's going on in the 0:08:21.580000 --> 0:08:25.820000 network so it can make intelligent decisions as far as what it displays 0:08:25.820000 --> 0:08:30.800000 to you on the GUI so it can implement policies dynamically that you've 0:08:30.800000 --> 0:08:33.680000 already pre-configured and pre-provisioned. 0:08:33.680000 --> 0:08:38.920000 And these methods here, SNMP, Cyslog, NetFlow, some of those methods only 0:08:38.920000 --> 0:08:40.880000 worked when you pulled the device. 0:08:40.880000 --> 0:08:43.500000 You pull the device, you get the data, well, by that point in time, it 0:08:43.500000 --> 0:08:44.800000 might be too late. 0:08:44.800000 --> 0:08:47.620000 Some of this data we want to see instantly as it happens. 0:08:47.620000 --> 0:08:48.740000 We don't want to pull it. 0:08:48.740000 --> 0:08:51.340000 So some of these polling mechanisms don't work. 0:08:51.340000 --> 0:08:56.820000 Other mechanisms like Cyslog, which dynamically report stuff to you, might 0:08:56.820000 --> 0:09:00.400000 not give you the level of granularity that you're looking for, might not 0:09:00.400000 --> 0:09:03.780000 give you what you want or in some cases might give you more stuff than 0:09:03.780000 --> 0:09:05.580000 you really care to see. 0:09:05.580000 --> 0:09:11.200000 So the DNA center approach for telemetry is something called model-based 0:09:11.200000 --> 0:09:13.880000 streaming telemetry. 0:09:13.880000 --> 0:09:18.880000 What is that? Well, model-based streaming telemetry just basically means 0:09:18.880000 --> 0:09:24.960000 that the devices in your fabric, your switches, your routers, are going 0:09:24.960000 --> 0:09:28.960000 to stream the data as it happens as they create these key performance 0:09:28.960000 --> 0:09:32.880000 indicators that they have created in their on-device analytics. 0:09:32.880000 --> 0:09:36.760000 As that stuff has been populated, they will establish TCP connections 0:09:36.760000 --> 0:09:43.960000 to the controller and over those TCP connections using HTTP, using something 0:09:43.960000 --> 0:09:54.360000 called GRPC, which will stream that data directly to the controller. 0:09:54.360000 --> 0:09:59.420000 So data is pushed from the device at any time and individual metrics can 0:09:59.420000 --> 0:10:00.600000 be streamed to the collector. 0:10:00.600000 --> 0:10:04.080000 The collector in this particular case being your DNA center controller 0:10:04.080000 --> 0:10:07.360000 or whatever controller you have. 0:10:07.360000 --> 0:10:10.920000 And then the next component is, well, this controller is getting tons 0:10:10.920000 --> 0:10:13.540000 of data. We need storage. 0:10:13.540000 --> 0:10:17.340000 As we can see here, networks and hosts can generate over one terabyte 0:10:17.340000 --> 0:10:19.920000 of data every single day. 0:10:19.920000 --> 0:10:23.100000 We need to have some sort of scalable storage to store all that stuff 0:10:23.100000 --> 0:10:25.280000 so we can parse through it. 0:10:25.280000 --> 0:10:31.180000 Now from a terminology standpoint, there's three basic ways you can do 0:10:31.180000 --> 0:10:32.520000 scalable storage. 0:10:32.520000 --> 0:10:34.860000 You can do a centralized collector. 0:10:34.860000 --> 0:10:41.180000 In other words, you can have one storage area network or one massive raid 0:10:41.180000 --> 0:10:43.800000 array or something which is collecting all your data. 0:10:43.800000 --> 0:10:47.340000 Now the nice thing about centralized collectors is they're very easy to 0:10:47.340000 --> 0:10:52.080000 deploy, very easy, but they're not very scalable. 0:10:52.080000 --> 0:10:55.920000 On the reverse side, you've got distributed collectors. 0:10:55.920000 --> 0:10:59.520000 Gives you great scalability because you can put them all over the place, 0:10:59.520000 --> 0:11:03.020000 but it's a lot more complex to integrate those. 0:11:03.020000 --> 0:11:07.520000 Or you can take a hybrid approach or you can do cloud-based. 0:11:07.520000 --> 0:11:10.800000 Cloud-based means your collectors, like it sounds, are in the cloud. 0:11:10.800000 --> 0:11:14.360000 This is the best of both worlds because it's typically easier to deploy 0:11:14.360000 --> 0:11:18.680000 than if you were to do your own distributed storage. 0:11:18.680000 --> 0:11:22.100000 It's very scalable. 0:11:22.100000 --> 0:11:24.780000 The only downside to this is it's going to cost you some money. 0:11:24.780000 --> 0:11:27.580000 There's going to be an additional expense from the cloud service provider 0:11:27.580000 --> 0:11:33.960000 to supply this. Now we've got our controller. 0:11:33.960000 --> 0:11:37.720000 Our controller data has been streamed to it via telemetry. 0:11:37.720000 --> 0:11:41.660000 The controller either has the storage on it itself or it's connected to 0:11:41.660000 --> 0:11:44.620000 some external storage that has access to. 0:11:44.620000 --> 0:11:49.660000 Now there needs to be something on the controller in the solution that 0:11:49.660000 --> 0:11:53.700000 can make sense of all this data because this is still massive quantities 0:11:53.700000 --> 0:11:59.380000 of data. We need something to be able to analyze it and put it in a human 0:11:59.380000 --> 0:12:07.380000 readable format, maybe color code it to something that is not required 0:12:07.380000 --> 0:12:13.500000 or identified. And so we need something called an analytics engine. 0:12:13.500000 --> 0:12:17.160000 So Cisco DNA Center provides analytics engines. 0:12:17.160000 --> 0:12:21.420000 It actually has the ability to correlate multiple sources of data that 0:12:21.420000 --> 0:12:25.620000 normally we'd have to query individually on a box-by-box basis. 0:12:25.620000 --> 0:12:28.340000 So it can also provide automated context. 0:12:28.340000 --> 0:12:32.680000 For example, it can tell you what device was experiencing an issue. 0:12:32.680000 --> 0:12:35.740000 What's the IP address and MAC address of the device? 0:12:35.740000 --> 0:12:38.900000 What's the security policy that was granted to that device? 0:12:38.900000 --> 0:12:40.760000 What department is in? 0:12:40.760000 --> 0:12:42.080000 What user is it? 0:12:42.080000 --> 0:12:44.080000 What security policy? 0:12:44.080000 --> 0:12:46.100000 Where is it supposed to go? 0:12:46.100000 --> 0:12:47.600000 Was it allowed to access? 0:12:47.600000 --> 0:12:49.260000 What is it not allowed to access? 0:12:49.260000 --> 0:12:51.500000 What's the network connection of the endpoint? 0:12:51.500000 --> 0:12:55.340000 Where is it? Tell me where it is geographically. 0:12:55.340000 --> 0:13:00.380000 So an analytics engine can take all the data and give you information 0:13:00.380000 --> 0:13:06.900000 like this. Now another component of intent-based networking is machine 0:13:06.900000 --> 0:13:10.720000 learning, troubleshooting, and remediation. 0:13:10.720000 --> 0:13:13.300000 And this is the last thing I'm going to talk about in this section. 0:13:13.300000 --> 0:13:17.660000 Machine learning is the ability to statistically learn from data without 0:13:17.660000 --> 0:13:23.460000 explicit programming. 0:13:23.460000 --> 0:13:30.280000 So within Cisco DNA Center, a component of it is NDP. 0:13:30.280000 --> 0:13:34.480000 The NDP is the analytics engine of Cisco DNA Center. 0:13:34.480000 --> 0:13:39.180000 And it actually has artificial intelligence and machine learning built 0:13:39.180000 --> 0:13:45.580000 into it. So it can not only recognize troubleshooting areas, it can recommend 0:13:45.580000 --> 0:13:48.840000 to you courses of action to the point where it says, would you like to 0:13:48.840000 --> 0:13:50.280000 do this to fix the problem? 0:13:50.280000 --> 0:13:53.500000 You click a button, the problem goes away. 0:13:53.500000 --> 0:13:57.200000 Or in some cases, you can even automate it to where once it spots a problem, 0:13:57.200000 --> 0:14:00.320000 it takes action all by itself. 0:14:00.320000 --> 0:14:06.440000 So if you have all of these elements in your solution, this gets you to 0:14:06.440000 --> 0:14:09.400000 intent-based networking. 0:14:09.400000 --> 0:14:11.540000 Thank you for watching this video. 0:14:11.540000 --> 0:14:12.680000 I hope it was useful to you.