Determining Necessary Configuration Objects

0:00It's time to put your architect hat on and start thinking like an architect

0:05when it comes to the big IP and its abilities.

0:09So what we're here doing is looking at determining the least amount of objects

0:15necessary, and this is really necessary for a given scenario, let's say.

0:20Okay, so let's have a quick review of the configuration objects. We've got a

0:24little screenshot over here to the right.

0:27So of course we've got virtual servers, policies, profiles, cypher, eye rules,

0:32pools, and along with the pools, we have our members that are in there.

0:38And of course, our nodes, which are directly related to our members, we've got

0:43monitors, traffic classes, and address translation.

0:47And of course, within many of these, like our virtual servers, there are

0:51profiles that we're going to be applying in there.

0:55So we need to think about those. So really this nugget here and this skill that

1:00's a part of, it's all about thinking like an architect and working on

1:06identifying what objects are necessary in order to meet a goal.

1:12So what we're going to do now is walk through a little scenario, and this is a

1:17very generic scenario. It's not very defined, so it's going to allow us to

1:21really talk through some of our options and what we might be facing.

1:25So here's the scenario. Again, very straightforward and generic. It's a new web

1:30application. So we know we're going to be dealing with HTTP.

1:36It requires load balancing, pretty straightforward, and the application must be

1:41encrypted to and from the client. Now, it's key here.

1:46Encrypted to and from the client. It doesn't say anything about encrypted to

1:51and from the server.

1:53Because remember, we've got your client over here communicating with the

1:58virtual server on the big IP, which then no balances to a pool member. Well, if

2:03only this portion here needs to be encrypted.

2:08Well, that means we can actually perform SSL offloading here at the big IP,

2:14which helps take some of the burden dealing with SSL off of our member servers

2:20there to read.

2:22Do some of the resource utilization. It also allows our big IP here to read

2:27layer seven information, all that layer seven traffic going across. So we're

2:34able to see everything and make decisions based on that.

2:37So now that we see what our scenario is, let me go ahead and make a little room

2:43here so that we can kind of walk through this. And we're starting with objects,

2:48right? We need to look at what objects we need to create.

2:52Well, obviously, if we're going to have an application like this, we need a

2:57virtual server. So we're going to have to figure out what type of virtual

3:01server would work best in this scenario.

3:04And honestly, when I look at it, I think of a standard virtual server, because

3:09the standard will allow us to have full layer seven functionality, as well as

3:15lots of other types of HTTP, let's say advanced settings, things like

3:22compression and web acceleration,

3:25and using, of course, I rules and one connect, all those things are going to be

3:31based on using a CDP. So if I have a standard server, I want to need to then

3:36think about some other things that goes into the server.

3:40For example, within the virtual server here, what are my profiles going to be

3:45that I'm going to be using? If I'm using a standard server, I know that

3:49defaults to the TCP profile.

3:51And of course, I'm already working with a web application. I'm definitely going

3:56to be wanting to use an HTTP profile as well.

3:59And if I'm using SSL offloading, well, then I'm going to need an SSL profile.

4:05And that's going to be the client side of that.

4:10That's going to allow me to terminate that SSL session. And that's what we see

4:13here. We know that's going to be the bare minimum right there, as far as

4:18profiles.

4:20Because of course, we could also look at using compression, web acceleration.

4:24Now there's nothing mentioned about that in here, but we need to think about

4:28that as an architect, big picture. What are all my options?

4:31What is my goal? What's the target that I'm aiming for here? And how can I get

4:36there using various objects and the profiles associated with them?

4:41So far, we've talked here about our virtual server. And actually, let's keep

4:45going with that virtual server. There's a couple of things we should also talk

4:49about.

4:50So we talk about profiles. We should also talk about SNAT. Do we need to use SN

4:55AT? That's a great question.

4:58So this address translation in SNAT, is there a requirement that the source

5:04address remained the same?

5:07And that would be a requirement of the application. Because if this equals true

5:12, then I cannot use SNAT because it's going to change that source address. I won

5:19't be able to do that.

5:20But if this is not true, if it's false, then I can use SNAT. But here's the

5:27question. Do I need to use SNAT? And really the answer to that is, when we come

5:33and look at our pool members here,

5:36these are all of our servers that we have. Well, is there default gateway the

5:41big IP? Which means all of the response traffic is going to go through the big

5:46IP. So we really don't need to worry about the use of SNAT.

5:51Now, here's the thing. If, for instance, the default gateway is not the big IP.

5:56No, they actually go over here to this router over here. Well, then we're going

6:01to need to use SNAT.

6:02Because that's going to ensure that our pool members send their responses to

