WEBVTT 1 00:00.000 --> 00:03.850 And to really appreciate the idea of an IP SLA, let me start off with a true 2 00:03.850 --> 00:04.160 story, 3 00:04.160 --> 00:08.400 if something happened to me, a long, long time ago, back, I won't say what year 4 00:08.400 --> 00:09.200 it was, but a long, 5 00:09.200 --> 00:13.480 long time ago at Paramount Pictures, we had an application that was written by 6 00:13.480 --> 00:14.560 our developers 7 00:14.560 --> 00:18.080 that some of the executives at Paramount Pictures used. So let's imagine this 8 00:18.080 --> 00:19.440 is the computer 9 00:19.440 --> 00:22.960 where the executive sat, and when they clicked a button to build a table, 10 00:22.960 --> 00:23.440 actually, they just 11 00:23.440 --> 00:27.250 clicked a button for some function. And what happened in the background, there 12 00:27.250 --> 00:28.160 was a server 13 00:28.160 --> 00:32.880 that was being used, and it was actually calling upon a SQL server, a database, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 13 00:28.160 --> 00:32.880 that was being used, and it was actually calling upon a SQL server, a database, 14 00:32.880 --> 00:33.520 to go ahead and 15 00:33.520 --> 00:37.580 collect the data, and then return it to the client, and then fill the graph or 16 00:37.580 --> 00:38.960 complete the table 17 00:38.960 --> 00:43.620 at the desktop of the user. Now, unfortunately, when the user clicked on that 18 00:43.620 --> 00:44.640 one little item that 19 00:44.640 --> 00:48.550 caused that to happen, it took like 60 seconds. Now I'm rounding it there was 20 00:48.550 --> 00:49.680 close to 60 seconds, 21 00:49.680 --> 00:53.750 which is for anything pretty much, that's an eternity when somebody clicks a 22 00:53.750 --> 00:54.320 button and they 23 00:54.320 --> 00:57.580 have to wait 60 seconds for it to populate the table. And so what the 24 00:57.580 --> 00:58.880 developers team came back 25 00:58.880 --> 01:03.840 and said, well, it's a split. There's 20 seconds that the application is taking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 25 00:58.880 --> 01:03.840 and said, well, it's a split. There's 20 seconds that the application is taking 26 01:03.840 --> 01:04.800 here to actually do 27 01:04.800 --> 01:08.560 the crunching there locally. There's 20 seconds that's being used for the 28 01:08.560 --> 01:09.520 network to deliver the 29 01:09.520 --> 01:13.870 traffic, which even decades ago, it wouldn't have been that long for moving 30 01:13.870 --> 01:15.120 data across the network. 31 01:15.120 --> 01:18.430 And at the point of time, this was happening in my experience, the network 32 01:18.430 --> 01:19.920 traffic was above 10 33 01:19.920 --> 01:23.590 megabits per second. So it wasn't the network taking 20 seconds just to move 34 01:23.590 --> 01:24.480 the data. And then 35 01:24.480 --> 01:27.950 they said it was another 20 seconds on the back end for the SQL server to 36 01:27.950 --> 01:29.120 actually do the queries 37 01:29.120 --> 01:35.150 and so forth. Now that was just a complete wild guess. And it was unfortunately WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 37 01:29.120 --> 01:35.150 and so forth. Now that was just a complete wild guess. And it was unfortunately 38 01:35.150 --> 01:36.080 , most of the burden 39 01:36.080 --> 01:40.640 was on me because my team was responsible for the SQL server on the back end. 40 01:40.640 --> 01:41.760 And also the network 41 01:41.760 --> 01:46.440 and the developers were just responsible for the application. So put app, net, 42 01:46.440 --> 01:47.600 and SQL. So one of 43 01:47.600 --> 01:51.370 the first things we wanted to do is to actually validate where is the actual 44 01:51.370 --> 01:52.960 delay. So we did was 45 01:52.960 --> 01:56.910 after hours, we actually wrote a little script, and that little script had a 46 01:56.910 --> 01:58.160 bunch of SQL statements 47 01:58.160 --> 02:01.990 in it. So it'd go ahead and create a timestamp. And we write that timestamp to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 47 01:58.160 --> 02:01.990 in it. So it'd go ahead and create a timestamp. And we write that timestamp to 48 02:01.990 --> 02:02.880 a network drive, 49 02:02.880 --> 02:05.750 then it will do several of the SQL requests, the ones that were being done by 50 02:05.750 --> 02:06.560 the app. And then 51 02:06.560 --> 02:09.520 it would go ahead and after that was done, and make a timestamp and write that 52 02:09.520 --> 02:10.160 to disk. And then 53 02:10.160 --> 02:14.600 we'll go ahead and repeat that. So we had a central database from like five or 54 02:14.600 --> 02:15.520 10 machines 55 02:15.520 --> 02:19.110 that were all running this over and over and over again to actually collect the 56 02:19.110 --> 02:19.760 timestamps. 57 02:19.760 --> 02:24.640 And as it turned out, the time it took for the actual queries to be made, the 58 02:24.640 --> 02:25.440 responses to come 59 02:25.440 --> 02:30.050 back was about nine seconds, which is still quite a bit of time. But the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 02:25.440 --> 02:30.050 back was about nine seconds, which is still quite a bit of time. But the 60 02:30.050 --> 02:31.120 development team said, 61 02:31.120 --> 02:34.320 Oh, it's 40 seconds for the network of the SQL server, went in reality. It was 62 02:34.320 --> 02:35.360 about nine seconds 63 02:35.360 --> 02:38.910 for that whole back end of all the transport across. But we had to prove that 64 02:38.910 --> 02:39.520 by doing some 65 02:39.520 --> 02:43.040 testing. So after we came back with that information and had it clearly 66 02:43.040 --> 02:43.760 documented, 67 02:43.760 --> 02:47.920 the developer team then took a look at their coding and said, Oh, we can 68 02:47.920 --> 02:48.640 revisit this and 69 02:48.640 --> 02:53.020 change that. And they got the whole thing down to about 13 seconds. Now it's 70 02:53.020 --> 02:53.680 still in today's 71 02:53.680 --> 02:57.850 standards, 13 seconds after you click on something that's an eternity. But it's 72 02:57.850 --> 02:58.960 a lot less than the 73 02:58.960 --> 03:03.910 60 seconds. And to come back to our point here, if we have to prove that our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 02:58.960 --> 03:03.910 60 seconds. And to come back to our point here, if we have to prove that our 74 03:03.910 --> 03:05.120 network and our devices 75 03:05.120 --> 03:08.580 are behaving in a certain fashion, we have to have some mechanism for doing 76 03:08.580 --> 03:09.920 that. So back at Paramount 77 03:09.920 --> 03:14.320 Pictures, we created some batch files and ran them to build our documentation 78 03:14.320 --> 03:15.600 about the time it took 79 03:15.600 --> 03:19.760 for the SQL server on the network. And we can use IP SLAs IP service level 80 03:19.760 --> 03:20.960 groups today for the 81 03:20.960 --> 03:24.300 testing and measurement of our data as it goes across the network. So let me 82 03:24.300 --> 03:25.200 clean this up a little 83 03:25.200 --> 03:31.850 bit and let's chat about what we can do on a Cisco network to implement IP SLAs WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 83 03:25.200 --> 03:31.850 bit and let's chat about what we can do on a Cisco network to implement IP SLAs 84 03:31.850 --> 03:32.800 . One of the cool 85 03:32.800 --> 03:37.020 things is we can specify that some device in the network will be a responder. 86 03:37.020 --> 03:37.920 For example, 87 03:37.920 --> 03:41.600 let's say we want our eight to be able to respond to any probes that we send 88 03:41.600 --> 03:42.880 across the network and 89 03:42.880 --> 03:46.260 feed that information back. And when we set that up on our eight to make it 90 03:46.260 --> 03:47.280 willing to respond, 91 03:47.280 --> 03:52.720 we do that with the command IP space SLA space responder, just like that. So we 92 03:52.720 --> 03:53.200 just do that in 93 03:53.200 --> 03:57.070 global config. And that makes our eight willing to respond. Now some devices, 94 03:57.070 --> 03:57.760 if we just do like 95 03:57.760 --> 04:01.270 a ping test, they'll respond to that without any type of configuration. But for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 95 03:57.760 --> 04:01.270 a ping test, they'll respond to that without any type of configuration. But for 96 04:01.270 --> 04:02.000 some of the 97 04:02.000 --> 04:06.710 advanced and more detailed information we want to get from SLAs, if we use the 98 04:06.710 --> 04:07.760 IP SLA responder 99 04:07.760 --> 04:12.020 feature on a Cisco router, because the functionality once we enable the feature 100 04:12.020 --> 04:13.120 is built in, we don't 101 04:13.120 --> 04:16.480 have to add any other devices to our network. We can have our existing 102 04:16.480 --> 04:17.760 infrastructure act as 103 04:17.760 --> 04:21.760 responders. So for the IP SLA responder, let's go ahead and specify that as a 104 04:21.760 --> 04:22.720 target. And then what 105 04:22.720 --> 04:26.820 we do is we specify some other device or devices in our network to act as the 106 04:26.820 --> 04:28.000 probes where they're 107 04:28.000 --> 04:32.590 sending out information requests to that responder. So maybe our eight is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 107 04:28.000 --> 04:32.590 sending out information requests to that responder. So maybe our eight is the 108 04:32.590 --> 04:33.920 responder, and maybe 109 04:33.920 --> 04:39.160 we use our one as a probe that sends out requests to the responder. So our next 110 04:39.160 --> 04:39.920 question might be, 111 04:39.920 --> 04:43.580 well, what exactly are the types of things we can measure and get information 112 04:43.580 --> 04:44.400 on regarding our 113 04:44.400 --> 04:48.760 network? Well, here's a few we can measure delay. So if we want to measure 114 04:48.760 --> 04:49.840 delay in our network, 115 04:49.840 --> 04:52.490 or if we have a service level agreement says, you know what, we want to make 116 04:52.490 --> 04:53.680 sure that the round 117 04:53.680 --> 04:57.750 trip time is anywhere above 100 milliseconds, we want to have that considered 118 04:57.750 --> 04:58.800 out of the threshold, 119 04:58.800 --> 05:03.070 meaning out of bounds or above what we want, then we can set up a probe that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 119 04:58.800 --> 05:03.070 meaning out of bounds or above what we want, then we can set up a probe that's 120 05:03.070 --> 05:03.680 sitting traffic down 121 05:03.680 --> 05:07.730 the responder, measuring the response back either from that device directly, or 122 05:07.730 --> 05:08.480 we can measure the 123 05:08.480 --> 05:12.380 entire path response. And assuming that target is reachable, and the delay is 124 05:12.380 --> 05:14.160 less than 100 milliseconds, 125 05:14.160 --> 05:19.220 that would be considered within scope or within the IP SLA. Or if the delay is 126 05:19.220 --> 05:20.560 more than 100 milliseconds, 127 05:20.560 --> 05:24.240 the SLA can measure that and say, whoa, this is outside of the threshold. And 128 05:24.240 --> 05:24.560 then we can use 129 05:24.560 --> 05:28.870 other tools like S&P and network management tools to keep track of that. And 130 05:28.870 --> 05:30.160 based on a problem or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 05:28.870 --> 05:30.160 based on a problem or 131 05:30.160 --> 05:34.060 an issue allows to go ahead and address it. So besides delay, what else can we 132 05:34.060 --> 05:35.200 measure with IP 133 05:35.200 --> 05:40.320 SLAs? Another important factor for many applications is jitter. Now, I think, 134 05:40.320 --> 05:41.040 well, what's the difference 135 05:41.040 --> 05:44.600 key between jitter and delay? And when I think of jitter, I think of it as 136 05:44.600 --> 05:46.560 variation regarding delay, 137 05:46.560 --> 05:50.410 another way of saying delay is latency. So for example, if some of our packets 138 05:50.410 --> 05:51.360 are coming in with 139 05:51.360 --> 05:56.680 50 millisecond delay, and others are coming in with 160 millisecond delay, and 140 05:56.680 --> 05:57.280 others are coming in 141 05:57.280 --> 06:00.610 with 20 millisecond delay, for some applications like email, that doesn't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 141 05:57.280 --> 06:00.610 with 20 millisecond delay, for some applications like email, that doesn't 142 06:00.610 --> 06:01.680 matter at all. But if 143 06:01.680 --> 06:06.420 we have a real time application like voice over IP, or some real time video, 144 06:06.420 --> 06:07.280 that jitter, that 145 06:07.280 --> 06:12.550 variation in delay can wreak havoc on those types of applications. So we can 146 06:12.550 --> 06:13.680 set up a service level 147 06:13.680 --> 06:18.640 agreement probing and verifying what is the jitter and if it falls out of scope 148 06:18.640 --> 06:20.000 of what we needed to 149 06:20.000 --> 06:23.900 be, we can go ahead and be aware of it. Again, if we're either looking at the 150 06:23.900 --> 06:24.800 router during the 151 06:24.800 --> 06:28.460 probes, or if we have a network management system with S&P, we can have alerts 152 06:28.460 --> 06:29.360 indicating that 153 06:29.360 --> 06:33.960 there's a problem. Another popular but simple option is to look for packet loss WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 153 06:29.360 --> 06:33.960 there's a problem. Another popular but simple option is to look for packet loss 154 06:33.960 --> 06:34.880 . We can also 155 06:34.880 --> 06:39.630 analyze the path that's being taken and the delay based on each hop in the path 156 06:39.630 --> 06:40.720 . We can also 157 06:40.720 --> 06:44.790 measure web services. So if we have a web server down here, and we want to 158 06:44.790 --> 06:46.640 verify the delay between, 159 06:46.640 --> 06:50.330 for example, R1, the probe and the web server, we can test that as well. We can 160 06:50.330 --> 06:51.200 also test for 161 06:51.200 --> 06:56.050 DHCP services. So if we have a DHCP server, and all of a sudden it's no longer 162 06:56.050 --> 06:57.040 in scope or it's no 163 06:57.040 --> 07:01.850 longer available, we can become aware of that if we've set up DHCP probes as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 163 06:57.040 --> 07:01.850 longer available, we can become aware of that if we've set up DHCP probes as 164 07:01.850 --> 07:03.280 part of our IP SLAs. 165 07:03.280 --> 07:07.790 There's also an option to test DNS services. So if we have a DNS issue or 166 07:07.790 --> 07:09.360 problem by doing probes 167 07:09.360 --> 07:12.610 with IP SLAs, if the DNS service is no longer available or is it working 168 07:12.610 --> 07:13.680 correctly, we can be 169 07:13.680 --> 07:18.740 aware of it. And with all of these, we can track these SLAs as well. So in the 170 07:18.740 --> 07:20.080 event that, for example, 171 07:20.080 --> 07:25.440 there's packet loss or non-reachability to a target, we can actually manipulate 172 07:25.440 --> 07:26.320 our routing or other 173 07:26.320 --> 07:29.930 parameters on the routers in conjunction with that. For example, let's say R3 174 07:29.930 --> 07:30.720 right here. Let's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 174 07:29.930 --> 07:30.720 right here. Let's 175 07:30.720 --> 07:34.580 imagine we have a default route that goes over to R4. So put 000, 000 there to 176 07:34.580 --> 07:35.440 represent a default 177 07:35.440 --> 07:40.260 route with the next top of 10, 0, about 34, 000. However, if R4 is not reach 178 07:40.260 --> 07:41.360 able, let's go ahead 179 07:41.360 --> 07:45.720 and imagine R4 has a loop back of 4.4.4.4, which it does. So what we could do 180 07:45.720 --> 07:46.720 is we could set up an 181 07:46.720 --> 07:50.870 IP SLA for reachability testing to verify that R3 can reach that loopback 182 07:50.870 --> 07:51.920 address. And we can make 183 07:51.920 --> 07:57.860 the default route conditional upon that SLA being mapped, meaning that 4444 is 184 07:57.860 --> 07:59.280 reachable. And should 185 07:59.280 --> 08:04.470 that 4444 not be reachable, we can go ahead and automatically remove that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 07:59.280 --> 08:04.470 that 4444 not be reachable, we can go ahead and automatically remove that 186 08:04.470 --> 08:06.400 default route from R3. 187 08:06.400 --> 08:10.480 And by using route maps and policy-based routing, we can basically track and 188 08:10.480 --> 08:11.760 manipulate the activities 189 08:11.760 --> 08:17.260 on the router based on the IPSLA coming back okay or coming back as failed. And 190 08:17.260 --> 08:18.560 in a reachability 191 08:18.560 --> 08:23.550 test, okay would mean I can reach 4444 and failed would mean I can't or in the 192 08:23.550 --> 08:24.800 concept of measuring 193 08:24.800 --> 08:28.730 jitter we can set a threshold. So if the threshold we specified were jitter is 194 08:28.730 --> 08:29.760 below a certain value, 195 08:29.760 --> 08:33.940 it'd be okay or if it's above that level it'd be considered failed. So here's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 195 08:29.760 --> 08:33.940 it'd be okay or if it's above that level it'd be considered failed. So here's 196 08:33.940 --> 08:34.560 what I propose 197 08:34.560 --> 08:38.380 to do in the next video. Let's put a quick high level game plan together 198 08:38.380 --> 08:39.520 regarding several options 199 08:39.520 --> 08:43.640 with IPSLA that we can implement. And then we'll take that game plan and we'll 200 08:43.640 --> 08:44.160 walk through it 201 08:44.160 --> 08:47.380 step by step and at the tail end of the set of videos, I'll put you on a hands- 202 08:47.380 --> 08:48.560 on lab so you too 203 08:48.560 --> 08:54.010 can get practice in configuring and verifying IP service level agreements. So I 204 08:54.010 --> 08:54.400 'll see you in the 205 08:54.400 --> 08:56.300 in the next video in just a moment.