I wonder what the delay is, or the jitter, between point A
and point B in the network.
That's a good question to ask ourselves
and to monitor if we're using voice over IP.
So in this video and hands-on lab,
you and I are going to set up an SLA that's
looking for our jitter so we have
some feedback in monitoring regarding what that latency
and what that jitter is between two points in the network.
All right.
So let's set up our plan.
Let's imagine that we have a client down here,
our device that's running voice over IP.
And it's communicating with a device
up here on the 10.0.1 network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up here on the 10.0.1 network.
This could be a server or another peer-to-peer device.
And what we want to do is, from R7, we want to, first of all,
determine and then monitor over time the latency
and the jitter between R7 and R1.
What we could do is we could set up an SLA that's
looking for jitter.
We'll use UDP as a transport protocol.
And we probably want to aim at this network or this interface
because that's where the actual server would be.
Actually, we could also source it from this interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Actually, we could also source it from this interface.
So we could source this SLA from this network,
which is the 10.1.7 network--
and R7 is .7--
and going to 10.0.1.1, which is R1.
And if we're doing something above and beyond just
echo requests, we need to train R1 to be willing to respond.
Effectively, R1's going to be an SLA responder so,
when he gets these probes, he's willing to respond back
to the actual person who made that request.
In this case, it's going to be R7.
So let me walk you through that syntax.
If you're sitting at a computer logged on to the CBT Nuggets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If you're sitting at a computer logged on to the CBT Nuggets
website, I encourage you to click
on the link for the virtual lab and do this hands-on along
with me.
All right.
Here we are on R7.
Let's do a first show IP route.
Just want to make sure we have access to the 10.0.1.0 network,
and we do.
That's in the top left of our topology.
Great.
So let's create an SLA.
So config t, and we'll do a IP SLA.
And let's call this--
what do you want to call this?
Let's call this 111.
There we go.
That's creative. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's creative.
So SLA 111.
So in this SLA, what do we want to look for?
And so in this example, we want to do-- we did ICMP echo.
Let's do the UDP jitter, exactly what we're looking for.
So we'll type in udp-jitter and a question mark.
And now it's asking, where to?
We'll say 10.0.1.1, which is the gig 0/0 interface up on R1.
And then we can also specify the port.
We can use any port we want because, when
we configure the responder to respond, he'll respond back. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we configure the responder to respond, he'll respond back.
So we'll cover R1 as well.
So we're going to use UDP port 3131.
And then we're going to use source IP address.
And back in our topology, I'm going
to point back to the source being 10.1.7.7,
this interface right here.
That way, we get an accurate picture from network
to network and all the interfaces involved or our SLA.
I'm going to put 10.1.7.7.
And then, for the number of packets, let's go ahead
and do num-packets.
And the default's 10. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the default's 10.
Let's send five.
And then the interval, let's go ahead and--
the delay, let's do every five seconds.
So five packets delayed by five--
so that's about 25 seconds per test,
and then we can specify the frequency.
So for the frequency, we can say,
let's do that every 60 seconds.
So every 60 seconds, it's going to send five packets
at five-second intervals, and I get the responses back. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at five-second intervals, and I get the responses back.
And let's see what other options we have here as well.
Let's use this one too, request data size.
So we can actually specify the size.
And I clipped off the R there.
Sorry about that.
So request data size, and let's specify it's in bytes.
So I'm going to do 150 bytes.
I want to keep it under 1,500.
I don't have datagrams so big that I have
to fragmentation at layer 3.
So 150 bytes times eight is still less than 1,500, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So 150 bytes times eight is still less than 1,500,
so that'll work.
And let's do a do show run, include section SLA just
to see what we have so far.
All right.
So IP SLA 111, UDP jitter, that destination address,
that source address, number of packets five,
interval five, data request size 150.
Didn't I say frequency?
I thought I did frequency.
[INAUDIBLE] again.
Frequency-- let's do frequency 55 seconds,
and then do that show command again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then do that show command again.
There we go.
So I presume, based on what just happened,
that the default is 60 seconds.
And that's why I said, oh, that's the default.
No need to have it literally in the config.
So every 55 seconds, it's going to do
five packets at five-second intervals
and get the responses back.
All right.
Now let's launch this.
But to launch it, it's IP SLA schedule, and then
the SLA number, which is 111.
And let's go ahead and do it start time now and lifetime, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's go ahead and do it start time now and lifetime,
and let's just do it for 1,000 seconds.
That's enough for this demo.
And then show IP SLA statistics.
All right, and here's the successes and failures.
So there's a lot of detail in this output.
But right now, just getting it going, troubleshooting-wise, I
want to see, is it working?
So let me do a show that, and I'll do a pipe include,
and we'll say success and fail. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we'll say success and fail.
There we go.
All right, so it's going to try every 55 seconds,
and so far, it's failing.
Oh, yeah.
I realize why now.
It's because we haven't trained R1 to be an SLA responder.
It's getting those probe requests and saying,
I don't know what that is.
Port 3131?
Nobody told me.
I'm not responding in any manner to that.
So let's go tell R1 that it should be an IP SLA responder.
So config t, IP SLA responder.
And if we want to, we can get very granular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we want to, we can get very granular
by specifying what it should respond to
and the addresses involved.
But if you just press enter here,
that's actually enough to make it work.
So if we do a show IP SLA responder and press enter,
it's showing us now that it's listening.
So if we go back to R7 and we do an up arrow of show
IP SLA statistics, include success/fail as part
of the output, we might have to wait 55 seconds WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of the output, we might have to wait 55 seconds
because it is running.
We can do a show IP SLA, and there's lots of options here.
We could do statistics again, which is great.
And look at this.
We have some data now.
We have some samples.
We also have some min, average, and max time for the responses.
And if you go down, boom, we have a success,
and that's going to continue to grow.
So if we do a show IP SLA statistics
with include success or failure, that success number, every 55
seconds, based on it coming back, should be successful.
So there's a couple of factors I want to point out here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there's a couple of factors I want to point out here
with the SLAs.
By themselves, they do give us some information
about what's working and what's happening in the network.
But also, we could tie the SLAs into SNMP
so that we can set thresholds so we get alerts like, OK,
if this stops happening or if this
goes beyond a certain limit, go ahead and generate an SNMP
alert.
Also, as we'll see in a couple of videos from right now,
we'll set up tracking.
Then we can have other network protocols like static routes
or HSRP and others pay attention via tracking to an SLA.
And if it changes or goes down or has a problem, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if it changes or goes down or has a problem,
the router or the network can make a different decision
about forwarding packets, and that's a fantastic tool
as well.
All right.
So in our next video, what I'd like to do
is give you a third example of hands-on configuration
for SLAs.
And that is not looking for just IP connectivity, not just
looking for jitter, but we're going to focus on,
is a DHCP server functioning on this network with an SLA
for DHCP?
And that's in the next video, so I'll see you there
in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I'd like to thank you for viewing.