6:06the sessions back through the big IP so they can be sent back out to the client

6:11.

6:12Okay. Unless we're using something like in-path that we're going to talk about

6:17later on in this course. So again, SNAT, that's something else we need to think

6:21about.

6:22We talked about our profile, our virtual server type. Now let's make a little

6:26room down here so that we can finish up with our virtual server discussion.

6:31And the next thing I want to talk about with our virtual servers is persistence

6:35. Because we're going to want to use persistence unless there's some reason that

6:41we shouldn't use it.

6:42For example, what if all of your clients over here, we'll put a bunch of

6:46clients here, these are all clients that are going to access your web

6:49application. There we go, super duper.

6:52And they all reside in one building at an office. There's a hundred of them,

6:57let's say. And they're going to come out to your big IP here.

7:02And they're going to access a virtual server. They're going to be load balanced

7:06over here to some pool members. All right. Everything looks good, right?

7:11Well, here's the exception to that. Think about this. If you are using source

7:16address affinity for your precedence, so it's based on the source address, when

7:21all these users leave their network, they're going through a gateway is

7:26probably a firewall routing service of some type.

7:30And it's going to be using net. So what's going to happen is most likely all

7:36those users are going to exit that network with the same source address, which

7:42means when that first packet comes to the virtual server, it's going to be load

7:48balance and sent to a specific

7:51pool member. And also at that point, a persistence record is created with that

7:58source address. So then we have another user who decides to go out and use the

8:03application. But guess what?

8:06They have the same source address. They're not going to be load balanced

8:08because there's a persistence record present. They're going to be sent to that

8:12same server.

8:13So we see the problem here. Most likely, everyone in this office is going to

8:19end up on that same pool member. Load balancing is not going to function like

8:24we think it should, because we're using source address affinity persistence in

8:29this type of scenario.

8:30So this is where we really need to consider what type of persistence we're

8:34going to choose to use. And that's why it's important to think like an

8:38architect. Think about the big picture.

8:41Who are the clients over here that are going to be accessing my application?

8:46Where do they reside? Are they in one location? Are they global? Do they sit in

8:49different offices or they work remotely? You know, all these things, as well as

8:54the information about how the application itself works.

8:58What protocols it uses? All of these things. Again, we're thinking like an

9:03architect. So I'm going to clear some of this out here.

9:06All right, so for now, that's going to wrap up our virtual server. But there's

9:10more. We need to talk about pools and those pools. They need to have members

9:15associated with them.

9:18And we need some type of load balancing method that we're going to use. And

9:23when choosing a load balancing method is important. We understand what these

9:27members are made up of.

9:29What are their abilities as far as CPU memory and disk resources are some more

9:34faster than others? And are they in the same location? Maybe they're located in

9:38different data centers.

9:40We need to understand what those are so we can choose the best load balancing

9:45method as an architect. And of course, we also need to set up monitors.

9:51We need to understand what our pool members are doing. What services are they

9:55offering up? How are we going to monitor them? Are we going to use a generic

10:00HTTP monitor? Maybe we're going to use some type of custom HTML monitor where

10:06we're checking for certain text being sent back.

10:09Or we're using some other type of generic TCP monitor for a service running on

10:14a TCP port. There's lots of different types of monitors. We need to figure out

10:19how our pool members and nodes are operating so that we can best monitor them.

10:25So now you understand we're really talking about big picture here. Now that we

10:29've gained enough knowledge to understand what these objects are and how they

10:33work and how profiles work and all this stuff. It's really time to put it all

10:38together.

10:40That is what this skill is all about. And a lot of this course is going to be

10:45about that so that we can really start working from a high level and then get

10:50down and granular so we can make good decisions as we can figure our big IP

10:55device.

10:56Alright, well that wraps up this first nugget in the next nugget. We're going

11:00to be talking about understanding dependencies of configuration objects because

11:04we've talked about dependencies for things like profiles.

11:08But now it's time to look at dependencies of those configuration objects, some

11:12of which we just discussed. And we're going to do that in the next night. So I

11:15'll see you there shortly.

0:00Now let's talk about object dependencies. Now in the past we've discussed how

0:06profiles have dependencies and we understand that. For example if you want

0:11to say use the HTTP profile well it is dependent on the TCP profile being

0:18configured as well and there are various other profiles that have

0:22dependencies but we're talking now about objects not profiles okay. So we need

0:28to understand that objects have dependencies and believe it or not we've

0:33talked about one of these already in the past but we really didn't refer to it

0:38as a dependency but it truly is a dependency so let's talk about what that

0:42is. Now the example I'm talking about is the dependency of pool members on

0:48nodes.

