Determining Necessary Configuration Objects

0:00It's time to put your architect hat on and start thinking like an architect when it comes to the big IP and its abilities. So what we're here doing is looking at determining the least amount of objects necessary, and this is really necessary for a given scenario, let's say. Okay, so let's have a quick review of the configuration objects. We've got a little screenshot over here to the right. So of course we've got virtual servers, policies, profiles, cypher, eye rules, pools, 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 monitors, traffic classes, and address translation. And of course, within many of these, like our virtual servers, there are profiles that we're going to be applying in there. So we need to think about those. So really this nugget here and this skill that 's a part of, it's all about thinking like an architect and working on identifying 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 very generic scenario. It's not very defined, so it's going to allow us to really talk through some of our options and what we might be facing. So here's the scenario. Again, very straightforward and generic. It's a new web application. So we know we're going to be dealing with HTTP. It requires load balancing, pretty straightforward, and the application must be encrypted 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 and from the server. Because remember, we've got your client over here communicating with the virtual server on the big IP, which then no balances to a pool member. Well, if only this portion here needs to be encrypted. Well, that means we can actually perform SSL offloading here at the big IP, which helps take some of the burden dealing with SSL off of our member servers there to read.

2:22Do some of the resource utilization. It also allows our big IP here to read layer seven information, all that layer seven traffic going across. So we're able to see everything and make decisions based on that. So now that we see what our scenario is, let me go ahead and make a little room here so that we can kind of walk through this. And we're starting with objects, right? 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 virtual server. So we're going to have to figure out what type of virtual server would work best in this scenario. And honestly, when I look at it, I think of a standard virtual server, because the standard will allow us to have full layer seven functionality, as well as lots of other types of HTTP, let's say advanced settings, things like compression and web acceleration, and using, of course, I rules and one connect, all those things are going to be based on using a CDP. So if I have a standard server, I want to need to then think about some other things that goes into the server.

3:40For example, within the virtual server here, what are my profiles going to be that I'm going to be using? If I'm using a standard server, I know that defaults to the TCP profile. And of course, I'm already working with a web application. I'm definitely going to be wanting to use an HTTP profile as well. And if I'm using SSL offloading, well, then I'm going to need an SSL profile. And 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 here. We know that's going to be the bare minimum right there, as far as profiles. Because of course, we could also look at using compression, web acceleration. Now there's nothing mentioned about that in here, but we need to think about that as an architect, big picture. What are all my options? What is my goal? What's the target that I'm aiming for here? And how can I get there 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 going with that virtual server. There's a couple of things we should also talk about. So we talk about profiles. We should also talk about SNAT. Do we need to use SN AT? That's a great question. So this address translation in SNAT, is there a requirement that the source address remained the same? And that would be a requirement of the application. Because if this equals true , then I cannot use SNAT because it's going to change that source address. I won '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 question. Do I need to use SNAT? And really the answer to that is, when we come and look at our pool members here, these are all of our servers that we have. Well, is there default gateway the big IP? Which means all of the response traffic is going to go through the big IP. 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. No, they actually go over here to this router over here. Well, then we're going to need to use SNAT. Because that's going to ensure that our pool members send their responses to the sessions back through the big IP so they can be sent back out to the client . Okay. Unless we're using something like in-path that we're going to talk about later on in this course. So again, SNAT, that's something else we need to think about.

6:22We talked about our profile, our virtual server type. Now let's make a little room down here so that we can finish up with our virtual server discussion. And the next thing I want to talk about with our virtual servers is persistence . Because we're going to want to use persistence unless there's some reason that we shouldn't use it. For example, what if all of your clients over here, we'll put a bunch of clients here, these are all clients that are going to access your web application. There we go, super duper.

