WEBVTT 00:00:01.000 --> 00:00:10.000 Now it's time for discussion on IPSLA folks. So what is IPSLA in the world of Cisco? 00:00:10.000 --> 00:00:27.000 So IPSLA is a tool that is built into our Cisco iOS devices. And this tool gives us the ability to continuously monitor our various aspects of our network. 00:00:27.000 --> 00:00:34.000 In addition to monitoring, we can also measure the various aspects of our network. So what are some of these different aspects? 00:00:34.000 --> 00:00:53.000 Things like delay. Delay from one point to another point. So when you examine this picture here, you can see that we have a connection from ourselves at one site to another site over a service provider's environment. 00:00:54.000 --> 00:01:11.000 We have an agreement with our service provider. They provide us a service that meets certain levels, and we go ahead and we use that service. But if we don't measure that service continuously, we are not going to know if that service provider is actually providing the level of service that we're paying for. 00:01:12.000 --> 00:01:27.000 We can't just take their word for it. You know what I mean? So in the end, we need a way to continuously measure things so we know if we are getting the levels that we need to provide the levels of service that we need. 00:01:28.000 --> 00:01:40.000 So this is just one example of continuously measuring that environment to find out if we are getting what we're paying for. But there are many other reasons why we might want to use IPSLA. 00:01:41.000 --> 00:01:58.000 So things like measuring delay, or jitter, or packet loss, packet sequencing, the path that is being taken, or just simple connectivity from point A to point B, round trip times, voice quality scores. 00:01:58.000 --> 00:02:19.000 This is just a small, small example of what we could possibly do with IPSLA. IPSLA is massive, folks. And what we can do with it is astronomical. But for the certification exam, we have to stay focused, and we are going to focus on just what we need to know for this particular certification exam. 00:02:20.000 --> 00:02:39.000 So what is the purpose of IPSLA? Well, if we can continuously monitor and measure our environment, then we will have the ability to fine-tune that environment. So we'll have the ability to do things like increase productivity, lower operational costs, reduce the frequency of network outages. 00:02:39.000 --> 00:03:00.000 We'll be able to improve our troubleshooting capabilities. We'll be able to perform better problem analysis. And then in the end, we'll ultimately be designing better networks. So by constantly measuring what is going on, we'll have a better understanding of how the network is performing, and then we can tweak it to meet our needs. 00:03:01.000 --> 00:03:22.000 So with IPSLA, we're actually doing a type of active traffic monitoring, folks. Active traffic monitoring. What does that mean? It means we're sending out a probe, as we call it. What is the probe? Well, the probe is anything that you can ultimately create with IPSLA to mimic other types of traffic. 00:03:22.000 --> 00:03:49.000 So can I create a probe that mimics a voice packet? Sure. Can I create a probe that mimics a simple ping? Sure. Can I create a probe that mimics HTTP web traffic? Sure. So I can create various probes that mimic traffic types in my environment, and I can send these probes in a continuous, reliable, predictable manner. 00:03:49.000 --> 00:04:15.000 So that way there, I can gather measurements based on that. So think about your voice traffic. If I could send a probe continuously, repeatably, reliably, predictably, that is like a voice packet, and continuously measure, measure, measure, measure, then we know exactly how our network is performing when it comes to those voice packets. 00:04:16.000 --> 00:04:42.000 So if all of a sudden we see that, ooh, the round-trip time is not that good, or the one-way time is not that good, or the delay is not that good, or the jitter is not that good, and so on and so forth, we can fine-tune the environment. We might be able to find those deficiencies in the environment, like, oh, maybe we need to implement quality of service over here. So that way there, we can expedite, prioritize that traffic, that voice traffic to the front of the line. So that way there, it's not being held up by all that other TCP traffic that we have. 00:04:42.000 --> 00:05:00.000 So we have the ability to constantly measure and collect that information. We can store that in the memory of the CLI, but it's also findable or stored in the SNMP management information base as well. 00:05:01.000 --> 00:05:22.000 So when it comes to IPSLA, we have different operations that are supported. Now, not all operations are going to be supported on all Cisco products. Some Cisco products will support the set you see here. Some will support some more. Some will support less. So you won't be directly tested on, oh, which of the operational types are supported on a particular version of Cisco. 00:05:22.000 --> 00:05:38.000 But you'll see here that we can send out probes that mimic things like DHCP, DNS, ECHOs, FTPs, HTTP, Jitters, MPLS, JitterPath, ECHOs, PAP, Jitter, TCP Connects, UDP, ECHO. So we have all these various options available to us. 00:05:38.000 --> 00:06:05.000 And our focus is going to be on things like the Jitter aspect, the ECHO aspect for the certification exam. So for the certification exam, I'll give you some examples here based on things like testing a server's response time with an ICMP ECHO, testing network performance with UDP ECHO, failover for floating static routes, as well as monitoring the network for voice with UGP Jitter. So those are the things we are going to focus on to get ready for the certification exam. 00:06:05.000 --> 00:06:34.000 Now, something to keep in mind is that in the HSRP discussion, you would have had an example there where you were using a ping probe to test straight up simple connectivity, meaning if we are able to connect through this interface to that particular destination, then we are going to leave our priority of our HSRP device at a certain value. 00:06:34.000 --> 00:06:50.000 But if that ping fails, that probe fails, the SLA instance fails, the tracking object goes down, the tracking object goes down, we decrement our priority. If we decrement our priority enough, then we give up that active role and the standby device becomes active. 00:06:50.000 --> 00:07:02.000 So we already saw an example of how we could use the IPSLA in that particular scenario. So we'll add these ones now to our repertoire, our arsenal of information that we have to get ready for the certification exam. 00:07:02.000 --> 00:07:27.000 So the first thing we need to do is understand this terminology, IPSLA, IP Service Level Agreement Without Responder. That is kind of misleading, but that is how we say it. Without Responder simply means the device that's responding does not run IPSLA. That's all that means. 00:07:27.000 --> 00:07:46.000 So IPSLA Without Responder simply means that we are using probes that the device who responds to understands those probes natively. It doesn't need IPSLA running in order for it to respond. 00:07:46.000 --> 00:08:11.000 So something like a simple what? A simple ping, an echo, probe, all devices understand, an ICMP echo. So as a result of that, they can respond. So that is an example of IPSLA without a responder, simply meaning that I configure the source probe sends the probe. 00:08:11.000 --> 00:08:33.000 I don't have to do anything on the responder or the responding device, I should say, because it already understands what to do with it because it's a protocol, a service that already understands. It knows what to do with it so that it can respond back. So when we're talking about IPSLA Responder, we're setting up in a way that the device in question that we're probing already understands the type of probe that we are using. 00:08:33.000 --> 00:08:50.000 All right, so here's our environment we're going to play around with in this particular case as we do our examples. And so we are going to do some examples here. I'm going to do an example right now on DSW-1. We'll also do an example on R2. And this is going to be our target device over here in most of these examples. 00:08:50.000 --> 00:09:09.000 So the first one I want to do is just a simple probe to show you how we can measure, one, connectivity. Do we have connectivity? And the round-trip time of that connectivity. So we'll set up a probe here on DSW-1. That probe is going to go out here, go there, and then come back. 00:09:09.000 --> 00:09:31.000 And then we'll know what? We'll know whether we have connectivity, yes or no. And if we do have connectivity, then the question is, how long did it take to go from DSW-1 to the server and back? So this is a very simple example in this particular case because this example is going to be based on the fact that we're using ping. That's it. 00:09:32.000 --> 00:09:49.000 So let's go ahead and reach out to DSW-1 right now. And on DSW-1, we're going to type in configure terminal. And we'll type in, well, you know what, let's do a ping first. Let's make sure we can ping that device, 192.0.2.5. All right, we can. That's good. 00:09:49.000 --> 00:10:07.000 So actually, let's source that from the inside interface, so 10.40.12.1, so my SVI, 10.40.12.1. Let's do it from that IP address instead. And that works. So it's from our inside SVI all the way to that server and back. 00:10:08.000 --> 00:10:32.000 So now let's go ahead and type in IPSLA. And we give it a number. So as you can see, you get many SLA instances on your device. So IPSLA1. And then I'm going to hit enter. Now we are in IPSLA1 configuration mode. So the 1 is just a number, probe number 1. So I've got 2 probes, 3 probes, 4 probes. I just number them differently. 00:10:33.000 --> 00:10:51.000 Now what we're going to do is we're going to set up the probe. And in this case, we want to have an ICMP echo probe for our example. So it's a simple ping one. But you can see there's video operations, UDP jitter operations, UDP echo operations, path echo operations, HTTP, FTP, and so on and so forth on this device. ICMP echo in our example. 00:10:52.000 --> 00:11:16.000 Next, what is the destination IP address we want to ping? So I'm going to be 192.0.2.5. And then what is our source interface or source IP address? So I'm going to say the source IP address we're sending this probe from, as an example, 10.40.12.1. Because I just want to test roundtrip time and connectivity from that summit, that VLAN, that broadcast domain, as an example. 00:11:17.000 --> 00:11:32.000 All right. Now, how often are we going to do this? Let's say we want to do this every 5 seconds. That way there, I want to know every 5 seconds if that connection is up and running. And also, what is the roundtrip time every 5 seconds, so we know. 00:11:33.000 --> 00:11:51.000 All right. So something as simple as that. Now, what we're going to do is we are going to turn it on. So IPSLA schedule. And then you got to specify the entry number. So I'm going to specify entry number 1. And then now, you'll see that we have different options, age outs, life, recurring, start time. 00:11:51.000 --> 00:12:10.000 So, for example, you can schedule this to start every day at a certain time and then end every day at a certain time and just have this running maybe from 8 a.m. to 5 p.m. every day. Or you could have it running 24 hours a day, 7 days a week if you want to. 00:12:10.000 --> 00:12:31.000 So how you schedule it is determined by how often you need to get those measurements, when you need to get those measurements. So it's going to be variable in regards to every probe that you create, meaning you're going to customize your schedule for every single probe that you have. 00:12:32.000 --> 00:12:45.000 So I'm just going to type in here start time now, and I'm going to say life forever. But if I didn't say now, you'll see here start time. We can actually set up a schedule. 00:12:46.000 --> 00:13:01.000 So if I say now, it means start now. And in lifetime, you'll see you can specify how long it lasts for. Or I can say forever, which means it never expires until I manually shut it off. 00:13:02.000 --> 00:13:22.000 All right, so now the probe is running. So if we type in do show IPSLA configuration, you can see here that it tells us that our operation time out of milliseconds is 5,000. It's ICMP echo. There's the target address, the source address, any other type of parameters we specified, which we didn't specify any other types of parameters, but we can. 00:13:22.000 --> 00:13:38.000 For example, like a type of service parameter, a particular request size, a data pattern, and all that stuff can be done here. Then we got our thresholds and so on and so forth. All right, now I want to check to see if it's working. So it's show IPSLA statistics. 00:13:39.000 --> 00:13:54.000 And we'll see here that we have already sent eight probes. And the return status code is OK, meaning that everything is fine. We've had no failures at all. And you'll see here that our round trip time is one millisecond. 00:13:54.000 --> 00:14:14.000 Because there's not a whole lot of stuff going on in this environment. But that is an example of what? Verifying testing connectivity and figuring out the round trip time of that. So let's go ahead and just break it. So if we go here, we say interface loopback 192. 00:14:14.000 --> 00:14:33.000 I'm going to shut down that interface just to break that. So if we shut it down, we go back over to DSW1. And if we type in show IPSLA statistics, you're going to start to see some failures here. Why? Because the interface has gone down, which means the ping is not working anymore. 00:14:34.000 --> 00:14:55.000 So it says no connection, busy timeout, failure one. Failure two, because remember, we're pinging every five seconds. So every five seconds, we're getting an update. There you go. So let's go back here. Let's re enable the interface. 00:14:55.000 --> 00:15:16.000 And then we'll see here shortly that we start getting a round trip time back and our success to start going up there 18 with one millisecond again. Right. So perfect example of setting up a ping to test round trip time and testing basic connectivity. 00:15:17.000 --> 00:15:34.000 Now, let's talk about doing a floating static route. So one of the things we learn in CCNA is the concept of a floating static default route. And so, for example, on router number two, we'll set up a default route. 00:15:34.000 --> 00:15:50.000 Pointing to here, we'll set up a default route pointing to here, and then we'll set the administrative distance of this one, let's say, to seven. So that way, this is the primary route. This is the backup route. 00:15:51.000 --> 00:16:08.000 So this one's only going to be installed in the routing table if this one's no longer in the routing table for whatever reason. Typically, the reason for this one not being in the routing table is that the interface is down. Now, the only way that interface is going to go down is if something happens to this connection or somebody brings down the interface. 00:16:09.000 --> 00:16:26.000 The thing is, is most of the time, our networks are not going to have just a straight up cable from here to here from ourselves to our ISP. Why is that? Because there's going to be other layer one and layer two devices in between. Other layer one and layer two devices in between. 00:16:27.000 --> 00:16:47.000 What does that mean? It means that our status of up, up on the interface is based on this connection from here to here. So if there's a failure here or here or here or here, my interface is still up, up. So if my interface is still up, up, then my default route is still in my routing table using that interface, even though the connection is down. 00:16:48.000 --> 00:16:59.000 Because my interface is still up, up. So the default route is still in the routing table. Because that default route points to that particular interface using the next hop IP address. So it doesn't know that there's a problem further on down the line. 00:17:00.000 --> 00:17:25.000 So the backup path with the higher administrative distance is not going to be installed in the routing table because this default route is still in based on the fact the interface is up, up. So what we can do here is we can actually set up a probe. So if I set up a probe and we constantly ping, ping, ping, ping, ping from that interface out, if that ping ever fails, then we can have this removed out of the table. 00:17:26.000 --> 00:17:40.000 And then this one would be installed in the routing table instead. So that's what we're going to do here. We're going to set it up that way, where we have our primary path with an administrative distance of one. We have a secondary path with an administrative distance of seven. 00:17:40.000 --> 00:17:53.000 And then we're going to set up an IP SLA instance, followed by a tracking object. And then we're going to attach the tracking object to the IP route command. That's what we need to do here to get this to work. 00:17:54.000 --> 00:18:20.000 So over on R2, let's take a look to see what we have so far set up for our static routes. So run, pipe to section, IP route. We'll see here that we already have two specified in the table. So just to make this the same as our example, I'm going to take this one, I'm going to type a no, boom, break it, put it back in and change the administrative distance to seven. 00:18:21.000 --> 00:18:33.000 Because we set ADF seven for the secondary path. Now we type in do show run, pipe to section IP route. It equals what we have in our example up here. 00:18:34.000 --> 00:18:52.000 So our primary path goes through 203.01.13.89 because it has a lower administrative distance. Our secondary path goes through 192.02.241 with an administrative distance of seven. So if I type in do show IP route, we're going to see that the path through 203.01.13.89 is in the routing table. 00:18:53.000 --> 00:19:15.000 Let's go ahead now and just bring down the interface. So interface FastEthernet 0.0.0. So it's the interface for the primary route. We shut that down. What we're going to see is that that route gets removed from the routing table because that interface to get to that next top IP address is no longer available to use. 00:19:16.000 --> 00:19:25.000 So because that interface is no longer available to use to get to that next top IP address, the secondary route gets installed in the routing table. 00:19:26.000 --> 00:19:45.000 And then when the interface comes back up, then that primary path has the lower administrative distance and it's now usable because the interface is back up. So what happens, it gets installed. The primary path gets installed back in the routing table. 00:19:46.000 --> 00:19:55.000 So that's the basics here. But like I said, it's all dependent on that physical interface. So if we go to something like ISPA as an example, and I type in do show IP. 00:19:55.000 --> 00:20:24.000 All right. Let's go to R2 right now. And instead, let's do this right now. Let's do, if I ping, do ping 8.8.8.8 or no 192. Let's do 192.0.2.5. That work? Yes. Let's repeat that. 00:20:25.000 --> 00:20:42.000 Lots and lots and lots of times. Right. So it's working. Let's go over to ISPA right now. And what I'm going to do is I'm going to bring down interface VLAN1. I'm going to go ahead and shut it down. 00:20:42.000 --> 00:20:59.000 So if I bring down that interface, what's going to happen here on R2 is that we lose connectivity. Why are we losing connectivity? Because we don't have the ability to get to the next top IP address. 00:20:59.000 --> 00:21:19.000 The thing is the physical interface on R2 is still up up because we haven't affected the physical connection at all. The physical connection is still there. It's just that we have a problem in that environment. That's what I'm mimicking right now. There's a problem in that environment. But it doesn't affect my physical interface. 00:21:19.000 --> 00:21:41.000 So if we type in here, let me break that sequence. Do show IP route. You'll see that that path is still in the routing table. This is a problem we have right now that I'm going to try and solve with IPSLA and tracking. So what we're going to do now instead is we're going to set up our probe. 00:21:41.000 --> 00:22:00.000 So I'm going to bring this one back up. Go back to R2. All right, we're going to set up a probe now. And the probe, let's just do a ping again, make sure that everything's back up and running as it's supposed to. All right, it's working. So now I'm going to set up IPSLA. We'll call it SLA instance number one. 00:22:00.000 --> 00:22:29.000 And now I'm going to say ICMP echo. And in this particular case, let's ping some address. Let's just ping some address in the service provider's environment. So do ping 8.8.8.8. All right, so that IP address is there. So let's go ahead and just say let's ping the ISPs IP address 8.8.8.8. 00:22:29.000 --> 00:22:48.000 That's what we're going to do. So ICMP echo, destination address is 8.8.8.8. And the most important thing here is that the source IP address or the source interface, let's just say that's a better option here, is FastEthernet06060. 00:22:48.000 --> 00:23:12.000 I'm making sure that it's coming from this physical interface because I want to test it from that physical interface to that IP address. So I want to test the primary link. It's important to get that interface proper. All right, now I'm going to do that, for example, every five seconds. So that way there we can detect a failure within five seconds and transition over to the backup link within five seconds. 00:23:13.000 --> 00:23:36.000 I'm going to start that now. So IP SLA schedule for SLA instance number one that we're creating right here. And we're going to say start now, life forever. All right, so now let's take a look at do show IP SLA statistics and see if we're actually pinging successfully right now. And we are. 00:23:37.000 --> 00:23:56.000 So let's go ahead now and bring down, for example, this interface again. So bringing down this virtual interface is an example of having a failure somewhere here in the ISPs environment, but it doesn't affect our physical interface on R2. And you'll see that there's failures happening now. 00:23:57.000 --> 00:24:22.000 The ping is not reaching 8.8.8.8 anymore. So this is good, right? Why? Because I want to make sure that what we're doing is actually going to result in the outcome we're looking for. So I'm going to bring that interface back up, and we'll see here momentarily that those pings should start working again, and we should get a round trip. And there we go. So round trip, one millisecond, successful. All right, so we know that probe is working. It's accomplishing what we wanted to accomplish so far. 00:24:23.000 --> 00:24:45.000 But we still have to attach it to our static default route. That's what we need to do. So that way our static default route can be removed from the table when the probe goes down. Now, how do you do that? You need what is called a tracking object, an intermediary feature between IPSLA and the actual default route. 00:24:46.000 --> 00:25:11.000 So you create your tracking object by typing in track. Then you give it a number. So I'm going to give it number five here today for fun. And what do we want to track? We want to track the IPSLA probe. That's what we want to track. And what is the number of that probe? That was probe number one, if you remember. Okay, so put in probe number one there. And what do we want to track? We want to track the state of that probe. 00:25:12.000 --> 00:25:27.000 We could just hit Enter, and it would be perfectly fine. It would still work for us, but I'm going to pick state here. And that's it. We don't have to do any other aspects, any other features as to tracking object. I just want to track the state of it. So now what we're going to do is we're going to type in show track. 00:25:27.000 --> 00:25:55.000 When I type in show track, the result is that the state of IPSLA1 is up. So since the state of IPSLA1 is up or okay, then our tracking object is up. So I was reading that incorrectly. So IPSLA1 state right now is up. Yes, okay, I am reading it right. So IPSLA state is up. Why? Because our return code is okay. 00:25:55.000 --> 00:26:14.000 So since everything's good, that means our tracking object is a-okay. That's what that means. So now watch what happens, and I'm going to just show you again. If we shut down that interface, the probe fails. Watch what happens to our tracking object. So I'm showing you inch by inch what is happening with these different features. 00:26:14.000 --> 00:26:31.000 So with IPSLA statistics, we're going to start to see some failures. So now you're going to see the tracking object went down because the probe has failed. So if we look at track, it's down. So since we're down, that means the tracking object is down as well. 00:26:31.000 --> 00:26:57.000 So now that we have that, we can apply it to our default route. So what we're going to do is we're going to go now back to R2. I'm going to bring up the ISPs interface first. Let's go back to R2, and I'm going to type in do show run pipe to section IP route. Notice the tracking object has gone back up for us. 00:26:58.000 --> 00:27:21.000 Tracking object is back up. So what we're going to do is we're going to modify the primary route, the primary route. So I'm going to type in no and get rid of that primary route, and I'm going to put it back in. And now we're going to type in track, track, T-R-A-C-K. And what are we tracking? We're tracking that tracking object we created, which was object number five, tracking object number five. 00:27:22.000 --> 00:27:37.000 So what does this mean? Only put this route in the routing table if the tracking object is up and the IP address, the next hop IP address is reachable out of a physical interface. So now it's based on those two conditions. 00:27:37.000 --> 00:27:51.000 Is that next hop IP address reachable out of that interface? In this case, it's fast Ethernet 000 that gets to that next hop IP address and the tracking object is up. Both of those conditions must be true for that to go in the routing table. 00:27:52.000 --> 00:28:11.000 So now if we type in do show IP route, we're going to see that it is in the routing table, the next hop of .89. So that's the primary path. We type in do show track. We'll see the tracking object is up. The tracking object is attached to our static routing. 00:28:11.000 --> 00:28:31.000 And our IPSLA statistics, everything's good. So now let's just go ahead and bring down, make that virtual failure on our ISP side so we can see what's going to happen now. And this is what we want. This is what we've been waiting for. This is what we've configured all this for. 00:28:32.000 --> 00:28:58.000 We're going to see here eventually that R2 is going to give us a message, a syslog message that says, hey, tracking object is down. So when that happens, we now know what? We know that our probe has failed and our tracking object is down, which means that the static route should be removed from the routing table now because the tracking object is down. 00:28:58.000 --> 00:29:02.000 And the backup static route should be in the routing table. 00:29:05.000 --> 00:29:06.000 And it is. 00:29:11.000 --> 00:29:14.000 And so now we're using the backup path. 00:29:15.000 --> 00:29:17.000 If it comes back up that link. 00:29:19.000 --> 00:29:22.000 Eventually the ISP solves their problem as an example. 00:29:23.000 --> 00:29:27.000 Then what we should see here is that the ping starts to work again. 00:29:28.000 --> 00:29:40.000 The tracking object therefore goes up and therefore the primary default route can go back into the table. So tracking objects back up. Why? Because the pings working again. 00:29:40.000 --> 00:29:42.000 The tracking object is therefore OK and up. 00:29:43.000 --> 00:29:46.000 Therefore, in our routing table, we have our primary path back in. 00:29:48.000 --> 00:29:55.000 All right, so there's another example of using IPSLA without a responder. In this case, we're using this concept to. 00:29:56.000 --> 00:30:13.000 To improve the functionality of our floating static default route. So instead of the decision being purely solely on the status of the interface being up or not, now it's going to be based on the status of the interface being up or not. 00:30:13.000 --> 00:30:19.000 In addition to the tracking object being up or not, based on an IPSLA probe that is going out along that primary link. 00:30:19.000 --> 00:30:31.000 All right, so let's now talk about IPSLA with a responder. So a responder simply means that the device responding understands IPSLA. So it's going to be another Cisco device. 00:30:32.000 --> 00:30:35.000 So in order to have a responder, you need a Cisco device that understands IPSLA. 00:30:36.000 --> 00:30:42.000 So with IPSLA with a responder, essentially what happens is we have a control phase where we open the communication channel. 00:30:43.000 --> 00:30:51.000 And then from there, we can probe, respond, probe, respond, probe, respond back and forth. And why is this important? Because we have the ability to gather hyper accurate measurements. 00:30:52.000 --> 00:30:57.000 So any scenario that talks about you requiring hyper accurate measurements, you need to have a responder. 00:30:58.000 --> 00:31:04.000 Set up that understands IPSLA. So in this case, here's our source and here's our responder device. 00:31:04.000 --> 00:31:14.000 And then there are other devices in between. So what happens here now is that there are going to be timestamps that can be kept track of from here to here. 00:31:16.000 --> 00:31:22.000 And from here to here. And we have the ability to now take into account those timestamps. 00:31:23.000 --> 00:31:36.000 From here to here. And from here to here. And we have the ability to now take into account things like the processing that's going on as well. 00:31:37.000 --> 00:31:43.000 Because we can take into account the processing that's going on, we can get one way measurements now. 00:31:44.000 --> 00:31:50.000 Because this device, the source, can send the probe. The probe's processed. The probe's sent back. 00:31:51.000 --> 00:32:00.000 But because of the timestamps that are put in, this device now can measure one way measurements for latency, jitter, packet loss. 00:32:01.000 --> 00:32:03.000 Therefore, we get what? Hyper accurate measurements. 00:32:04.000 --> 00:32:18.000 So based on the fact now that we're keeping track of when we created it, when it was received, how long it took to process, when it was sent again, when it was received, how long it took to process, factor all those things in, do a little bit of subtraction, and the end result is what? 00:32:20.000 --> 00:32:25.000 One way timestamp and a one way timestamp in return. 00:32:26.000 --> 00:32:32.000 So things like UDP Echo can do this for us. UDP Jitter can do this for us. 00:32:33.000 --> 00:32:35.000 So let's talk about right now UDP Echo. 00:32:37.000 --> 00:32:53.000 So UDP Echo gives us the ability to measure end-to-end response times between a Cisco device and another device that has the ability to understand UDP messages. 00:32:54.000 --> 00:33:04.000 The thing is you don't need a responder, meaning you don't have to, with UDP Echo, have a responder. 00:33:05.000 --> 00:33:12.000 You could use UDP Echo and send it to another device because pretty much all devices out there understand UDP Echoes. 00:33:13.000 --> 00:33:25.000 But the thing is that you have the ability with UDP Echoes when you set up a responder, the ability to actually measure things like your delay. 00:33:32.000 --> 00:33:36.000 And then also inner packet delay variance. 00:33:36.000 --> 00:33:46.000 So with that in mind, you'll have the ability to get better measurements, more hyper-accurate measurements when you are using the responder with UDP Echo. 00:33:55.000 --> 00:33:59.000 So just by specifying UDP Echo, the destination IP address. 00:33:59.000 --> 00:34:13.000 Now in this case, I didn't put a source IP address or anything like that, but yes, you could put a source IP address there, source ports, destination ports, the frequency, all of that, even thresholds and other values. 00:34:14.000 --> 00:34:18.000 But like we said, we're just touching the surface of IPSLA to get you ready for the exam. 00:34:29.000 --> 00:34:31.000 Notice the configuration on the responder is pretty simple. 00:34:32.000 --> 00:34:33.000 IPSLA Responder. 00:34:34.000 --> 00:34:42.000 Now if you want to specify specific port numbers and specific protocols to respond with, then you can absolutely put that information in there as well. 00:34:43.000 --> 00:34:50.000 But in its basic sense, by typing in IPSLA Responder, default values can be used and you can get the responses back you need. 00:34:51.000 --> 00:34:53.000 Minimal configuration, as you can see, on the responder. 00:34:59.000 --> 00:35:14.000 But now, if you need to specifically target voice, as an example, UDP Echo is not the best option. 00:35:15.000 --> 00:35:19.000 You want to target real-time traffic, real-time applications. 00:35:20.000 --> 00:35:23.000 There's something better than UDP Echo, and that is UDP Jitter. 00:35:24.000 --> 00:35:34.000 So UDP Jitter can diagnose real-time traffic applications like voice over IP, video over IP, real-time conferencing applications and solutions. 00:35:35.000 --> 00:35:37.000 So what exactly does Jitter mean? 00:35:38.000 --> 00:35:43.000 If you don't know, Jitter means the inner packet delay variance. 00:35:44.000 --> 00:35:47.000 UDP Echo can give us kind of that, but not as good as UDP Jitter. 00:35:48.000 --> 00:36:00.000 So I always pick, I always go with, especially for a Cisco exam, any scenario that's talking about IPSLA, anything about voice, anything about video, anything about real-time conferencing, UDP Jitter is the way to go for that one. 00:36:05.000 --> 00:36:13.000 And if you don't know exactly what we mean by inner packet delay variance or Jitter, let me give you a little bit more information about that. 00:36:13.000 --> 00:36:16.000 So think about when packets are sent consecutively in order. 00:36:17.000 --> 00:36:19.000 So I send a packet, send a packet, send a packet, send a packet, so think voice. 00:36:20.000 --> 00:36:21.000 I send it, I send it, I send it, I send it. 00:36:22.000 --> 00:36:24.000 Okay, what is the best scenario for that? 00:36:25.000 --> 00:36:31.000 The best scenario is that we want the delay between those packets to be the exact same. 00:36:32.000 --> 00:36:33.000 We really do. 00:36:34.000 --> 00:36:37.000 I want the delay between every single voice packet, if I can, let's say to be 10 milliseconds. 00:36:38.000 --> 00:36:44.000 That way there, there's consistency for the receiving device. 00:36:45.000 --> 00:37:05.000 But if there's any variation in that delay, let's say one of those packets, the difference between one packet and another is 10, the difference between that packet and another is 12, the difference between that packet and another is 15, and then that one and that one is 10, and then that one and that one, right, that is what Jitter is, the variation in delay between those packets. 00:37:05.000 --> 00:37:11.000 And we really don't want a lot of Jitter, right? 00:37:12.000 --> 00:37:18.000 We want that ultimately to be zero if we can, so that way their delay between every single packet is the exact same. 00:37:19.000 --> 00:37:21.000 But it's not necessarily going to be that way for us in our environment. 00:37:22.000 --> 00:37:27.000 We strive for that using quality of service and different things like that, but it doesn't necessarily happen exactly like that for us. 00:37:28.000 --> 00:37:33.000 So we try to keep Jitter as low as possible, the variation in delay between voice packets. 00:37:33.000 --> 00:37:35.000 So the key here now is we want to measure that stuff. 00:37:36.000 --> 00:37:44.000 If we can constantly measure our environment for that, then we'll know if our environment is performing the way it needs to perform to accommodate that type of traffic. 00:37:45.000 --> 00:37:46.000 So UDP Jitter is great for what? 00:37:47.000 --> 00:37:51.000 Real-time voice over IP, video over IP, video conferencing. 00:37:53.000 --> 00:37:54.000 Because I can measure the network's performance. 00:37:55.000 --> 00:37:56.000 I can measure its delay. 00:37:57.000 --> 00:37:58.000 I can measure its Jitter. 00:37:59.000 --> 00:38:00.000 I can measure all of that stuff. 00:38:00.000 --> 00:38:04.000 So in this case, an example, there's UDP Jitter, the IP address, the port number. 00:38:05.000 --> 00:38:06.000 Again, you can do source port. 00:38:07.000 --> 00:38:08.000 You can do many options here. 00:38:09.000 --> 00:38:17.000 But to keep it simple for the exam, right, getting ourselves ready, UDP Jitter, destination, destination port. 00:38:18.000 --> 00:38:21.000 If you need a IP address source port, then you can put it in there as well. 00:38:22.000 --> 00:38:28.000 If not, the source port is just going to be randomly generated, and the source IP is whatever the exiting interface is for the probe. 00:38:28.000 --> 00:38:35.000 So if you don't specify the exiting IP address, then in the end, it's just whatever interface it goes out of based on the routing table information. 00:38:37.000 --> 00:38:39.000 So if you need to be specific, put in a source IP as well. 00:38:41.000 --> 00:38:43.000 And again, we started this one now, life forever. 00:38:44.000 --> 00:38:46.000 But the key here is to look at what we've got on the next few pages. 00:38:47.000 --> 00:38:49.000 In this case, we've got a UDP Jitter operation set up. 00:38:50.000 --> 00:38:51.000 So target address. 00:38:52.000 --> 00:38:55.000 And notice the source address ends up being 000 in this particular case, ending with a port. 00:38:56.000 --> 00:38:59.000 So it's whatever the IP address is when the probe gets sent out of an interface. 00:39:00.000 --> 00:39:05.000 That's the one that becomes a source and the destination, and the port will be whatever is generated by the device. 00:39:07.000 --> 00:39:10.000 Now, with IPSLA statistics, here's the cool stuff. 00:39:11.000 --> 00:39:13.000 You see, we've got our UDP Jitter operation. 00:39:14.000 --> 00:39:17.000 As you look down here, latency one way, one way. 00:39:18.000 --> 00:39:20.000 So UDP Jitter gives you one-way measurements. 00:39:21.000 --> 00:39:26.000 Number of latency, one-way sample, source-to-destination latency, destination-to-source latency. 00:39:27.000 --> 00:39:32.000 So we have the ability to do those calculations that I was saying, because we have our source and our responder in our particular case. 00:39:33.000 --> 00:39:34.000 And there's our Jitter. 00:39:35.000 --> 00:39:36.000 Our Jitter. 00:39:37.000 --> 00:39:38.000 Pocket loss as well, and so on and so forth. 00:39:39.000 --> 00:39:41.000 So here's the wrap-up to this. 00:39:42.000 --> 00:39:43.000 You might see UDP Echo on the exam. 00:39:44.000 --> 00:39:45.000 You might see UDP Jitter on the exam. 00:39:45.000 --> 00:39:46.000 You might see UDP Jitter on the exam. 00:39:47.000 --> 00:39:54.000 If you see both UDP and Echo in the same question, I would gravitate towards UDP Jitter as my answer. 00:39:55.000 --> 00:39:59.000 Especially if it's about voice, especially if it's about video, things like that, all right? 00:40:00.000 --> 00:40:08.000 If the question is still about voice and video, but there's no UDP Jitter option, but there's a UDP Echo option, then I want you to pick UDP Echo. 00:40:09.000 --> 00:40:14.000 And don't forget that both of these work best, UDP Echo and UDP Jitter, when you have a responder. 00:40:15.000 --> 00:40:16.000 When you have a responder. 00:40:17.000 --> 00:40:18.000 You don't need a responder, right? 00:40:19.000 --> 00:40:21.000 I could set all this up without a responder, but then I don't get what? 00:40:22.000 --> 00:40:27.000 I wouldn't get my Jitter, my one-way measurements, my Jitter, and all that stuff. 00:40:28.000 --> 00:40:29.000 I wouldn't be able to calculate that. 00:40:30.000 --> 00:40:31.000 So with a responder, you get the extra stuff. 00:40:32.000 --> 00:40:33.000 Without the responder, you don't get the Jitter. 00:40:34.000 --> 00:40:35.000 You don't get the latency and all that stuff. 00:40:35.000 --> 00:40:41.000 All right, so that is our coverage of IPSLA to get you ready for the Encore certification exam, folks. 00:40:42.000 --> 00:40:43.000 So review that a few different times. 00:40:44.000 --> 00:40:45.000 Take note of what I showed you. 00:40:46.000 --> 00:40:47.000 Take note of what I explained to you. 00:40:48.000 --> 00:40:55.000 So that way there, nothing throws you off when you get maybe one or two questions or max three for IPSLA on the certification exam.