0:48So we have a node and a node is just an IP address let's say let's see what

0:54does

0:54one or ten ten one oh one dot eleven okay that is a node. Now a pool member as

1:02we

1:02know is an IP address one oh one dot eleven with a port added to it which is a

1:13socket. Now here's the thing we see these IPs are the same what this means is

1:18there is a relationship between these two the node and the pool member and the

1:26pool member is actually dependent on the node being available. For example if

1:32this node here was to be marked down by a health monitor and it's now showing

1:40offline well this associated pool member here is also going to be marked as

1:47offline and that is a dependency this pool member is dependent on this node

1:54being available if the nodes mark down that pool members mark down we see this

1:59dependency in relationship here. Now let's talk about some other examples of

2:04configuration object dependency. So starting here we're looking at virtual

2:10servers pools and pool members. So we know that a virtual server once

2:17configured in order for it to be up and available well it's dependent on

2:23virtual

2:24addresses that they're configured to use so our virtual servers are dependent

2:31on

2:31a virtual address being available. There we go gotta have that or you can't

2:37have

2:37a virtual server that functions. Now the other thing is we're also dependent on

2:42pools being up and available because if a pool is marked as offline or

2:50unavailable

2:51well that affects the virtual server directly. So again we see here that we

2:57have an object like a virtual server which is dependent on a virtual address

3:01as well as the pool that's associated with it. So another example well I rules

3:09I rules can be dependent on something and that something is profiles. Maybe we

3:17want to use an I rule to identify and replace text in an HTTP request so we

3:24have this HTTP request coming in to our big IP and we want to be able to do

3:33basically a find and replace within the HTTP headers. Well in order for that to

3:41work there needs to be a profile that's being used to allow the I rules over

3:48here

3:48to read that HTTP header and that is yeah that's right the HTTP profile that's

3:57what's going to have to be in place well and that relies on the TCP profile as

4:02well so there's a dependency there but the I rules can be dependent on a

4:07profile

4:07and in this instance where we're doing the find and replace within HTTP header

4:12our I rules are dependent on our HTTP profile so that's another example well

4:19there's yet another one and this is the global traffic manager or GPM if we're

4:26using the GTM for something like let's say DNS load balancing you can define

4:34what's known as a dependent virtual server and this is where we set up the

4:40GTM to do DNS load balancing and when we define this dependent virtual server

4:47what happens is we say you've got this server over here we're gonna say server

4:52one and we've got server two over here now in order for server one to be

4:57available

4:57and running it depends on the fact that server two is also up and running so we

5:04can see a dependency here as well between these objects so the key takeaway

5:11here

5:12is to get back to that architectural mindset when we're talking about

5:16creating and deploying objects we need to understand that those objects well

5:22they can have dependencies which means we need to know what those dependencies

5:28are so that we can make sure that we deploy them properly and we use the

5:33correct

5:33profiles and settings and such so that all the way up the stack from the

5:38dependencies down here all the way up to our primary objects that we have

5:44everything configured properly and again that goes right back to the

5:48architectural mindset so in the next negative we're going to look at

5:53identifying

5:54unnecessary configuration objects because yes as time goes on we don't

6:00always clean up our messes and oftentimes there are things that are well

6:04unfortunately left behind maybe we decommissioned a specific application

6:10we forgot to remove some objects associated with it well they could be

6:13lying around and that's what we're gonna look at how to identify so that we can

6:17get rid of and clean up our house in the next night so I'll see you there

6:21shortly

0:00So I've got a question for you. How do you identify unused objects on your big

0:05IP?

0:05Because we could have in here virtual servers that aren't being used. That's

0:10probably not as likely as some other things.

0:12We could have let's say some pools that aren't being used anymore.

0:15And maybe we have health monitors set up to monitor those pools. And if those

0:20pools aren't even being used, then we're just wasting

0:23resources. So then how do we find unused objects? Well, do we come through here

0:29and

0:29manually map everything out and try to figure out what's going where? Well,

0:35honestly, we should already have that documented somewhere.

0:37But for the sake of time in this, let's say that we don't and we're not going

0:44to do that right now.

0:45How are we going to identify something that's unused? Well, I'll tell you. We

0:49can use iHealth.

0:50And if you remember back, we talk about iHealth, you'd come down here to system

0:55, then we're going to go to support.

0:57There we go. And we're going to generate a support snapshot or a

1:01QK view file, which we've done in multiple times throughout these courses.

1:06And then we're going to upload that to iHealth and then go ahead and analyze it

1:10.

1:10And then we'll jump in and see if we can find some unused objects. So I've done

1:15that. I'm going to jump over to iHealth.

