To start off, I thought it'd be a great idea
for you and I to chat about the big picture regarding
SLAs, what our options are.
And then in the proceeding videos,
we'll have a chance to go ahead and lab them up and verify them
together.
So let's use this topology for a discussion SLAs
and how they can help us.
Service level agreements between a service provider
and a customer, they might guarantee
you 99% uptime or a certain quality of service
through the network.
And by using SLAs, we can actually
have a consistent way of measuring that and verifying,
is that happening, or is it not? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is that happening, or is it not?
See, sometimes when we have a problem in the network
and we start looking at the details, we might say,
well, it seems OK now.
But maybe over time, it's had a problem or an issue.
Well, with SLAs, we can actually determine
if there is a current problem and also
have some historical data as well.
So let's talk about some of the options
with service level agreements.
There's two parts we should start off with.
There is the source.
Think of the source like the individual that's
going to be sending out a probe, like hey, are you there?
And then the responder would be the device WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then the responder would be the device
that's responding back, saying, yes, I'm here.
And we have various things that we can send as a source.
Now, as an example, let's imagine
that we're down here on R8.
R8's kind of the end of the road.
And he's got some fairly slow links in the path getting up
here to this network, 10.0.1.0.
And R8 might have multiple paths to get to this network.
But one way we could verify that the network is reachable,
whether it's through this path or this path or this path,
is we could use an SLA.
So we would configure an SLA for reachability. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we would configure an SLA for reachability.
And we would send those requests--
and I'll use a different color here; I'll use blue--
up to R1.
Now, whatever path it takes, for this example, we don't care.
And if we just care about connectivity,
like can I reach that network, we could use the ICMP echo.
And the one thing about using an ICMP echo-based SLA
and sending it out every 10 seconds, every 15 seconds,
to get a response is that the responder just
thinks it's a ping.
We don't have to do anything special at R1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We don't have to do anything special at R1.
He just thinks he's getting a ping every 15 seconds
or whatever the frequency is.
He responds back.
And then this SLA will indicate, yeah, successful, successful,
successful.
Or maybe it runs for days, and it has thousands and thousands
of successful queries, ICMP probes, and responses.
So we know we have that connectivity.
So that's one option, ICMP.
Another use for SLAs is for jitter and delay.
And we might say, well, what's the big deal about delay,
a few milliseconds here, a few milliseconds there? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a few milliseconds here, a few milliseconds there?
But if we have jitter, which is varying
delay by great quantities, if we have applications like voice
over IP, that's tricky, because if we don't have
consistent or good enough throughput,
and if we have wild jitter, it's not
going to make for a very good application.
So we could also send out probes.
And so we could create an SLA based on UDP-jitter,
measuring the jitter.
So we send out a special request that's UDP.
And then in that case, we just configure
R1 to be a responder, saying, hey,
you're going to get some requests. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you're going to get some requests.
We could say, you might get any request and please respond.
Or we could be very specific with the request
it should respond to.
So we send these probes up regarding UDP.
And then we're measuring the details or that round trip,
like what is the delay getting there
and the delay getting back?
What's the round trip, and what's the jitter?
So those are great tools that we could use.
Now it doesn't end there.
There are lots of options with SLAs.
We could also use SLAs to track DHCP.
So if we had a DHCP server running
and we wanted to test every 30 seconds or every minute WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we wanted to test every 30 seconds or every minute
whether or not that server is up and handing out IP addresses
and able to, we could do an SLA for DHCP services.
It's fantastic.
And then, if it goes down or if it's not working correctly,
we can tie all that to SNMP.
And we can get an alert or a trap
that says, hey, this happened.
Or we could also do something called tracking.
So we can track to an SLA.
So an example of that would be HSRP.
If we're running HSRP somewhere and we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we're running HSRP somewhere and we're
tracking a hop past one of their routers
and it is no longer reachable, we
could automatically have that tracking,
which is based on the SLA.
If the SLA is not working correctly or not responding,
we could have that impact things like HSRP
and swap over so the active is no longer active.
It's now standby.
And what was the standby can go active and start forwarding
traffic.
And that same thing holds true for routing.
We could have static routes, and we could tie them or track them
in combination with an SLA.
So if a router in the path is not reachable,
we can go ahead and automatically swap over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can go ahead and automatically swap over
to an alternate path or an alternate route.
So the key here with SLAs are what are we
trying to monitor for?
Are we trying to verify connectivity
to a certain IP address?
Are we measuring the latency or jitter
for an application that needs consistent throughput?
Or are we looking for some service that's always up,
like DHCP?
So we'd create the SLA, we'd launch it,
and then we can use that SLA in combination
with tracking to go ahead and influence our network behavior.
Now, what we're going to do in the next videos and labs
is we are going to implement three different SLAs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is we are going to implement three different SLAs.
We're going to do one for ICMP echo.
We're going to do one for jitter with UDP.
And we'll also do one for DHCP checking.
And then we'll wrap up this set of videos
with a final lab, where we'll take an SLA
and we'll use it in combination with tracking.
And we can tie that tracking to something
like a static route or something else
that we want to manipulate.
So we can see when that SLA is failing and not responding
or not working correctly.
The tracked object is going to show down,
as in no longer good.
And our routing can take a different path. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And our routing can take a different path.
So all that's coming up, starting
with the next video and lab.
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.