6:52And they all reside in one building at an office. There's a hundred of them, let's say. And they're going to come out to your big IP here. And they're going to access a virtual server. They're going to be load balanced over here to some pool members. All right. Everything looks good, right? Well, here's the exception to that. Think about this. If you are using source address affinity for your precedence, so it's based on the source address, when all these users leave their network, they're going through a gateway is probably 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 those users are going to exit that network with the same source address, which means when that first packet comes to the virtual server, it's going to be load balance and sent to a specific pool member. And also at that point, a persistence record is created with that source address. So then we have another user who decides to go out and use the application. But guess what?

8:06They have the same source address. They're not going to be load balanced because there's a persistence record present. They're going to be sent to that same server. So we see the problem here. Most likely, everyone in this office is going to end up on that same pool member. Load balancing is not going to function like we think it should, because we're using source address affinity persistence in this type of scenario. So this is where we really need to consider what type of persistence we're going to choose to use. And that's why it's important to think like an architect. Think about the big picture.

8:41Who are the clients over here that are going to be accessing my application? Where do they reside? Are they in one location? Are they global? Do they sit in different offices or they work remotely? You know, all these things, as well as the information about how the application itself works. What protocols it uses? All of these things. Again, we're thinking like an architect. So I'm going to clear some of this out here. All right, so for now, that's going to wrap up our virtual server. But there's more. We need to talk about pools and those pools. They need to have members associated with them.

9:18And we need some type of load balancing method that we're going to use. And when choosing a load balancing method is important. We understand what these members are made up of. What are their abilities as far as CPU memory and disk resources are some more faster than others? And are they in the same location? Maybe they're located in different data centers. We need to understand what those are so we can choose the best load balancing method 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 offering up? How are we going to monitor them? Are we going to use a generic HTTP monitor? Maybe we're going to use some type of custom HTML monitor where we're checking for certain text being sent back. Or we're using some other type of generic TCP monitor for a service running on a TCP port. There's lots of different types of monitors. We need to figure out how 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 've gained enough knowledge to understand what these objects are and how they work and how profiles work and all this stuff. It's really time to put it all together. That is what this skill is all about. And a lot of this course is going to be about that so that we can really start working from a high level and then get down and granular so we can make good decisions as we can figure our big IP device.

10:56Alright, well that wraps up this first nugget in the next nugget. We're going to be talking about understanding dependencies of configuration objects because we've talked about dependencies for things like profiles. But now it's time to look at dependencies of those configuration objects, some of which we just discussed. And we're going to do that in the next night. So I 'll see you there shortly.

0:00Now let's talk about object dependencies. Now in the past we've discussed how profiles have dependencies and we understand that. For example if you want to say use the HTTP profile well it is dependent on the TCP profile being configured as well and there are various other profiles that have dependencies but we're talking now about objects not profiles okay. So we need to understand that objects have dependencies and believe it or not we've talked about one of these already in the past but we really didn't refer to it as a dependency but it truly is a dependency so let's talk about what that is. Now the example I'm talking about is the dependency of pool members on nodes.

0:48So we have a node and a node is just an IP address let's say let's see what does one or ten ten one oh one dot eleven okay that is a node. Now a pool member as we know is an IP address one oh one dot eleven with a port added to it which is a socket. Now here's the thing we see these IPs are the same what this means is there is a relationship between these two the node and the pool member and the pool member is actually dependent on the node being available. For example if this node here was to be marked down by a health monitor and it's now showing offline well this associated pool member here is also going to be marked as offline and that is a dependency this pool member is dependent on this node being available if the nodes mark down that pool members mark down we see this dependency in relationship here. Now let's talk about some other examples of