1:17Here we go. I'm going to jump into this one right here. Let me zoom in a little

1:23bit.

1:23So basically, I'm just clicking on the name here.

1:25This is something that I uploaded previously. So we'd have something to look at

1:29.

1:29We're going to zoom in again. And of course, we have all of our standard i

1:32Health information here.

1:34But what we can do is go over here to our config explorer on the left and click

1:39on that.

1:40There we go. And if you look, I'll zoom in a little more. We have LTM, network

1:45and there it is.

1:47Unused objects. That's exactly what we're looking for. I'm going to click on

1:51that.

1:51And survey says, look at there. If I expand this, I've got an iRule that I'm

1:58not using.

1:58And I've got some monitors. Let's expand this. I've got 16 of them that I'm not

2:04using.

2:05Now, the monitors, if they're not monitoring anything, they're not causing a

2:10problem.

2:10The iRule, it's not really causing a problem here.

2:13But if I had pools that weren't used that had monitors associated with them,

2:17or nodes that were not used that had monitors associated with them, well, guess

2:22what?

2:22Then I'm wasting resources by monitoring something that I'm not using.

2:27But this is how we can identify unused objects. Again, here in iHealth, go to

2:32your config explorer,

2:33click on unused objects. And there you go. It's that simple.

2:38In the next, now that we're going to discuss the difference between a virtual

2:43server and a virtual address.

2:45So I'll see you there shortly.

0:00Now let's talk about the difference between a virtual server and a virtual

0:03address.

0:04And we're actually going to see the dependency between the two.

0:07So here we are.

0:08We got a virtual servers.

0:09Let me zoom in a little bit here.

0:10Okay.

0:11With our virtual servers, if I scroll over, we have a destination address.

0:16That is actually our virtual address.

0:18But the virtual server is when you combine these two here, our destination

0:24address and a service port.

0:26So if I was to go in here and look at this, let me go click on this right there

0:31.

0:31When we create a virtual server and define this right here, our destination

0:37address and mask.

0:38Once we create a virtual server and we've defined this, the big IP is going to

0:44go ahead

0:44and automatically create a virtual address that matches this right here.

0:48And it's going to then be on the big IP.

0:51So over here, next to virtual servers, if I click on instead of virtual server

0:57list,

0:57if I go to virtual address list, I'm going to see this 172 16 101 11.

1:02So let's go look at that virtual address list.

1:05And there we go.

1:07And right now I see 172 16 101 11 is green and healthy.

1:12But if I was to do this and go ahead and disable that just like that.

1:17And then I go back to look at my virtual server list.

1:20What do you think we're going to see?

1:22That's right. Look at those.

1:23They are available, but disabled parent.

1:28That means the parent of the virtual server is the virtual address.

1:34There's that relationship and dependency that we've talked about in the past.

1:38So these are now down because their parent virtual address has been disabled.

1:44So let's go fix that.

1:47Let's go back over here.

1:48Let's go ahead and enable this again.

1:50And we'll give that just a minute.

1:53Then we'll go to our virtual server list and there you go.

1:55They're back up and green.

1:57So we see that dependency there.

1:58So let's go now over to the terminal and look at a couple of commands here.

2:03So we're going to do first is we're going to use TMSH show LTM virtual dash

2:09address

2:10and it'll list out our virtual addresses.

2:12There we go.

2:14So we have some information.

2:16We've got the, that's just all zeros there, but we come down here.

2:20This is our internal virtual IP address for internal interface.

2:25We've got one for external.

2:27And we can see here the availability and the state, the state is enabled.

2:32And then we come down here and, oh, this is actually the network up here.

2:39I see that.

2:41And that's why this is showing availability offline.

2:43But down here we have the external IP of our external interface, the

2:47availability status

2:48is available and the state is enabled.

2:50And of course we see some traffic information.

2:53So this is how we can identify the virtual addresses from the terminal.

2:58Let's clear the screen here.

3:00Something else we could do if we wanted to create and enable a virtual address,

3:04create a new one.

3:05We could use TMSH create LTM virtual dash address and say like my address,

3:15app two or something like that.

3:17We've got to give it a name and then address and we could say 172.16.101.50.

3:24Let's say that's on our external and then enabled.

3:27Yes.

3:28And that would go ahead and create and enable that virtual IP address for us.

3:33But we're not going to do that.

3:34We're going to show you the command associated with that.

3:37Maybe we want to delete a virtual address as well.

3:41Then we'd pretty much use a very similar command.

3:44We'd do TMSH delete LTM virtual address and then my address app two.

3:52If that was the name of the virtual address.

3:55That's how we'd go ahead and do that.

