WEBVTT

1
00:00.000 --> 00:03.680
So up to this point, we did an IC&P jitter probes and UDP jitter.

2
00:03.680 --> 00:06.160
And now we get to focus our attention on an application layer service

3
00:06.160 --> 00:06.800
monitoring with an

4
00:06.800 --> 00:11.750
IPSLA using HTTP. So I just so happen to have a server right here. This is

5
00:11.750 --> 00:12.480
actually the server,

6
00:12.480 --> 00:16.070
server one nug that we use to get console access to all of our other devices.

7
00:16.070 --> 00:17.440
And it's also running

8
00:17.440 --> 00:22.760
a basic HTTP service based on its services available as a Microsoft server. So

9
00:22.760 --> 00:23.600
it's running as a web

10
00:23.600 --> 00:28.510
server. What I'd like to do here is set up a probe from R1 and test that HTTP

11
00:28.510 --> 00:29.920
service just to verify

12
00:29.920 --> 00:34.320
that it's able to respond back. And so for the details, let's go ahead and for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.920 --> 00:34.320
that it's able to respond back. And so for the details, let's go ahead and for

13
00:34.320 --> 00:35.120
our test, let's use

14
00:35.120 --> 00:40.350
a get for HTTP colon, WACWAC, and we'll go ahead and use the IP address there

15
00:40.350 --> 00:43.760
192.168.1.100. And

16
00:43.760 --> 00:47.320
that'll just be the default web page for the web services running there on that

17
00:47.320 --> 00:48.320
server. Let's go

18
00:48.320 --> 00:52.840
ahead and set up the frequency so that we test every 60 seconds. And then we'll

19
00:52.840 --> 00:53.760
take a look at the

20
00:53.760 --> 00:58.810
results. So let's head over to R1 and set up the probe to verify that HTTP

21
00:58.810 --> 01:00.160
services are alive and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:58.810 --> 01:00.160
services are alive and

22
01:00.160 --> 01:04.680
well down to the server. And again, the server's IP address is at 192.168.1.100

23
01:04.680 --> 01:05.840
. So we're still R1.

24
01:05.840 --> 01:09.460
So let's do a show IPSLA summary to see where we're at. So we have two SLAs in

25
01:09.460 --> 01:10.640
place, one and two.

26
01:10.640 --> 01:14.340
Let's go ahead and make a third one. We'll do config T IP SLA and we'll use

27
01:14.340 --> 01:15.760
three and press enter.

28
01:15.760 --> 01:22.390
And for this one, we want to use HTTP. So we'll go ahead and type in HTTP space

29
01:22.390 --> 01:22.960
. And then we'll do a

30
01:22.960 --> 01:27.280
get and then we'll go ahead and put in the URL. So it's going to be HTTP colon

31
01:27.280 --> 01:30.480
slash slash 192.168.1.100.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:27.280 --> 01:30.480
slash slash 192.168.1.100.

32
01:30.480 --> 01:34.960
And then for the frequency, and it says the frequency can be between one and

33
01:34.960 --> 01:36.000
six hundred and four

34
01:36.000 --> 01:40.060
thousand seconds ish. But let's go ahead and try 30. But it's not going to like

35
01:40.060 --> 01:41.120
that because the

36
01:41.120 --> 01:47.270
default timeout for the HTTP testing is 60 seconds itself. So we'll go ahead

37
01:47.270 --> 01:48.720
and say the frequency

38
01:48.720 --> 01:52.950
is going to be 60 seconds. And it likes that. Okay, so every 60 seconds once

39
01:52.950 --> 01:53.360
this

40
01:53.360 --> 01:57.710
SLA is scheduled and running, it'll probe that server and validate that they

41
01:57.710 --> 01:58.880
can get content back.

42
01:58.880 --> 02:04.720
So type in exit, we'll just do a do show IP SLA summary. And it is currently
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

42
01:58.880 --> 02:04.720
So type in exit, we'll just do a do show IP SLA summary. And it is currently

43
02:04.720 --> 02:05.680
not running. Again,

44
02:05.680 --> 02:10.450
that little carrot on the far left indicates that also an IP SLA schedule. The

45
02:10.450 --> 02:11.280
ID number of our

46
02:11.280 --> 02:16.780
SLA is three. And that's going to do a start time. Say now, let's also run this

47
02:16.780 --> 02:18.080
forever as well.

48
02:18.080 --> 02:23.880
So life space, then we'll exit up configuration to a show IP SLA summary. And

49
02:23.880 --> 02:24.880
it is running right

50
02:24.880 --> 02:30.100
there. So look at that round trip time. That is pretty massive. That could be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:24.880 --> 02:30.100
there. So look at that round trip time. That is pretty massive. That could be

51
02:30.100 --> 02:31.200
for like the initial

52
02:31.200 --> 02:35.410
request or something. So that probably will go down. But let me also take you

53
02:35.410 --> 02:36.640
behind the scenes

54
02:36.640 --> 02:42.450
and let's do a packet capture on our network somewhere between R1 and server

55
02:42.450 --> 02:43.440
one. So we could

56
02:43.440 --> 02:47.510
capture on this ethernet segment between our six and our eight or between our