2:04configuration object dependency. So starting here we're looking at virtual servers pools and pool members. So we know that a virtual server once configured in order for it to be up and available well it's dependent on virtual addresses that they're configured to use so our virtual servers are dependent on a virtual address being available. There we go gotta have that or you can't have a virtual server that functions. Now the other thing is we're also dependent on pools being up and available because if a pool is marked as offline or unavailable well that affects the virtual server directly. So again we see here that we have an object like a virtual server which is dependent on a virtual address as well as the pool that's associated with it. So another example well I rules I rules can be dependent on something and that something is profiles. Maybe we want 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 basically a find and replace within the HTTP headers. Well in order for that to work there needs to be a profile that's being used to allow the I rules over here to read that HTTP header and that is yeah that's right the HTTP profile that's what's going to have to be in place well and that relies on the TCP profile as well so there's a dependency there but the I rules can be dependent on a profile and in this instance where we're doing the find and replace within HTTP header our I rules are dependent on our HTTP profile so that's another example well there's yet another one and this is the global traffic manager or GPM if we're using the GTM for something like let's say DNS load balancing you can define what'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 what happens is we say you've got this server over here we're gonna say server one and we've got server two over here now in order for server one to be available and running it depends on the fact that server two is also up and running so we can see a dependency here as well between these objects so the key takeaway here is to get back to that architectural mindset when we're talking about creating and deploying objects we need to understand that those objects well they can have dependencies which means we need to know what those dependencies are so that we can make sure that we deploy them properly and we use the correct profiles and settings and such so that all the way up the stack from the dependencies down here all the way up to our primary objects that we have everything configured properly and again that goes right back to the architectural mindset so in the next negative we're going to look at identifying unnecessary 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 unfortunately left behind maybe we decommissioned a specific application we forgot to remove some objects associated with it well they could be lying around and that's what we're gonna look at how to identify so that we can get rid of and clean up our house in the next night so I'll see you there shortly

0:00So I've got a question for you. How do you identify unused objects on your big IP? Because we could have in here virtual servers that aren't being used. That's probably not as likely as some other things. We could have let's say some pools that aren't being used anymore. And maybe we have health monitors set up to monitor those pools. And if those pools aren't even being used, then we're just wasting resources. So then how do we find unused objects? Well, do we come through here and manually map everything out and try to figure out what's going where? Well, honestly, 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 to do that right now. How are we going to identify something that's unused? Well, I'll tell you. We can use iHealth. And if you remember back, we talk about iHealth, you'd come down here to system , then we're going to go to support. There we go. And we're going to generate a support snapshot or a QK view file, which we've done in multiple times throughout these courses. And then we're going to upload that to iHealth and then go ahead and analyze it .

1:10And then we'll jump in and see if we can find some unused objects. So I've done that. I'm going to jump over to iHealth. Here we go. I'm going to jump into this one right here. Let me zoom in a little bit. So basically, I'm just clicking on the name here. This is something that I uploaded previously. So we'd have something to look at . We're going to zoom in again. And of course, we have all of our standard i Health information here. But what we can do is go over here to our config explorer on the left and click on that. There we go. And if you look, I'll zoom in a little more. We have LTM, network and there it is.

1:47Unused objects. That's exactly what we're looking for. I'm going to click on that. And survey says, look at there. If I expand this, I've got an iRule that I'm not using. And I've got some monitors. Let's expand this. I've got 16 of them that I'm not using. Now, the monitors, if they're not monitoring anything, they're not causing a problem. The iRule, it's not really causing a problem here. But if I had pools that weren't used that had monitors associated with them, or nodes that were not used that had monitors associated with them, well, guess what?

2:22Then I'm wasting resources by monitoring something that I'm not using. But this is how we can identify unused objects. Again, here in iHealth, go to your config explorer, click on unused objects. And there you go. It's that simple. In the next, now that we're going to discuss the difference between a virtual server and a virtual address. So I'll see you there shortly.

0:00Now let's talk about the difference between a virtual server and a virtual address. And we're actually going to see the dependency between the two. So here we are. We got a virtual servers. Let me zoom in a little bit here. Okay. With our virtual servers, if I scroll over, we have a destination address. That is actually our virtual address. But the virtual server is when you combine these two here, our destination address and a service port. So if I was to go in here and look at this, let me go click on this right there .