3:57Or maybe you simply want to disable the virtual address.

4:01Well, we'd come back here and instead of delete, we'd use the key word here of

4:07modify.

4:07So let's put modify in there.

4:09So TMSH modify LTM virtual address, put the name of your virtual address in

4:14there and then say enabled.

4:16No.

4:17And that would go ahead and disable it.

4:19And actually, let's go ahead and give this a go.

4:21Let's go down.

4:22I'm going to move this down so I can get the name of the virtual IP address

4:25over here.

4:26Let's go over here.

4:27Virtual address list and the name is just the IP address.

4:32So let's do this.

4:33Let's go ahead and put in here 172.16.101.

4:40And it would have to be 11.

4:42Let me move that down a little bit because this is the one we're working on

4:45right there.

4:45101.1726.1.1.1.11.

4:47Alright, let's go ahead and hit enter.

4:49And there it goes.

4:51So now let's go back here and let's just go back and refresh this page.

4:54Virtual address list and there we go.

4:57It's disabled.

4:58So how do we bring it back up?

4:59Well, hit the up arrow and say enabled.

5:02Yes.

5:03Enter.

5:04There we go.

5:05And let's refresh this virtual address list and we're up again.

5:10So that's how we can also use the terminal to manage our virtual addresses.

5:15And of course, the relationship between our virtual address and virtual server.

5:22In the next day, we're going to talk about virtual servers a little more and

5:26verifying

5:27where they are listening.

5:29And we're going to talk about why that's important in the next nugget.

5:32So I'll see you there shortly.

5:33[BLANK_AUDIO]

0:00Now it's time to talk about virtual servers and where they're listening.

0:05And this is because by default, when you create a new virtual server, you go in

0:08here.

0:09And let's look at that. Let's go to Create.

0:12There we go. Let's give it a name. My VS123. Super.

0:17And if I scroll down here to something called your VLANs, let's go down to our

0:23VLAN area here.

0:24Let's see. Looks like we're going to need to go ahead to Advanced.

0:29There we go. And let's go down here. Let's see here.

0:34Where is it? VLAN.

0:37There it is. VLAN and tunnel traffic.

0:43What this is, is the setting that tells the virtual server where to listen.

0:49So right now, by default, your virtual servers, when you create a new one, are

0:54set to all VLANs and tunnels.

0:56What does that mean? Well, it means that that virtual server is going to listen

1:01for incoming traffic on all VLANs and all tunnels.

1:04Well, that's not necessarily a good thing. You think about it.

1:08That means that it's going to set all those different types of traffic that

1:12really it doesn't need to accept.

1:15And it's not going to allow them to necessarily access the virtual server, but

1:19it's going to come in to the big IP here.

1:22The big IP is going to have to filter through all that junk just to find what

1:25it's looking for.

1:27So think about this with your mail. If instead of the mail person delivering

1:31mail to your place of residence,

1:33they deliver all the mail for the county in your place of residence, and you

1:37have to pick through it to find just the stuff that belongs to you.

1:40Everything else gets sent back to the carrier. Well, that's kind of like this.

1:45If you leave it to all tunnels and all VLANs, it's going to listen to

1:48everything. It's going to sort out only what is destined for it.

1:52That's just not good. It wastes a bunch of resources. So how do we remedy that?

1:57Well, we change this. We say enabled on. There we go.

2:00And you enable it on whichever of these is associated with your virtual server.

2:05Now, if it's external like ours are, you would just put external. That way it's

2:09only going to listen on the external VLAN for incoming traffic.

2:14It's not going to listen on anything else. That's what we want. So if we go

2:18back here and let's go back to our virtual server list.

2:23Let's go to our HTTP app one virtual server. And there to do to do to do

2:27advanced already selected.

2:29I'm actually going to just do a control F to search for VLAN. It's a lot easier

2:33. Right there. VLAN and tunnel traffic enabled on external.

2:38That's the way it should be set up. This is best practice configuration. Don't

2:42let it sit out there and listen to everything unless there's a specific reason

2:47you're doing so.

2:49There we go. Next up we're going to talk about persistence. We're going to talk

2:56about actually something called the cache array routing protocol or CARP and

2:59how it can be used within persistence.

3:02And we'll do that in the next night. So I'll see you there shortly.

0:00Let's talk about the cache array routing protocol

0:03karp. Alright, here we go. We're talking about karp and it's

0:09all about persistence because the karp protocol can be used

0:13as a hashing algorithm within

0:16the persistence profiles. Now we're going to talk about what karp is

0:21and why we might want to use it and why we might not want to use it.

0:25Okay, so traditionally when using persistence, so