57
02:47.510 --> 02:48.720
two and our four

58
02:48.720 --> 02:51.410
or between our one and our two. That's the path we're taking to get to the

59
02:51.410 --> 02:52.560
server. We also verify

60
02:52.560 --> 02:59.310
that with a trace down to 192.1 state dot 1 dot 100 just to verify the path.

61
02:59.310 --> 03:00.080
And that looks great.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
02:59.310 --> 03:00.080
And that looks great.

62
03:00.080 --> 03:04.110
So the last octet represents the router. So our two are four, then our six,

63
03:04.110 --> 03:05.040
then to our eight,

64
03:05.040 --> 03:08.480
then to the server itself. All right, let's take a look at the capture. All

65
03:08.480 --> 03:09.600
right. So that capture

66
03:09.600 --> 03:13.850
is running. And as soon as I see some HTTP traffic, we'll go ahead and we'll

67
03:13.850 --> 03:15.200
stop the capture. We

68
03:15.200 --> 03:18.610
shouldn't have to wait more than 60 seconds for that to happen. So still

69
03:18.610 --> 03:20.000
waiting, still waiting.

70
03:20.000 --> 03:25.060
In fact, let's put a filter in for HTTP. So type in HTTP up here as a display

71
03:25.060 --> 03:26.160
filter. And as soon

72
03:26.160 --> 03:29.970
as it pops up here, we'll go ahead and stop the capture. All right. And there

73
03:29.970 --> 03:30.720
it is. So we'll go
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

73
03:29.970 --> 03:30.720
it is. So we'll go

74
03:30.720 --> 03:34.990
and stop the capture and take a look at the details. So so here's the initial

75
03:34.990 --> 03:36.320
probe from 10 dot 0

76
03:36.320 --> 03:40.400
dot 12 dot one. That's our one going to the server. It's an HTTP get request.

77
03:40.400 --> 03:41.520
If we look at the details

78
03:41.520 --> 03:44.910
of that, I'll make that a little bit bigger and scroll down the byte

79
03:44.910 --> 03:46.320
information here. We'll look

80
03:46.320 --> 03:50.180
at the payload here. It is a get request. And then the next frame for the

81
03:50.180 --> 03:51.280
response, let's go ahead

82
03:51.280 --> 03:54.970
and close that and look at the response here. Here we have the response coming

83
03:54.970 --> 03:56.000
back. So in our

84
03:56.000 --> 04:00.230
probe, if we're looking for some specific element or component of a website, we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
03:56.000 --> 04:00.230
probe, if we're looking for some specific element or component of a website, we

85
04:00.230 --> 04:01.280
could probe for that

86
04:01.280 --> 04:04.820
as well. And with an HTTP probe, there's also additional options of what we can

87
04:04.820 --> 04:05.360
look for and

88
04:05.360 --> 04:08.960
specify as part of that probe. But for this one, we just want to verify that

89
04:08.960 --> 04:10.480
the basic website is

90
04:10.480 --> 04:14.830
up and running. And if we wanted to, we could actually do a specific URL that

91
04:14.830 --> 04:15.840
drills further

92
04:15.840 --> 04:18.970
in the server and to make sure we get a response from it. But because we got

93
04:18.970 --> 04:20.800
the response 200, okay,

94
04:20.800 --> 04:24.180
which is feeding us back the content, we consider to be up. So if we go back to

95
04:24.180 --> 04:25.120
our one,

96
04:25.120 --> 04:30.160
and we do the show IPS lay summary again, and now our round trip time is better
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
04:25.120 --> 04:30.160
and we do the show IPS lay summary again, and now our round trip time is better

97
04:30.160 --> 04:30.880
than it was.

98
04:30.880 --> 04:34.710
So it's had a few opportunities and traffic. So now we do a show IPS lay

99
04:34.710 --> 04:35.920
statistics, and we put a

100
04:35.920 --> 04:39.940
three there and the keyword details and press center, it'll give us the details

101
04:39.940 --> 04:40.560
for that IPS

102
04:40.560 --> 04:45.110
la. So it's going to run forever, because we told it to there's the latest

103
04:45.110 --> 04:46.160
round trip time.

104
04:46.160 --> 04:50.120
And because we didn't specify a threshold, we're not over the threshold. If we

105
04:50.120 --> 04:51.360
'd put a DNS name

106
04:51.360 --> 04:54.430
instead of an IP address, it would also have information on how long it took to

107
04:54.430 --> 04:55.040
resolve that

108
04:55.040 --> 04:59.620
DNS information. Here's the TCP connection round trip time, and then the HTTP

109
04:59.620 --> 05:00.480
information,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
04:59.620 --> 05:00.480
information,

110
05:00.480 --> 05:04.750
which is what we're after to begin with. And speaking of DNS, if we wanted to

111
05:04.750 --> 05:05.760
have a specific

112
05:05.760 --> 05:10.240
probe and IPS la just for DNS, we could do that as well. And the great news is

113
05:10.240 --> 05:11.360
that that's exactly

114
05:11.360 --> 05:15.080
what you and I get to do in the very next video. So I'll see you there in just

115
05:15.080 --> 05:15.760
a moment.