0:31When we create a virtual server and define this right here, our destination address and mask. Once we create a virtual server and we've defined this, the big IP is going to go ahead and automatically create a virtual address that matches this right here. And it's going to then be on the big IP. So over here, next to virtual servers, if I click on instead of virtual server list, if 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. And there we go. And right now I see 172 16 101 11 is green and healthy. But if I was to do this and go ahead and disable that just like that. And then I go back to look at my virtual server list. What do you think we're going to see? That's right. Look at those. They are available, but disabled parent. That 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. So these are now down because their parent virtual address has been disabled. So let's go fix that. Let's go back over here. Let's go ahead and enable this again. And we'll give that just a minute. Then we'll go to our virtual server list and there you go. They're back up and green. So we see that dependency there. So let's go now over to the terminal and look at a couple of commands here. So we're going to do first is we're going to use TMSH show LTM virtual dash address and it'll list out our virtual addresses.

2:12There we go. So we have some information. We've got the, that's just all zeros there, but we come down here. This is our internal virtual IP address for internal interface. We've got one for external. And we can see here the availability and the state, the state is enabled. And then we come down here and, oh, this is actually the network up here. I see that. And that's why this is showing availability offline.

2:43But down here we have the external IP of our external interface, the availability status is available and the state is enabled. And of course we see some traffic information. So this is how we can identify the virtual addresses from the terminal. Let's clear the screen here. Something else we could do if we wanted to create and enable a virtual address, create a new one. We could use TMSH create LTM virtual dash address and say like my address, app 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. Let's say that's on our external and then enabled. Yes. And that would go ahead and create and enable that virtual IP address for us. But we're not going to do that. We're going to show you the command associated with that. Maybe we want to delete a virtual address as well. Then we'd pretty much use a very similar command. We'd do TMSH delete LTM virtual address and then my address app two.

3:52If that was the name of the virtual address. That's how we'd go ahead and do that. Or maybe you simply want to disable the virtual address. Well, we'd come back here and instead of delete, we'd use the key word here of modify. So let's put modify in there. So TMSH modify LTM virtual address, put the name of your virtual address in there and then say enabled. No. And that would go ahead and disable it. And actually, let's go ahead and give this a go. Let's go down.

4:22I'm going to move this down so I can get the name of the virtual IP address over here. Let's go over here. Virtual address list and the name is just the IP address. So let's do this. Let's go ahead and put in here 172.16.101. And it would have to be 11. Let me move that down a little bit because this is the one we're working on right there. 101.1726.1.1.1.11. Alright, let's go ahead and hit enter. And there it goes. So now let's go back here and let's just go back and refresh this page.

4:54Virtual address list and there we go. It's disabled. So how do we bring it back up? Well, hit the up arrow and say enabled. Yes. Enter. There we go. And let's refresh this virtual address list and we're up again. So that's how we can also use the terminal to manage our virtual addresses. And of course, the relationship between our virtual address and virtual server. In the next day, we're going to talk about virtual servers a little more and verifying where they are listening.

5:29And we're going to talk about why that's important in the next nugget. So I'll see you there shortly. [BLANK_AUDIO]

0:00Now it's time to talk about virtual servers and where they're listening. And this is because by default, when you create a new virtual server, you go in here. And let's look at that. Let's go to Create. There we go. Let's give it a name. My VS123. Super. And if I scroll down here to something called your VLANs, let's go down to our VLAN area here. Let's see. Looks like we're going to need to go ahead to Advanced. There we go. And let's go down here. Let's see here.

0:34Where is it? VLAN. There it is. VLAN and tunnel traffic. What this is, is the setting that tells the virtual server where to listen. So right now, by default, your virtual servers, when you create a new one, are set to all VLANs and tunnels. What does that mean? Well, it means that that virtual server is going to listen for incoming traffic on all VLANs and all tunnels.