0:30traditional persistence here is what we're talking about, the big IP

0:34once a client connects to a virtual server running on the big IP

0:39if persistence is being used. We've got our pool members over here.

0:43The load balancing algorithm is run and

0:47the method is used to go ahead and decide a pool member to

0:50load balance to at which point a persistence

0:55record is created and maintained by the big IP

1:00in the persistence record table. That way

1:03future connections coming in are checked against this table

1:07if they match. The packet is then just simply

1:10forwarded to that same pool member and not load balance because when it goes to

1:15the load balance calculations

1:17it uses a lot of resources to figure out where to load balance something to.

1:21So this is more of just a simple forwarding

1:24which is much faster than the load balancing calculation process.

1:30So that is traditionally how it's done. Now,

1:34let's talk about karp. Now if you go into

1:37your profiles for your persistence, this is just a screenshot here,

1:41you can see under the hash algorithm you have either the default

1:45or you have karp. So let's talk about how karp works and how it's different

1:51than the default hashing algorithm. So when karp

1:56is used, state information is not maintained

2:01by the big IP which reduces the amount of memory used

2:05in comparison to not using karp. So that is key here.

2:09The state is not maintained which

2:13allows us to increase the amount of memory that we have because we're not

2:16using memory to retain that information.

2:19But why not? Well, because we don't need to maintain it.

2:24Here's why. The way karp works is it uses the karp

2:30algorithm along with, so put in here karp

2:35algorithm plus the persistence key

2:40which is maintained by the big IP and that will equal

2:44the pool member to load balance two and then that is recorded

2:49into of course our persistence table.

2:53Okay, so so far we see that we are not maintaining

2:58our state. So that allows us to gain back some memory

3:02as far as resources but is there any other benefit?

3:06Absolutely. The other benefit is since karp works by using

3:12the karp hashing algorithm plus the persistence key,

3:16guess what we don't need to do? We don't need

3:21to mirror persistence data. And I should say this is in a high

3:27availability environment. So in order to maintain a

3:31nearly seamless failover between devices,

3:35normally we need to mirror persistence data so that our standby big IP

3:40knows all of the persistence table records. So when that new connection

3:44comes in during a failover, it already knows who to forward that to as

3:49far as the pool member. Well, the thing is because

3:53the persistence key is already being replicated

3:59between big IPs in an HA pair because it's a system data that is

4:05replicated by default. Well, the thing is we don't have to

4:09mirror persistence data which is going to save us a whole bunch of data going

4:14across as part of our mirroring of data. So the question now is

4:20well, why doesn't it need to? Well, it doesn't need to replicate this because

4:25the persistence key is already being replicated. So that standby big IP

4:30already has the replication key. So all it has to do is when an incoming

4:35connection comes in that it doesn't have a persistence

4:38record for all it has to do is run that karp

4:41algorithm along with that same persistence key and it's going to gain

4:46the same solution as to which of the pool members to forward that user to

4:52and then a new persistence record is created. So karp does provide us a

4:57couple of benefits. Number one, it allows us to reclaim some memory

5:02from less resource utilization because we're not maintaining state.

5:06Secondly, we don't need to mirror our persistence data. So we

5:11gain that as well and that's why we might want to use karp.

5:15Okay, but karp does have its disadvantages as well.

5:19Let's talk about that and really it's just one and that it's not very good

5:24at balancing out the low to new pool members.

5:28Now, this would really only come to into play if you

5:32are using something like PGA or Priority Group

5:36activation where we have our active servers and our standby servers.

5:41Well, when you're going and adding new active servers,

5:44this could be a definite disadvantage. It takes it a while to kind of

5:48normal things out. But in the traditional situation, if you're not using PGA

5:53and you just have let's say a pool down here, well, if you're going to add new

5:58pool members, just do it after hours or off hours during non-peak hours

6:02and you're not going to see much of a problem then. So just keep that in mind.

6:07And lastly, let's talk about which persistent profiles

6:12support karp because not all of them do. So when it comes to persistent

6:16profiles,

6:17well, you've got your source address affinity.

6:20That does work with karp. Your destination address affinity as well

6:25and hashing. So your hash. So that really tells us cookies don't work with it,

6:30of

6:30course, because that's cookie-based and universal doesn't work with it either.

6:36So there you go. There is our karp. And in the next segment, we're going to

6:41talk about health monitors and aliases. So I'll see you there shortly.

0:00Now it's time to talk about health monitor aliases.

0:04And we've covered health monitors in previous F5 courses,

0:08but I wanted to touch on the use of alias, addresses, and ports

0:12with health monitors because it really comes into play.

