Jitter measurement

- [Instructor] IP SLA or IP service level agreements are a feature built into Cisco's iOS that provides a way to monitor network performance. This is an active method for monitoring and reporting, as it has the ability to report on our traffic in real time. Metrics that IP SLA has the ability to report on include basic connectivity, delay, jitter, packet loss and sequencing, response time, and much more. This is a very common tool for service providers that they use to monitor customer sites, whether that's internet service providers or data center providers, but it can also be helpful to us as we're troubleshooting our own topologies. The main benefit of IP SLA is that it does not require a physical probe in order to monitor network performance. It simply uses generated traffic to measure the performance of a network between devices. Configuring IP SLA requires an IP SLA source and, optionally, an IP SLA responder. The IP SLA source will generate packets and send those to a destination device somewhere else on the network. This can be as simple as an ICMP echo used to continuously test reachability of a remote device. The response from the remote device would have timestamp information that would allow the IP SLA source to make calculations around certain network metrics that would be of interest to us. Optionally, a remote Cisco router could be configured as an IP SLA responder. This would allow the device to respond to more advanced IP SLA request packets. Some IP SLA operations will work without a responder on the other side. Some of those operations would include ICMP or HTTP. In order for IP SLA to be effective, they leverage SNMP traps triggered by events, such as connection loss, jitter, latency, and packet loss, just to name a few things. For any IP SLA metric, certain thresholds can be set. So, for example, we might set a threshold for a specific round-time trip metric. Anytime our IP SLA detected a threshold violation, that is if the round trip time went above our configured upper limit in this example, an SNMP trap would be sent out to trigger an alert to an administrator. Also, threshold violations can be used to trigger other IP SLA operations for subsequent testing in the event of a violation. So, for example, the frequency of the probe may be increased to ensure that the information is accurate, and that it's not just an anomaly. An additional and optional piece of an IP SLA configuration is some type of SNMP agent. That's going to give you the ability to more easily read and interpret reporting. Some of those popular options include SolarWinds, PRTG, and Nagios Core, but there are many, many SNMP monitoring tools on the market. In regard to IP SLA, we want to specifically examine jitter measurements here in this video. Jitter in an IP network is the measurement of variation in the latency of a packet flow. So that's an important metric to be able to capture. This can alert us to unexpected route changes or network congestion, among other things. Measuring jitter does require an IP SLA responder on the other side, and so in this topology, we have router one, that's going to act as our IP SLA source, and that's connected to router two, which we'll configure as an IP SLA responder. So, on router one, let's say, show run. We want to pipe to section beginning with ip sla, just so that we can see what we currently have in place, and you can see that, at the moment, we have a very simple ICMP echo, or a ping test in other words, over to 10.1.1.50, which is router two, in our case. We can also say, show ip sla configuration 1, and this will give us a more detailed output of that. So we can see, again, our target address, 10.1.1.50, we can see that the start time has already passed, so this is up and running, and the frequency, we can see is every 10 seconds. We can also say, show ip sla statistics, for IP SLA number one, and this tells us we have 28 successes and zero failures at the moment. So you can see I've had this up and running for some time and everything seems to be going just as we would expect. So that's a pretty basic IP SLA configuration. We're only tracking basic connectivity through an ICMP ping. So let's look at tracking jitter between these devices. If we start here on router one, let's go under global configuration mode, and let's say, ip sla, and if we look at contextual help, you can see at the top, it tells us we need to give that an entry number. So since we already have entry number one, I'm just going to make this number two, and we'll hit enter. Now, we are under IP SLA configuration mode. If we, again, look at our contextual help options, you can see we have various ways that we can configure IP SLA. Now, in our case, for tracking jitter, the option that we want to use is this udp-jitter. So let's say, udp-jitter. And one of the common reasons you might use this would be to diagnose voice over IP or video streaming traffic, really any type of conferencing. So let's follow that with the IP address that we want to send our probe packets to, which is, of course, router two at 10.1.1.50. And if we look at contextual help, we need to specify a port number, and we can indicate that, so I will say, 16500, as the port number. Now, if we look at contextual help again, notice this top option is for a codec. So we have lots of options here, but I'll point out the codec option. We can indicate the number of packets, we can indicate the size of those, lots of different things. But one way that you might use this, if you're tracking jitter, is you may want to specify a codec. You can see those here. I'm just going to choose the g729a codec, and we want to say control to enable our control packets. So we'll enable those, and we'll hit enter. The next thing we want to do is we want to set the frequency. How often do we want this to occur? I'm going to set that to every five seconds in our case by saying frequency 5, and we can end that. So that's our basic configuration. Now, we can say, show ip sla 2, and this is going to show us everything that we've configured again. We see that we're using udp-jitter. That's what we're tracking. We're tracking at 10.1.1.50. That's router two. We see we're doing that over target port 16500. We're going to do that every five seconds, and notice here that the next scheduled start time is listed as pending trigger. So, in other words, we need to start this probe. Let's do that. Let's go under global configuration mode, and let's say, ip sla schedule, and contextual help is going to tell us we need to give this an entry number as well. I find that it's easiest just to give that the same entry number as the probe has, just so there's a really easy correlation if you need to go back and take a look at that later. So I'll say, 2. Contextual help is going to tell us more of those options again, so we can specify the lifetime. I'm going to set that to forever. So this will essentially run indefinitely. And I want to say start-time. And if we look at those help options, you can see we can specify that as pending, as random. You can specify a very specific hour, minute, and second for that to start. In my case, I want it to start immediately, so I'm just going to say, now. I'll break out of here, and I want to say, show ip sla configuration 2, this time. And now, you'll notice that we see a lot of the same information that we just looked at prior to this, but this time, our start time tells us that the start time has already passed. So now, this probe is active. So let's again, look at some of those statistics. Let's say, show ip sla statistics, and this time, we want to do that for ip sla 2. Now, notice at the very end of this output, we have zero successes at the moment, and we have two failures. Why is that? Well, when we're tracking udp-jitter, we have to have an IP SLA responder configured, and we can do that very easily. Let's go to router two. We'll go under global configuration mode, and we'll say, ip sla responder. Very, very simple to do that. If we break out of there and say, show run pipe to section beginning with ip sla, that's going to verify that we have in fact configured this as an IP SLA responder. We see that in our output. If we go back to router one now, and let's see if it's had enough time to run. Again, we'll say, show ip sla statistics 2. Looks like it's still at zero successes, so we'll just run that couple more times. We should begin to see successes pop in there. Now, you can see in our output, when we give that a little bit of time to run, now we're already up to one success. So it looks like that is responding as we would expect. Run that once more just to verify. We're not getting any additional failures. So we're still at four. We have one success. And there we go. We've seen our second success. So it looks like this is working just as we would expect. So that's how we can set up IP SLA to track jitter and to take a look at those statistics. Now, a couple of places you need to check for troubleshooting. Those would be obviously the destination IP address. So if we again say, show ip sla configuration 2. Again, you want to make sure, first of all, that the type of operation you've chosen is correct. If you're having trouble, you want to check to make sure you've configured that correctly and, of course, the destination or the target IP address. You want to make sure that that is correct. If you're using more advanced IP SLA, such as we did here by measuring jitter, you want to make sure you have an IP SLA responder configured. Remember that when we initially turned this probe on, we were getting failures, and that's because we did not have an IP SLA responder configured. So, with these more advanced options, it's important to do that. With the general ICMP echo that was already in place, that wasn't necessary, but again, the more advanced probes are going to require IP SLA responders. And, of course, you want to make sure that you've also configured your port correctly. That's another place that you want to check and make sure that you have configured properly. And, finally, we want to make sure that our start time has passed. We want to see that message, Start Time has already passed. If you don't see that, if it tells you that it's pending trigger, that means that the probe actually has not been started yet. So that's a look at IP SLA and, specifically, using that to check for jitter.