1:04Well, that's not necessarily a good thing. You think about it. That means that it's going to set all those different types of traffic that really it doesn't need to accept. And it's not going to allow them to necessarily access the virtual server, but it's going to come in to the big IP here. The big IP is going to have to filter through all that junk just to find what it's looking for. So think about this with your mail. If instead of the mail person delivering mail to your place of residence, they deliver all the mail for the county in your place of residence, and you have 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. If you leave it to all tunnels and all VLANs, it's going to listen to everything. It's going to sort out only what is destined for it. That's just not good. It wastes a bunch of resources. So how do we remedy that? Well, we change this. We say enabled on. There we go. And you enable it on whichever of these is associated with your virtual server. Now, if it's external like ours are, you would just put external. That way it's only 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 back here and let's go back to our virtual server list. Let's go to our HTTP app one virtual server. And there to do to do to do advanced already selected. I'm actually going to just do a control F to search for VLAN. It's a lot easier . Right there. VLAN and tunnel traffic enabled on external. That's the way it should be set up. This is best practice configuration. Don't let it sit out there and listen to everything unless there's a specific reason you're doing so.

2:49There we go. Next up we're going to talk about persistence. We're going to talk about actually something called the cache array routing protocol or CARP and how it can be used within persistence. And 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 karp. Alright, here we go. We're talking about karp and it's all about persistence because the karp protocol can be used as a hashing algorithm within the persistence profiles. Now we're going to talk about what karp is and why we might want to use it and why we might not want to use it. Okay, so traditionally when using persistence, so traditional persistence here is what we're talking about, the big IP once a client connects to a virtual server running on the big IP if persistence is being used. We've got our pool members over here.

0:43The load balancing algorithm is run and the method is used to go ahead and decide a pool member to load balance to at which point a persistence record is created and maintained by the big IP in the persistence record table. That way future connections coming in are checked against this table if they match. The packet is then just simply forwarded to that same pool member and not load balance because when it goes to the load balance calculations it uses a lot of resources to figure out where to load balance something to.

1:21So this is more of just a simple forwarding which is much faster than the load balancing calculation process. So that is traditionally how it's done. Now, let's talk about karp. Now if you go into your profiles for your persistence, this is just a screenshot here, you can see under the hash algorithm you have either the default or you have karp. So let's talk about how karp works and how it's different than the default hashing algorithm. So when karp is used, state information is not maintained by the big IP which reduces the amount of memory used in comparison to not using karp. So that is key here.

2:09The state is not maintained which allows us to increase the amount of memory that we have because we're not using memory to retain that information. But why not? Well, because we don't need to maintain it. Here's why. The way karp works is it uses the karp algorithm along with, so put in here karp algorithm plus the persistence key which is maintained by the big IP and that will equal the pool member to load balance two and then that is recorded into of course our persistence table.

2:53Okay, so so far we see that we are not maintaining our state. So that allows us to gain back some memory as far as resources but is there any other benefit? Absolutely. The other benefit is since karp works by using the karp hashing algorithm plus the persistence key, guess what we don't need to do? We don't need to mirror persistence data. And I should say this is in a high availability environment. So in order to maintain a nearly seamless failover between devices, normally we need to mirror persistence data so that our standby big IP knows all of the persistence table records. So when that new connection comes in during a failover, it already knows who to forward that to as far as the pool member. Well, the thing is because the persistence key is already being replicated between big IPs in an HA pair because it's a system data that is replicated 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 across as part of our mirroring of data. So the question now is well, why doesn't it need to? Well, it doesn't need to replicate this because the persistence key is already being replicated. So that standby big IP already has the replication key. So all it has to do is when an incoming connection comes in that it doesn't have a persistence record for all it has to do is run that karp algorithm along with that same persistence key and it's going to gain the same solution as to which of the pool members to forward that user to and then a new persistence record is created. So karp does provide us a couple of benefits. Number one, it allows us to reclaim some memory from less resource utilization because we're not maintaining state.