0:15We talk about various scenarios. So let's say we got our client over here,

0:19and our client will connect into a virtual server and of course be

0:23load balanced to one of our various pool members over here. So we got our pool

0:28members.

0:29But here's the thing. Our application, well, it runs on port 443.

0:35That's what it accepts incoming connections on. So that is going to be

0:40HTTPS, which is fine. But it also runs a secondary service

0:47on port 8080 on each of our pool members. Okay?

0:53And that is a service that our web service application

0:58uses on itself. So what this means is we have two things here

1:03that we need to monitor. And each of these must be up in order for

1:08application to function properly. So when it comes to our monitors,

1:12what we're going to probably do is go ahead and configure an HTTPS

1:17monitor. So it will monitor our port 443 and let me actually change

1:22colors there. Let's do that. There we go. Super. It'll make sure that that's

1:26up and responding. And then we could create a custom TCP monitor

1:31for our port 8080 and it will monitor that to make sure it's up.

1:36But here's the thing. If either one of these services goes down, I need to make

1:40sure

1:41that the pool member is marked down as well, that that's associated with.

1:47Just because one of these is up doesn't mean I want the pool member

1:52to be marked as up. It's not either or for the services to mark the pool

1:57members up and available. It's all or nothing. Both of these have to be up

2:01or the pool members down. How do we make sure that's configured? What we do

2:05that

2:06with our alias IPs and port numbers as well as the availability

2:12requirement field within our pool. That has to be set to, and I'll change

2:21colors here, all, a l l and all is the default, but we still want to make

2:26sure that it's set that way and somehow it didn't get changed. So now that

2:30we've discussed the scenario, let's jump into the big IP and see what this

2:34looks

2:34like. All right, here we are in our big IP and what I want to look at is our

2:41monitors for our pool. So let's go down to monitors real quick. There we go.

2:46Now in the scenario we were talking about our pool members were running an

2:51HTTPS service that would accept connections. So we definitely want to go

2:57ahead and configure an HTTPS monitor like we have right here. So if I click on

3:03this monitor here, we can see it's pretty straightforward. What it's doing is

3:08going to check for an HTTPS service running and then I actually have it

3:13running for a specific receive string to make sure that that service is

3:18responding with the correct information. And there you go. It's pretty

3:22straightforward, not a whole lot to it there. So let's go back here to our

3:28monitors and that was for our HTTPS service. But what about the service that

3:35was running on port 8080? Well, in that instance, I'd want to come over here

3:39to custom TCP. So let's go to create name is going to be TCP dash 8080. The

3:46type

3:46here I'm going to find TCP. Where are you right down here off the screen? There

3:52is TCP. There you go. I'm going to come down here to my alias service port.

3:58I'm going to put in 8080 just like that. Excellent. And basically at this

4:05point, I would say because I don't need to define the actual specific address,

4:09I really just need to do the port here. I'd say finished. Okay. And now I have

4:14by TCP 8080. Now what I would do is go over to my pool. So let's go to our

4:20pool now. There we go. And let's say it's our HTTP app one pool. Excellent. And

4:25our

4:25help monitors. I currently have this one. But in our scenario, what I would do

4:29is

4:29I would have app one HTTPS. And I would have my TCP 80. I wouldn't have this

4:35one.

4:36And it would look like that. All right. Super. And I would just go ahead and

4:40update that. Now let me pull those out because I want to put it back to the

4:43way it was. And there you go. And there you go. Okay. There you go. Update real

4:48quick.

4:49Okay. But here's the other thing we would want to do here. I want to go to

4:53advanced right there. And under advanced, we see availability requirement. And

4:59right

5:00now it's set to all. I could say at least. And right. I could leave it at one.

5:04So if I

5:05did this at least one health monitor must be true or available in order for

5:11this

5:11pool and its pool members to be marked as up. But here if I said it to all,

5:16that

5:16means that both the TCP 8080 and my app one HTTPS health monitors would have to

5:22be

5:22successful to mark this up. So that is a key requirement here. Need to make

5:26sure

5:26that availability requirement is set to all when you're using more than one

5:30health

5:31monitor. So that's how we would use health monitors and aliases in order to set

5:36up

5:36more than one health monitor for specific services and such on a pool member

5:41and

5:42making sure that both of those health monitors are successful in order for that

5:46pool member and the pool itself to be marked as up and available. All right.

5:51So that wraps up this nugget. Next up we're going to go through the validation

5:56and take what we've learned in this skill and put it to the test with some

6:00great review questions. So I'll see you there shortly.

0:00It's time for validation.

0:02So let's go ahead and take our newly acquired knowledge and answer a few review

0:05questions.

