WEBVTT

1
00:00.000 --> 00:04.240
All right, so for this customer scenario where they set up a virtual IP address

2
00:04.240 --> 00:04.740
of

3
00:04.740 --> 00:10.020
.5 on the 192.1 state one network and they want that to lead back to one of

4
00:10.020 --> 00:10.560
these backend

5
00:10.560 --> 00:14.060
servers with the load balancer in the middle of that.

6
00:14.060 --> 00:16.910
So if you look to those previous screenshots and have a pretty good idea of

7
00:16.910 --> 00:17.560
what you think

8
00:17.560 --> 00:22.140
it might be, let's go to the live interface and verify it together.

9
00:22.140 --> 00:25.690
So the first thing I'd want to do if it was a real customer site would be to

10
00:25.690 --> 00:26.320
replicate

11
00:26.320 --> 00:29.200
the symptoms or replicate the experience that they're having.

12
00:29.200 --> 00:33.580
So let's bring out a client on this network right here, the 192.1 state one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.200 --> 00:33.580
So let's bring out a client on this network right here, the 192.1 state one

13
00:33.580 --> 00:34.360
network and

14
00:34.360 --> 00:36.720
let's try to go to .5.

15
00:36.720 --> 00:39.920
So it just so happens I have a little client right here.

16
00:39.920 --> 00:43.770
Let's verify that it's on this subnet or at least has an IP address on that sub

17
00:43.770 --> 00:44.280
net.

18
00:44.280 --> 00:49.770
We'll do that up to CLI and we can do that with an IF config and its IP address

19
00:49.770 --> 00:53.480
is 192.168.1.123.

20
00:53.480 --> 00:57.120
So right from here from a command line, we could try a curl with a dash,

21
00:57.120 --> 00:57.720
capital I to

22
00:57.720 --> 01:04.110
HTTP colon slash slash and then go to that virtual address right here of 192.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:57.720 --> 01:04.110
HTTP colon slash slash and then go to that virtual address right here of 192.

23
01:04.110 --> 01:06.040
168.1.5.

24
01:06.040 --> 01:08.200
And we are not getting the header information coming back.

25
01:08.200 --> 01:12.120
So this filling from the command line, let's also verify it from a browser.

26
01:12.120 --> 01:17.740
So we'll open up a browser and I've got a bookmark right here for 192.168.1.5

27
01:17.740 --> 01:18.520
and connection

28
01:18.520 --> 01:19.960
was reset.

29
01:19.960 --> 01:20.960
All right.

30
01:20.960 --> 01:22.800
So we definitely have confirmed that it's not working.

31
01:22.800 --> 01:25.520
Let me move the client computer out of the way.

32
01:25.520 --> 01:29.030
So next, let's make a road trip over to the controller and take a look at its

33
01:29.030 --> 01:30.080
configuration.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:29.030 --> 01:30.080
configuration.

34
01:30.080 --> 01:33.980
So here we are at the controller and right off the bat with application

35
01:33.980 --> 01:34.840
selected and

36
01:34.840 --> 01:40.160
the dashboard, we have one virtual service and it is showing as down.

37
01:40.160 --> 01:44.450
So if we hover there, it says reason pools belonging to this virtual service

38
01:44.450 --> 01:45.400
are down.

39
01:45.400 --> 01:46.400
Okay.

40
01:46.400 --> 01:48.120
Well, that's a really good indication of what's going on.

41
01:48.120 --> 01:50.080
So if we go down to pools here.

42
01:50.080 --> 01:53.040
It shows that supporting the service called web servers.

43
01:53.040 --> 01:56.840
And as far as how many are available, we have zero out of three.

44
01:56.840 --> 01:59.440
So if we click on that, that takes us to the details.

45
01:59.440 --> 02:04.700
And so it shows in that pool, we have three servers and it shows that they are
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
01:59.440 --> 02:04.700
And so it shows in that pool, we have three servers and it shows that they are

46
02:04.700 --> 02:05.800
all unreachable.