5:06Secondly, we don't need to mirror our persistence data. So we gain that as well and that's why we might want to use karp. Okay, but karp does have its disadvantages as well. Let's talk about that and really it's just one and that it's not very good at balancing out the low to new pool members. Now, this would really only come to into play if you are using something like PGA or Priority Group activation where we have our active servers and our standby servers.

5:41Well, when you're going and adding new active servers, this could be a definite disadvantage. It takes it a while to kind of normal things out. But in the traditional situation, if you're not using PGA and you just have let's say a pool down here, well, if you're going to add new pool members, just do it after hours or off hours during non-peak hours and you're not going to see much of a problem then. So just keep that in mind. And lastly, let's talk about which persistent profiles support karp because not all of them do. So when it comes to persistent profiles, well, you've got your source address affinity.

6:20That does work with karp. Your destination address affinity as well and hashing. So your hash. So that really tells us cookies don't work with it, of course, because that's cookie-based and universal doesn't work with it either. So there you go. There is our karp. And in the next segment, we're going to talk about health monitors and aliases. So I'll see you there shortly.

0:00Now it's time to talk about health monitor aliases. And we've covered health monitors in previous F5 courses, but I wanted to touch on the use of alias, addresses, and ports with health monitors because it really comes into play. We talk about various scenarios. So let's say we got our client over here, and our client will connect into a virtual server and of course be load balanced to one of our various pool members over here. So we got our pool members. But 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 HTTPS, which is fine. But it also runs a secondary service on port 8080 on each of our pool members. Okay? And that is a service that our web service application uses on itself. So what this means is we have two things here that we need to monitor. And each of these must be up in order for application to function properly. So when it comes to our monitors, what we're going to probably do is go ahead and configure an HTTPS monitor. So it will monitor our port 443 and let me actually change colors there. Let's do that. There we go. Super. It'll make sure that that's up and responding. And then we could create a custom TCP monitor for 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 sure that the pool member is marked down as well, that that's associated with. Just because one of these is up doesn't mean I want the pool member to be marked as up. It's not either or for the services to mark the pool members up and available. It's all or nothing. Both of these have to be up or the pool members down. How do we make sure that's configured? What we do that with our alias IPs and port numbers as well as the availability requirement field within our pool. That has to be set to, and I'll change colors here, all, a l l and all is the default, but we still want to make sure that it's set that way and somehow it didn't get changed. So now that we've discussed the scenario, let's jump into the big IP and see what this looks like. All right, here we are in our big IP and what I want to look at is our monitors 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 HTTPS service that would accept connections. So we definitely want to go ahead and configure an HTTPS monitor like we have right here. So if I click on this monitor here, we can see it's pretty straightforward. What it's doing is going to check for an HTTPS service running and then I actually have it running for a specific receive string to make sure that that service is responding with the correct information. And there you go. It's pretty straightforward, not a whole lot to it there. So let's go back here to our monitors and that was for our HTTPS service. But what about the service that was running on port 8080? Well, in that instance, I'd want to come over here to custom TCP. So let's go to create name is going to be TCP dash 8080. The type here I'm going to find TCP. Where are you right down here off the screen? There is 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 point, I would say because I don't need to define the actual specific address, I really just need to do the port here. I'd say finished. Okay. And now I have by TCP 8080. Now what I would do is go over to my pool. So let's go to our pool now. There we go. And let's say it's our HTTP app one pool. Excellent. And our help monitors. I currently have this one. But in our scenario, what I would do is I would have app one HTTPS. And I would have my TCP 80. I wouldn't have this one.

4:36And it would look like that. All right. Super. And I would just go ahead and update that. Now let me pull those out because I want to put it back to the way it was. And there you go. And there you go. Okay. There you go. Update real quick. Okay. But here's the other thing we would want to do here. I want to go to advanced right there. And under advanced, we see availability requirement. And right now it's set to all. I could say at least. And right. I could leave it at one. So if I did this at least one health monitor must be true or available in order for this pool and its pool members to be marked as up. But here if I said it to all, that means that both the TCP 8080 and my app one HTTPS health monitors would have to be successful to mark this up. So that is a key requirement here. Need to make sure that availability requirement is set to all when you're using more than one health monitor. So that's how we would use health monitors and aliases in order to set up more than one health monitor for specific services and such on a pool member and making sure that both of those health monitors are successful in order for that pool 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 and take what we've learned in this skill and put it to the test with some great review questions. So I'll see you there shortly.