0:06And of course, well, this is the solution video for those review questions

0:11starting with number one.

0:12So we have a pair of HA, that's an active standby of big IP.

0:18So a pair of big IPs and we are using source address persistence and everything

0:24's working fine.

0:25Well, that's good.

0:26However, we're seeing a large amount of data being replicated from our active

0:31host to our standby host.

0:33Okay.

0:34And it's starting to cause some problems.

0:35So what can we do to reduce the amount of replicated traffic between the two

0:40devices?

0:41Well, let's talk about this.

0:43Number one, enable HTTP compression.

0:47Well, that compresses HTTP traffic between the client and the big IP has

0:52nothing to do with data being replicated between two high availability.

0:56So that sounds like an absolute winner.

0:58Let's just make sure that these other two aren't correct as well.

1:02Let's see, add additional pool members to our pool.

1:05Well, that has nothing to do with replicating data between the two high

1:09availability and the other two high availability.

1:12So that sounds like an absolute winner.

1:14Let's just make sure that these other two aren't correct as well.

1:17Let's see, add additional pool members to our pool.

1:19Well, that has nothing to do with replicating data between big IPs and switch

1:24to hash persistence.

1:26That's just going to change our persistence method.

1:29Thought we're going to do anything for a replication.

1:31So definitely enable carp on our persistence profile is the answer.

1:35Question number two.

1:37All right, true false.

1:38Here we go.

1:39I rules are the one type of configuration object that doesn't rely on any

1:44dependencies.

1:45Well, if we think back, we talked about dependencies between objects and I

1:50rules was used as an example, but it was the opposite.

1:52I rules are reliable because if an I rule is supposed to go into an HTTP header

1:57and do some rewriting, well, that it's going to be reliant on the HTTP profile.

2:04So that is definitely going to be false here.

2:07Question number three.

2:08Which TMS is the one type of configuration that we're going to do with the API?

2:12Well, we're going to do some examples here.

2:15Question number three.

2:16Which TMSH command is used to create a virtual address and enable it?

2:23All right, we've got some options here.

2:25If we think about our TMSH commands anytime we're creating something, we use

2:29the create keyword.

2:31We don't use add or make.

2:34So right now that tells me this is going to be an option.

2:38So if we go through these TMSH create LTM virtual address, looks like an

2:42address name, the address and an address, right?

2:46That looks good.

2:47But let's take a look at the other one.

2:49TMSH create LTM virtual address, my virtual address, the name, address and IP

2:54address, and then enabled.

2:56Yes.

2:57If we look at this, it says which TMSH command is used to create a virtual

3:03address and enable it?

3:05This is the answer down here at the bottom because we have the enabled yes on

3:10there as opposed to this option up at the top.

3:14And again, these answers are all going to be randomized, so they'll be in a

3:18different order when you go through them.

3:20All right, question four.

3:21This is our last question.

3:22We have created a new virtual server and a pool.

3:25The pool members run the HTTP service on port 80 and a secondary application on

3:32TCP port 5555.

3:34We need the pool members to show up as down if any one of these two services is

3:40not running.

3:42We've gone ahead and set up an HTTP monitor for HTTP service on port 80.

3:46Okay, that definitely be step one.

3:48We created a custom TCP monitor for our service running on port 5555 and

3:53assigned it to the pool.

3:55Okay, that sounds good.

3:57That's definitely something needs to be done.

3:59So however, during testing, we see that when one of the services taken offline,

4:04the pool member still shows up and available.

4:08What could be the cause of the problem?

4:09So obviously here, we don't have something configured right because we want the

4:15pool member to be showing us down if any one of these two services is down.

4:19So what are we missing here?

4:21A here, the pool members need to have the health monitors assigned to them.

4:26Well, no, because they inherit that from the pool itself.

4:30You don't have to assign it directly to a pool member.

4:32The nodes need to have the health monitors assigned to them.

4:36No, we don't have to do that.

4:38There is no defined timeout period within the virtual server.

4:42Well, if we're talking about timeout periods, we're talking about accessions

4:45and things.

4:46That's definitely not this.

4:48The availability requirement is not set to all in the pool.

4:53That is the answer.

4:54If you remember, we went into the pool and looked at availability requirements.

4:57By default, it is set to all, but something can happen and they can be changed.

5:01And this availability requirements refers to the idea that all health monitors,

5:06if it's set to all, all health monitors must ring true.

5:11They must be positive and available for those pool members to be marked as

5:16available as well.

5:18And that's what we're looking at here.

5:20All right, that wraps up these review questions.

5:23I hope it's been informative for you, and I'd like to thank you for viewing.

5:25Thank you.