All right, so for this customer scenario where they set up a virtual IP address
of
.5 on the 192.1 state one network and they want that to lead back to one of
these backend
servers with the load balancer in the middle of that.
So if you look to those previous screenshots and have a pretty good idea of
what you think
it might be, let's go to the live interface and verify it together.
So the first thing I'd want to do if it was a real customer site would be to
replicate
the symptoms or replicate the experience that they're having.
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
So let's bring out a client on this network right here, the 192.1 state one
network and
let's try to go to .5.
So it just so happens I have a little client right here.
Let's verify that it's on this subnet or at least has an IP address on that sub
net.
We'll do that up to CLI and we can do that with an IF config and its IP address
is 192.168.1.123.
So right from here from a command line, we could try a curl with a dash,
capital I to
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
HTTP colon slash slash and then go to that virtual address right here of 192.
168.1.5.
And we are not getting the header information coming back.
So this filling from the command line, let's also verify it from a browser.
So we'll open up a browser and I've got a bookmark right here for 192.168.1.5
and connection
was reset.
All right.
So we definitely have confirmed that it's not working.
Let me move the client computer out of the way.
So next, let's make a road trip over to the controller and take a look at its
configuration. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
configuration.
So here we are at the controller and right off the bat with application
selected and
the dashboard, we have one virtual service and it is showing as down.
So if we hover there, it says reason pools belonging to this virtual service
are down.
Okay.
Well, that's a really good indication of what's going on.
So if we go down to pools here.
It shows that supporting the service called web servers.
And as far as how many are available, we have zero out of three.
So if we click on that, that takes us to the details.
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
And so it shows in that pool, we have three servers and it shows that they are
all unreachable.
And it shows here also that markdown by system UDP.
Now what that implies is that implies that they health check that the load bal
ancer is
doing is UDP based, which by default, UDP wouldn't be responded to on just a
typical
server unless you had pre programmed it to respond and have open listening
ports to support
that for UDP.
So I think we need to go into details for the pool and take a look.
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
So if we click on the pencil here for the editing of this pool and then let's
just go
down through it.
Now we could just jump over to health bonner right there or we could just
scroll our way
down that would work too.
So this is the name of the pool.
Here's the cloud is supporting.
There's the default port.
It's using round Robin that all looks good so far.
As we continue to scroll down, there's the location for the actual servers on V
LAN 5.
That part looks good, including the subnet.
If we scroll down, there's our three servers.
They look correct. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They look correct.
As we continue to scroll down, now we're getting down to the health monitor
section.
So once again, we could have just clicked here and it would have just jumped us
over
to the health monitor section.
And this is using system UDP.
So unless they specifically set up those servers on the back end to respond to
UDP request,
they wouldn't by default have UDP ports open.
So it's very likely they have the wrong health monitor.
So one option is we could just use the drop down here and choose a different
health monitor.
So we could do ping.
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
Unfortunately though, if we did ping and the system was still responding to a
ping but
the web services stopped, that would be the load balancer to believe that
system is up.
When in reality, if the HTTP server stopped, it wouldn't be a valid server for
HTTP services.
So we want to use a health monitor that's going to closely match the services
actually
being served up from that system.
So we probably want to use the system HTTP and use that.
And so we'll go ahead and try that and we'll click on save.
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
And before we go back to the client and start, so that right there is a very
good indication
that those health checks in the background are working.
And we'll give that a few more minutes just to confirm that that number is
increasing.
So as more health checks are being sent, the actual health score for each of
those servers
on the back end should improve.
So let's go back to the dashboard under applications and our virtual service is
up now.
It's no longer read and it doesn't have a great score.
And that's because the server is very recently just came back online or
appeared to based
on health checks.
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
So if we let this run long enough and barring any other problems, the health
score here
for the virtual service should also continue to increase and increase.
Now if you click on virtual services, here's our virtual service called web
servers supporting
port 80.
We have one service engine associated with it that's supporting it and it would
click
on the link for web servers.
It'll take us there and we can hover once again on the virtual service up here.
So there is our service engine.
The service is up.
There's a virtual IP address is supporting and there's the service port is
associated
with this virtual service.
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
So now that this virtual service is appearing as up and it has back end
resources, including
the three servers that are now responding with an appropriate health check on
the back end.
Let's try it once again from the client.
So let's bring in our clients, which a moment ago failed that check and let's
go ahead and
click right here on try again.
Let's also do a control shift R just to verify around Robin is working and it
is that looks
fantastic.
That means all three servers are responding.
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
actual interface
here for one of those tiny little servers and I think of this little button
here to
disable the web service.
So on the back end, what should be happening is health checks for this specific
server
should fail and it should be moved out of rotation.
So we can verify that by going to pools over here on the left.
So it's been a few moments and now it's showing two of three servers are up and
available
as part of that pool.
So that's also going to have a negative impact on the overall health score for
that pool.
But from a customer's perspective, we still should be able to access that
virtual IP
address and be proxied to the servers behind it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
address and be proxied to the servers behind it.
So even though we only have two active servers, if we go back to our client and
open up a
browser and let me make sure my cache is empty.
So let me clear my cache.
So I'll go ahead and clear the cache.
I'll say clear now and let me go ahead and let me just close the browser and
open it up
again for a nice fresh start.
And here I have a bookmark for 192 168 1.5 and sure enough, we can still
connect now.
We're not going to connect, of course, to the server that I brought down, which
was server
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
a, but as long as we still have at least one server in the pool, the customer
can still
get access to that resource.
So now we came back to the logs and I'll do a refresh right here to get the
latest and
greatest.
And now we can include the non significant logs as well.
Let me go ahead and collapse the right hand side here, give us a little more
room and
I'll collapse the left hand side as well.
So if we want to look at the details, for example, for this entry right here,
we'll
click on the eyeball and that's showing us the customer IP address at top 123
going to
the virtual IP address.
And the second one here is from the service engine going over to the actual
server on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
server on
the back end.
And there's the name of the service engine that was providing that function for
us.
So thanks for joining me in this set of videos regarding working with the
advanced load balancer
and using VLAN back segments for both the management of the service engines as
well
as VLAN back segments for the data plane and the servers that are going into
our pool.
And I look forward to seeing you my friend in another set of videos and another
skill
in the very near future.
Until then, I hope this has been informative and I'd like to thank you for
viewing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
viewing.
[BLANK_AUDIO]