0:00It's time for validation. So let's go ahead and take our newly acquired knowledge and answer a few review questions. And of course, well, this is the solution video for those review questions starting with number one. So we have a pair of HA, that's an active standby of big IP. So a pair of big IPs and we are using source address persistence and everything 's working fine. Well, that's good. However, we're seeing a large amount of data being replicated from our active host to our standby host.

0:33Okay. And it's starting to cause some problems. So what can we do to reduce the amount of replicated traffic between the two devices? Well, let's talk about this. Number one, enable HTTP compression. Well, that compresses HTTP traffic between the client and the big IP has nothing to do with data being replicated between two high availability. So that sounds like an absolute winner. Let's just make sure that these other two aren't correct as well. Let's see, add additional pool members to our pool.

1:05Well, that has nothing to do with replicating data between the two high availability and the other two high availability. So that sounds like an absolute winner. Let's just make sure that these other two aren't correct as well. Let's see, add additional pool members to our pool. Well, that has nothing to do with replicating data between big IPs and switch to hash persistence. That's just going to change our persistence method. Thought we're going to do anything for a replication. So definitely enable carp on our persistence profile is the answer.

1:35Question number two. All right, true false. Here we go. I rules are the one type of configuration object that doesn't rely on any dependencies. Well, if we think back, we talked about dependencies between objects and I rules was used as an example, but it was the opposite. I rules are reliable because if an I rule is supposed to go into an HTTP header and do some rewriting, well, that it's going to be reliant on the HTTP profile. So that is definitely going to be false here.

2:07Question number three. Which TMS is the one type of configuration that we're going to do with the API? Well, we're going to do some examples here. Question number three. Which TMSH command is used to create a virtual address and enable it? All right, we've got some options here. If we think about our TMSH commands anytime we're creating something, we use the create keyword. We don't use add or make. So 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 address name, the address and an address, right? That looks good. But let's take a look at the other one. TMSH create LTM virtual address, my virtual address, the name, address and IP address, and then enabled. Yes. If we look at this, it says which TMSH command is used to create a virtual address and enable it? This is the answer down here at the bottom because we have the enabled yes on there 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 different order when you go through them. All right, question four. This is our last question. We have created a new virtual server and a pool. The pool members run the HTTP service on port 80 and a secondary application on TCP port 5555. We need the pool members to show up as down if any one of these two services is not running. We've gone ahead and set up an HTTP monitor for HTTP service on port 80.

3:46Okay, that definitely be step one. We created a custom TCP monitor for our service running on port 5555 and assigned it to the pool. Okay, that sounds good. That's definitely something needs to be done. So however, during testing, we see that when one of the services taken offline, the pool member still shows up and available. What could be the cause of the problem? So obviously here, we don't have something configured right because we want the pool member to be showing us down if any one of these two services is down.

4:19So what are we missing here? A here, the pool members need to have the health monitors assigned to them. Well, no, because they inherit that from the pool itself. You don't have to assign it directly to a pool member. The nodes need to have the health monitors assigned to them. No, we don't have to do that. There is no defined timeout period within the virtual server. Well, if we're talking about timeout periods, we're talking about accessions and things. That's definitely not this. The availability requirement is not set to all in the pool.

4:53That is the answer. If you remember, we went into the pool and looked at availability requirements. By default, it is set to all, but something can happen and they can be changed. And this availability requirements refers to the idea that all health monitors, if it's set to all, all health monitors must ring true. They must be positive and available for those pool members to be marked as available as well. And that's what we're looking at here. All 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. Thank you.