- [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.