And to really appreciate the idea of an IP SLA, let me start off with a true
story,
if something happened to me, a long, long time ago, back, I won't say what year
it was, but a long,
long time ago at Paramount Pictures, we had an application that was written by
our developers
that some of the executives at Paramount Pictures used. So let's imagine this
is the computer
where the executive sat, and when they clicked a button to build a table,
actually, they just
clicked a button for some function. And what happened in the background, there
was a server
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
that was being used, and it was actually calling upon a SQL server, a database,
to go ahead and
collect the data, and then return it to the client, and then fill the graph or
complete the table
at the desktop of the user. Now, unfortunately, when the user clicked on that
one little item that
caused that to happen, it took like 60 seconds. Now I'm rounding it there was
close to 60 seconds,
which is for anything pretty much, that's an eternity when somebody clicks a
button and they
have to wait 60 seconds for it to populate the table. And so what the
developers team came back
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
and said, well, it's a split. There's 20 seconds that the application is taking
here to actually do
the crunching there locally. There's 20 seconds that's being used for the
network to deliver the
traffic, which even decades ago, it wouldn't have been that long for moving
data across the network.
And at the point of time, this was happening in my experience, the network
traffic was above 10
megabits per second. So it wasn't the network taking 20 seconds just to move
the data. And then
they said it was another 20 seconds on the back end for the SQL server to
actually do the queries
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
and so forth. Now that was just a complete wild guess. And it was unfortunately
, most of the burden
was on me because my team was responsible for the SQL server on the back end.
And also the network
and the developers were just responsible for the application. So put app, net,
and SQL. So one of
the first things we wanted to do is to actually validate where is the actual
delay. So we did was
after hours, we actually wrote a little script, and that little script had a
bunch of SQL statements
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
in it. So it'd go ahead and create a timestamp. And we write that timestamp to
a network drive,
then it will do several of the SQL requests, the ones that were being done by
the app. And then
it would go ahead and after that was done, and make a timestamp and write that
to disk. And then
we'll go ahead and repeat that. So we had a central database from like five or
10 machines
that were all running this over and over and over again to actually collect the
timestamps.
And as it turned out, the time it took for the actual queries to be made, the
responses to come
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
back was about nine seconds, which is still quite a bit of time. But the
development team said,
Oh, it's 40 seconds for the network of the SQL server, went in reality. It was
about nine seconds
for that whole back end of all the transport across. But we had to prove that
by doing some
testing. So after we came back with that information and had it clearly
documented,
the developer team then took a look at their coding and said, Oh, we can
revisit this and
change that. And they got the whole thing down to about 13 seconds. Now it's
still in today's
standards, 13 seconds after you click on something that's an eternity. But it's
a lot less than the
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
60 seconds. And to come back to our point here, if we have to prove that our
network and our devices
are behaving in a certain fashion, we have to have some mechanism for doing
that. So back at Paramount
Pictures, we created some batch files and ran them to build our documentation
about the time it took
for the SQL server on the network. And we can use IP SLAs IP service level
groups today for the
testing and measurement of our data as it goes across the network. So let me
clean this up a little
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
bit and let's chat about what we can do on a Cisco network to implement IP SLAs
. One of the cool
things is we can specify that some device in the network will be a responder.
For example,
let's say we want our eight to be able to respond to any probes that we send
across the network and
feed that information back. And when we set that up on our eight to make it
willing to respond,
we do that with the command IP space SLA space responder, just like that. So we
just do that in
global config. And that makes our eight willing to respond. Now some devices,
if we just do like
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
a ping test, they'll respond to that without any type of configuration. But for
some of the
advanced and more detailed information we want to get from SLAs, if we use the
IP SLA responder
feature on a Cisco router, because the functionality once we enable the feature
is built in, we don't
have to add any other devices to our network. We can have our existing
infrastructure act as
responders. So for the IP SLA responder, let's go ahead and specify that as a
target. And then what
we do is we specify some other device or devices in our network to act as the
probes where they're
sending out information requests to that responder. So maybe our eight is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sending out information requests to that responder. So maybe our eight is the
responder, and maybe
we use our one as a probe that sends out requests to the responder. So our next
question might be,
well, what exactly are the types of things we can measure and get information
on regarding our
network? Well, here's a few we can measure delay. So if we want to measure
delay in our network,
or if we have a service level agreement says, you know what, we want to make
sure that the round
trip time is anywhere above 100 milliseconds, we want to have that considered
out of the threshold,
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
meaning out of bounds or above what we want, then we can set up a probe that's
sitting traffic down
the responder, measuring the response back either from that device directly, or
we can measure the
entire path response. And assuming that target is reachable, and the delay is
less than 100 milliseconds,
that would be considered within scope or within the IP SLA. Or if the delay is
more than 100 milliseconds,
the SLA can measure that and say, whoa, this is outside of the threshold. And
then we can use
other tools like S&P and network management tools to keep track of that. And
based on a problem or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
based on a problem or
an issue allows to go ahead and address it. So besides delay, what else can we
measure with IP
SLAs? Another important factor for many applications is jitter. Now, I think,
well, what's the difference
key between jitter and delay? And when I think of jitter, I think of it as
variation regarding delay,
another way of saying delay is latency. So for example, if some of our packets
are coming in with
50 millisecond delay, and others are coming in with 160 millisecond delay, and
others are coming in
with 20 millisecond delay, for some applications like email, that doesn't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with 20 millisecond delay, for some applications like email, that doesn't
matter at all. But if
we have a real time application like voice over IP, or some real time video,
that jitter, that
variation in delay can wreak havoc on those types of applications. So we can
set up a service level
agreement probing and verifying what is the jitter and if it falls out of scope
of what we needed to
be, we can go ahead and be aware of it. Again, if we're either looking at the
router during the
probes, or if we have a network management system with S&P, we can have alerts
indicating that
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
there's a problem. Another popular but simple option is to look for packet loss
. We can also
analyze the path that's being taken and the delay based on each hop in the path
. We can also
measure web services. So if we have a web server down here, and we want to
verify the delay between,
for example, R1, the probe and the web server, we can test that as well. We can
also test for
DHCP services. So if we have a DHCP server, and all of a sudden it's no longer
in scope or it's no
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
longer available, we can become aware of that if we've set up DHCP probes as
part of our IP SLAs.
There's also an option to test DNS services. So if we have a DNS issue or
problem by doing probes
with IP SLAs, if the DNS service is no longer available or is it working
correctly, we can be
aware of it. And with all of these, we can track these SLAs as well. So in the
event that, for example,
there's packet loss or non-reachability to a target, we can actually manipulate
our routing or other
parameters on the routers in conjunction with that. For example, let's say R3
right here. Let's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
right here. Let's
imagine we have a default route that goes over to R4. So put 000, 000 there to
represent a default
route with the next top of 10, 0, about 34, 000. However, if R4 is not reach
able, let's go ahead
and imagine R4 has a loop back of 4.4.4.4, which it does. So what we could do
is we could set up an
IP SLA for reachability testing to verify that R3 can reach that loopback
address. And we can make
the default route conditional upon that SLA being mapped, meaning that 4444 is
reachable. And should
that 4444 not be reachable, we can go ahead and automatically remove that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that 4444 not be reachable, we can go ahead and automatically remove that
default route from R3.
And by using route maps and policy-based routing, we can basically track and
manipulate the activities
on the router based on the IPSLA coming back okay or coming back as failed. And
in a reachability
test, okay would mean I can reach 4444 and failed would mean I can't or in the
concept of measuring
jitter we can set a threshold. So if the threshold we specified were jitter is
below a certain value,
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
it'd be okay or if it's above that level it'd be considered failed. So here's
what I propose
to do in the next video. Let's put a quick high level game plan together
regarding several options
with IPSLA that we can implement. And then we'll take that game plan and we'll
walk through it
step by step and at the tail end of the set of videos, I'll put you on a hands-
on lab so you too
can get practice in configuring and verifying IP service level agreements. So I
'll see you in the
in the next video in just a moment.