47
02:05.800 --> 02:09.960
And it shows here also that markdown by system UDP.

48
02:09.960 --> 02:13.330
Now what that implies is that implies that they health check that the load bal

49
02:13.330 --> 02:13.800
ancer is

50
02:13.800 --> 02:19.170
doing is UDP based, which by default, UDP wouldn't be responded to on just a

51
02:19.170 --> 02:19.840
typical

52
02:19.840 --> 02:24.220
server unless you had pre programmed it to respond and have open listening

53
02:24.220 --> 02:25.160
ports to support

54
02:25.160 --> 02:26.400
that for UDP.

55
02:26.400 --> 02:29.960
So I think we need to go into details for the pool and take a look.

56
02:29.960 --> 02:34.220
So if we click on the pencil here for the editing of this pool and then let's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:29.960 --> 02:34.220
So if we click on the pencil here for the editing of this pool and then let's

57
02:34.220 --> 02:34.640
just go

58
02:34.640 --> 02:35.640
down through it.

59
02:35.640 --> 02:39.230
Now we could just jump over to health bonner right there or we could just

60
02:39.230 --> 02:39.800
scroll our way

61
02:39.800 --> 02:40.960
down that would work too.

62
02:40.960 --> 02:43.200
So this is the name of the pool.

63
02:43.200 --> 02:45.160
Here's the cloud is supporting.

64
02:45.160 --> 02:46.760
There's the default port.

65
02:46.760 --> 02:50.040
It's using round Robin that all looks good so far.

66
02:50.040 --> 02:53.730
As we continue to scroll down, there's the location for the actual servers on V

67
02:53.730 --> 02:54.840
LAN 5.

68
02:54.840 --> 02:56.720
That part looks good, including the subnet.

69
02:56.720 --> 02:59.600
If we scroll down, there's our three servers.

70
02:59.600 --> 03:00.880
They look correct.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
02:59.600 --> 03:00.880
They look correct.

71
03:00.880 --> 03:04.030
As we continue to scroll down, now we're getting down to the health monitor

72
03:04.030 --> 03:04.600
section.

73
03:04.600 --> 03:07.140
So once again, we could have just clicked here and it would have just jumped us

74
03:07.140 --> 03:07.360
over

75
03:07.360 --> 03:09.080
to the health monitor section.

76
03:09.080 --> 03:12.120
And this is using system UDP.

77
03:12.120 --> 03:16.750
So unless they specifically set up those servers on the back end to respond to

78
03:16.750 --> 03:17.600
UDP request,

79
03:17.600 --> 03:20.200
they wouldn't by default have UDP ports open.

80
03:20.200 --> 03:22.640
So it's very likely they have the wrong health monitor.

81
03:22.640 --> 03:26.140
So one option is we could just use the drop down here and choose a different

82
03:26.140 --> 03:27.200
health monitor.

83
03:27.200 --> 03:28.360
So we could do ping.

84
03:28.360 --> 03:32.090
Unfortunately though, if we did ping and the system was still responding to a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
03:28.360 --> 03:32.090
Unfortunately though, if we did ping and the system was still responding to a

85
03:32.090 --> 03:32.600
ping but

86
03:32.600 --> 03:35.730
the web services stopped, that would be the load balancer to believe that

87
03:35.730 --> 03:37.040
system is up.

88
03:37.040 --> 03:40.820
When in reality, if the HTTP server stopped, it wouldn't be a valid server for

89
03:40.820 --> 03:41.800
HTTP services.

90
03:41.800 --> 03:45.900
So we want to use a health monitor that's going to closely match the services

91
03:45.900 --> 03:46.120
actually

92
03:46.120 --> 03:48.320
being served up from that system.

93
03:48.320 --> 03:52.520
So we probably want to use the system HTTP and use that.

94
03:52.520 --> 03:55.120
And so we'll go ahead and try that and we'll click on save.

95
03:55.120 --> 04:00.070
And before we go back to the client and start, so that right there is a very
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
03:55.120 --> 04:00.070
And before we go back to the client and start, so that right there is a very

96
04:00.070 --> 04:01.160
good indication

97
04:01.160 --> 04:04.040
that those health checks in the background are working.

98
04:04.040 --> 04:07.490
And we'll give that a few more minutes just to confirm that that number is

99
04:07.490 --> 04:08.320
increasing.

100
04:08.320 --> 04:12.260
So as more health checks are being sent, the actual health score for each of

101
04:12.260 --> 04:13.080
those servers

102
04:13.080 --> 04:15.120
on the back end should improve.

103
04:15.120 --> 04:20.530
So let's go back to the dashboard under applications and our virtual service is

104
04:20.530 --> 04:20.840
up now.

105
04:20.840 --> 04:23.800
It's no longer read and it doesn't have a great score.

106
04:23.800 --> 04:26.610
And that's because the server is very recently just came back online or

107
04:26.610 --> 04:27.440
appeared to based

108
04:27.440 --> 04:28.440
on health checks.

109
04:28.440 --> 04:32.160
So if we let this run long enough and barring any other problems, the health
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
04:28.440 --> 04:32.160
So if we let this run long enough and barring any other problems, the health

110
04:32.160 --> 04:32.760
score here

111
04:32.760 --> 04:36.800
for the virtual service should also continue to increase and increase.

112
04:36.800 --> 04:40.490
Now if you click on virtual services, here's our virtual service called web

113
04:40.490 --> 04:41.400
servers supporting

114
04:41.400 --> 04:42.400
port 80.

115
04:42.400 --> 04:45.550
We have one service engine associated with it that's supporting it and it would

116
04:45.550 --> 04:45.920
click

117
04:45.920 --> 04:47.600
on the link for web servers.

118
04:47.600 --> 04:51.000
It'll take us there and we can hover once again on the virtual service up here.

119
04:51.000 --> 04:53.080
So there is our service engine.

120
04:53.080 --> 04:54.560
The service is up.

121
04:54.560 --> 04:57.760
There's a virtual IP address is supporting and there's the service port is

122
04:57.760 --> 04:58.360
associated

123
04:58.360 --> 04:59.840
with this virtual service.

124
04:59.840 --> 05:03.300
So now that this virtual service is appearing as up and it has back end
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

124
04:59.840 --> 05:03.300
So now that this virtual service is appearing as up and it has back end

125
05:03.300 --> 05:04.640
resources, including

126
05:04.640 --> 05:08.120
the three servers that are now responding with an appropriate health check on

127
05:08.120 --> 05:09.480
the back end.

128
05:09.480 --> 05:11.320
Let's try it once again from the client.

129
05:11.320 --> 05:15.620
So let's bring in our clients, which a moment ago failed that check and let's

130
05:15.620 --> 05:16.360
go ahead and

131
05:16.360 --> 05:17.920
click right here on try again.

132
05:17.920 --> 05:22.590
Let's also do a control shift R just to verify around Robin is working and it

133
05:22.590 --> 05:23.520
is that looks

134
05:23.520 --> 05:24.520
fantastic.

135
05:24.520 --> 05:26.800
That means all three servers are responding.

136
05:26.800 --> 05:30.000
And if we were to take one of those servers out of the loop, so this is the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
05:30.000 --> 05:30.880
actual interface

138
05:30.880 --> 05:33.680
here for one of those tiny little servers and I think of this little button

139
05:33.680 --> 05:34.040
here to

140
05:34.040 --> 05:35.840
disable the web service.

141
05:35.840 --> 05:39.590
So on the back end, what should be happening is health checks for this specific

142
05:39.590 --> 05:40.040
server

143
05:40.040 --> 05:43.280
should fail and it should be moved out of rotation.

144
05:43.280 --> 05:45.960
So we can verify that by going to pools over here on the left.

145
05:45.960 --> 05:49.260
So it's been a few moments and now it's showing two of three servers are up and

146
05:49.260 --> 05:49.840
available

147
05:49.840 --> 05:51.240
as part of that pool.

148
05:51.240 --> 05:54.480
So that's also going to have a negative impact on the overall health score for

149
05:54.480 --> 05:55.240
that pool.

150
05:55.240 --> 05:59.140
But from a customer's perspective, we still should be able to access that

151
05:59.140 --> 05:59.840
virtual IP

152
05:59.840 --> 06:03.080
address and be proxied to the servers behind it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
05:59.840 --> 06:03.080
address and be proxied to the servers behind it.

153
06:03.080 --> 06:07.020
So even though we only have two active servers, if we go back to our client and

154
06:07.020 --> 06:07.520
open up a

155
06:07.520 --> 06:10.160
browser and let me make sure my cache is empty.

156
06:10.160 --> 06:11.640
So let me clear my cache.

157
06:11.640 --> 06:13.040
So I'll go ahead and clear the cache.

158
06:13.040 --> 06:17.060
I'll say clear now and let me go ahead and let me just close the browser and

159
06:17.060 --> 06:17.680
open it up

160
06:17.680 --> 06:20.160
again for a nice fresh start.

161
06:20.160 --> 06:24.310
And here I have a bookmark for 192 168 1.5 and sure enough, we can still

162
06:24.310 --> 06:25.120
connect now.

163
06:25.120 --> 06:28.140
We're not going to connect, of course, to the server that I brought down, which

164
06:28.140 --> 06:28.640
was server

165
06:28.640 --> 06:32.850
a, but as long as we still have at least one server in the pool, the customer
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

165
06:28.640 --> 06:32.850
a, but as long as we still have at least one server in the pool, the customer

166
06:32.850 --> 06:33.520
can still

167
06:33.520 --> 06:35.360
get access to that resource.

168
06:35.360 --> 06:38.520
So now we came back to the logs and I'll do a refresh right here to get the

169
06:38.520 --> 06:39.120
latest and

170
06:39.120 --> 06:40.120
greatest.

171
06:40.120 --> 06:42.320
And now we can include the non significant logs as well.

172
06:42.320 --> 06:45.900
Let me go ahead and collapse the right hand side here, give us a little more

173
06:45.900 --> 06:46.120
room and

174
06:46.120 --> 06:47.680
I'll collapse the left hand side as well.

175
06:47.680 --> 06:50.570
So if we want to look at the details, for example, for this entry right here,

176
06:50.570 --> 06:50.880
we'll

177
06:50.880 --> 06:54.840
click on the eyeball and that's showing us the customer IP address at top 123

178
06:54.840 --> 06:55.400
going to

179
06:55.400 --> 06:56.400
the virtual IP address.

180
06:56.400 --> 06:59.720
And the second one here is from the service engine going over to the actual

181
06:59.720 --> 07:00.240
server on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

181
06:59.720 --> 07:00.240
server on

182
07:00.240 --> 07:01.240
the back end.

183
07:01.240 --> 07:04.480
And there's the name of the service engine that was providing that function for

184
07:04.480 --> 07:04.760
us.

185
07:04.760 --> 07:07.790
So thanks for joining me in this set of videos regarding working with the

186
07:07.790 --> 07:09.400
advanced load balancer

187
07:09.400 --> 07:14.800
and using VLAN back segments for both the management of the service engines as

188
07:14.800 --> 07:15.200
well

189
07:15.200 --> 07:19.870
as VLAN back segments for the data plane and the servers that are going into

190
07:19.870 --> 07:20.560
our pool.

191
07:20.560 --> 07:23.760
And I look forward to seeing you my friend in another set of videos and another

192
07:23.760 --> 07:24.080
skill

193
07:24.080 --> 07:25.600
in the very near future.

194
07:25.600 --> 07:29.640
Until then, I hope this has been informative and I'd like to thank you for

195
07:29.640 --> 07:30.040
viewing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

195
07:29.640 --> 07:30.040
viewing.

196
07:30.040 --> 07:39.300
[BLANK_AUDIO]