F5 101 – Application Delivery Controller (ADC) Part 5

29. Introduction to iRules Part 2

All right, as I mentioned, the iriscript consists of operators. Now, this is very common in most languages. You have equals, you have greater than, less than. You also have starts with, contains an answer. Now the statement for beginners or for starters, we always use if and log or pull switch. I don’t know, sometimes it’s not for beginners, but in our example later we’re going to use if and pull. And this is also common in other programming language. So if you’re very familiar with programming, even if you’re not a programmer, you can easily understand the IR language. We also have commands such as TCP payload. We can inspect what’s inside the TCP.

We can also use a specific layer three information. This is client IP address. So this is the source IP address that we can check when we create our rescript. And we’re going to use this in our example in a bit. We can also use Http header commands. This allows us to examine what’s inside the Http header coming from the client browser information. So this is our first example. As you can see, we have an iRule event client accepted, and that we only have two conditions. The first condition is we’re going to look at the client source IP address. If it is 1010 130, we’re going to forward the connection to a specific pool.

Now we have two pools added in our big IP. The first poll is named pull one, and inside pull one we added 172 dot 1620 dot one, listening to port 18. We also have pool two. Okay, same but a different IP address. Now, it’s very straightforward. We have pool one with pool number one, and we have pool two with pool number two. Now, if the source is from 1010 130 IP address, it will forward to pull one. If the source is from ten 10, 140. This is the second condition and it sends traffic to the virtual server. The big IP will skip the load balancing and it will automatically forward the connection to pull number two, where we have a pool member 170, 216, 22. Client one goes to pool one. And if the client sends traffic to the same Vs, the VIP will still forward the traffic on the connection to the same pool for the second client 1010 140. If the Vs received the traffic and it matches this condition, the big IP forwards the connection to the second pool member.

And if the client continues sending traffic to the same BS, the big IP will still continue forwarding the connection to that pool member too. All right, our next idol example involves Http header information. Inside our Http header, we have what we call the user agent. User agent is the information in our web browser. So here we have three examples.

We have Chrome user agent and this is what’s inside Chrome web browser. This is what’s inside the Ie user agent or web browser. We also have firefox. Now, we want to create an eye rule with the condition is if the client browser is Google Chrome, do this action. If it’s an Ie, do this action. So we need to find a word or a string that is unique for every user agent. Okay? So I will not recommend you use Mozilla, because the Mozilla word is available or exist in all of this three user agent. I will also not recommend you to use Windows Nt, because Windows Nt is always available in this three user agent. So we’ll look for a unique value. So for Chrome user agent, we use Chrome. For an Ie user agent, we use Msie. Now, if you’re going to create a condition based on Firefox user agent, I would highly suggest to use the string or value Firefox. Okay? So our I rule for our second I rule looks like this. Look at our event. We use http underscore request event. This means we are now processing deep Http examination. We can now read Http header. So this is the command Http header.

And inside the Http header, we want to look or examine what’s in the user agent value. If the user agent contains Chrome, we’ll do this action, meaning it will not select any pool member from the load balancing or from the default pool configured in the virtual server. Rather, it will just automatically forward it to the first pull member because that’s where this is what has been added to pull number one. Now, if the condition doesn’t match the first, or if the traffic doesn’t match the first condition, we go to the next condition, okay? Why? Because the client is now using an Ie web browser. If the client uses Ie web browser, it will automatically select the second pool, which is pool two with a pool member 170, 216, 22. Now, maybe you’re thinking, what if it doesn’t match the first two rules? Okay? Or the first two condition neither Chrome nor Msie is the web browser used by the client. Well, in this case, if you have Else in this script, it will go to the third pool where pool member three is added.

But if you don’t have this guys, you don’t have an Else statement in your I rule, it will use the default pool configured in your Vs. So this is what’s going to happen if the client use a Google Chrome web browser, sends traffic to our Vs, the big IP look to the IRL, assuming that it is already associated to the virtual server, and it will match the first rule. So the big IP will forward the connection to pool one, where pool member one is added. And if the client sends traffic using the same web browser, the big IP will just continue forwarding the traffic to the first server. Now, if the client and regardless whatever client, as long as they’re using Ie web browser, the virtual server will recognize based on our Irish repay.

You’re using Msie user agent because it contains MSI string. If this is the case, the VIP will just simply forward the traffic to the second pool number because this is what has been added to pool number two. And if the client continues sending to that virtual server, the VIP will just forwards it to the second pool member, right? So that’s our IRL example. For more Irull information, you may visit DevCentral. It’s www. DevCentral. F five and in this portal, you’ll see many different information, different resources. There are blogs, there are forums. People share their scripts, and they have podcasts, and you have a list of Iran useful information. All of the events, all of the commands with different examples. So if you want to be an expert in Irull, I would start visiting DevCentral. F five. com.

30. Configuring iRules Part 1

I’m here in our Fib IP GUI and we have two tabs. The first tab is used for idol configuration. What I have here, we also have our second tab. This second tab is used for Vs and pool configuration. The first thing I will do is I’m going to click Underscore Vs and we’ll go to resources and deselect our source address persistence. I’m going to select Nana and I’m going to go to our client PC to verify load balancing works, okay, to also verify the persistence is disabled. So I’m going to type an IP address of 1010 100. Currently it is connected to server number one. If I hit refresh goes to server number two and then server number three. So load balancing around Robin, load balancing is working properly. So I’m going to do now is I will create three special pools under local traffic pools. I’m going to hit create. I’m going to name our first pool, pool one. And this pool is dedicated to server one or pool number one with a service port of 80. And that’s it. I don’t need to select, monitor or add any other pool because this pool, excuse me, I don’t need to add any pool member because this pool is dedicated to a member 170 216 21. I’m going to select or create the second pool which is port two.

And this time I’m going to use the second server listening also on port 80. Okay, now I’m going to also create the third pool. I’m going to name it pool three and I’m going to add pool member 170 216 23 with a server port 80. There you go. So we have now three pools. OK, the second thing we’ll do is we’ll go to Irul and create our Irish our first Iride script. I’m going to name this client IP address or just simply client IP. And we’ve already talked about this script. You can also download the script under this lecture under resources. The script is very simple and here’s how it looks like. So the advantage gold client accepted. And we have two conditions. If the source IP address is 1010 130 we’ll use pool one. If the source IP address is ten 140, we’ll use pool two. Very easy, right? So I’m going to click finish now. So it is accepted. Let me go back guys.

The good thing about this I rule is if there is, let’s say an incorrect syntax, this will tell us that, hey, the syntax is incorrect, you need to change it. So we cannot just save an incorrect syntax when creating Iru. Now what I will do next is we’ll go to the virtual server configuration again under Vs virtual server list I will again click Http underscore Vs. Now if you look at our configuration, these are more profiles and it rules is not associated on the properties page but under Resources together with the pulls, the persistence. And here we have, I rules.

So we’ll click the manage icon and as you can see, this is our newly created IRA. The name is Client IP. I’m going to hit this check on sign. To enable this I rule. Now, you can enable as many iris as you want, but it is recommended to enable as fewer as possible. One is good, two is good. I suggest three or up is not the ideal number of Irus. Okay, I will click finish. And we have now our eye rules. I’m going to go back to our client PC and this time I will hit the refresh. Now, just to verify, our client IP address is 10 10 40. Okay, this is our client too, from our lap topology diagram. I’m going to hit refresh now. And as you can see, it is not doing any load balancing. The session is always forwarding to one server, which is the pool number 2170 216 22. So our idol works.

It bypassed the load balancing and it selected pool number two, which is based on our second condition. Now I will go ahead and change our source IP address to test the first condition. Okay. All right. So under control panel network connections. I’m going to right click the land, the first lamb, and I’m going to change the IP address from ten dot ten dot 140 to ten dot ten dot 130. I’m going to click OK, now I’ll click close and if I hit refresh, what will happen is this the client IP address will change to 1010 130, and the server should change to server one. Let’s do it now. Oh, that is successful. Client IP address is now ten 130 and the server is now selecting server one. Or the virtual server is now selecting server One. So our Irul works.

31. Configuring iRules Part 2

Now let’s create another I rule. We’re here under our Http underscore Vs and we have our IRL client IP address or client IP associated currently in this Vs. I’m going to remove this first. I will put them to the available and as you can see, there’s no available I rule. I will click enable save. Okay? And let’s first test. If load balancing goes back to round robin, it is now server three. I hit refresh, server one. I hit refresh again, server two and server three. So all three servers are doing load balancing. Okay, so everything goes back to normal. We’re going to create a new IRL.

Under Irilist, I’m going to hit create and I’m going to name this client browser and I’m going to copy paste our script again. I already showed you this script in our lecture. If you want to download this script, it is available on this lecture under Resources. Okay, so the event is Http request. Take note of the event Http underscore request. And what will happen here is we’re going to look our Http header and we will examine we will check the user agent. If the user agent contains a string Chrome, we will select pull. Actually, we can just remove this common since by default we are using the common partition anyway. We also have the second condition. If there is no string Chrome found, I will look for another string, another word Msie. If under the user agent, I see Msie. I will use pool two. If my browser doesn’t have Chrome or Msie on their Http header user agent, I’m going to select pool number three. So what I’m going to do is I’m going to click finish now.

And there you go. We just created our second I rule. I will go back to our Vs and I will click Manage. I will select client browser. Hit this chevron sign. I’m going to click finish. Oh, what is this? We’re getting an error. It says this http request this is the event. It requires us to associate Http or fast Http profile. As I mentioned in our profile discussion, some of the idols requires what? Dependencies. Okay, so our event is Http request and our command is Http. Let’s click it. This is the command under iron, we have Http header user agent. So the Vs will not be able to examine the Http header without what again? Http profile. So this is an example of an ID rule that requires profile dependencies. So I will go back to our properties and under properties, what do we have? Nothing. None is selected on our Http profile. I will just select the system defined Http profile and I’m going to click Update. It’s now updated. And if I go back to our Resources tab, we’ll do it again. Let’s select client browser and I will hit Finish. There you go. Association of Iroh to our Vs is now successful. After I enabled Http profile why again, why do we need Http profile? Because our Iro needs to examine our Http

header you see there from the command. And the Vs will not be able to process this action if there is no Http profile. The Vs without Http profile doesn’t have the intelligence or it doesn’t know how Http behaves in full capacity. So what I’m going to do next is I will go back to our Windows client and our last request connected to server three. Our client IP address is ten 130. Now I’m going to hit refresh. Let’s see which pool member it will select. Oh, it selected server one. Why is that? Well, because our web browser is Google Chrome and it sees Chrome the string itself. Let’s go back to our IRL script. So this is the string. This is the name that we’re looking from the user agent. And since this is Google Chrome yeah, of course there’s a Chrome string or word from our user agent. That is why I selected pull one where pool member is added. Even if I hit refresh multiple times, it will always go to server number one or pull number one. Now I will test another browser. This time I will open an ie. I’m going to open an Ie and I’m going to go to the same Vs with an IP address of 1010 100. Oh, what is this? It didn’t go to server one, but instead it went to server number two. And even if I hit refresh, it will always connect to server number two. Why is that? Let’s check our idol again. The second condition is if we see a word Msie in our user agent, it goes to pool number two with a pool number 170. 216, 22. This is even report 18. Now if I hit refresh, it always go there because of the Irull. Now, just a hint, guys. If you go to the Vs in this configuration, we already have Http underscore pole. But the iRule comes first before pole configuration. And from our IRL script, if it doesn’t see Chrome or Msie, it will use pool number three. So this Http underscore poll is already useless. Even if I deselect and click Update our transaction using Ie, our transaction using Ie is not going to change. It will still connect to the second server. Now, if we go back to our Google Chrome, as you can see that it’s always select and connects to the second server. Now I’m back here in our Google Chrome. Even if I hit the refresh multiple times, it will always select server number one. Okay? And as you can see, even though we don’t have a pool association anymore to our virtual server, our selection to the pool members or to the pool is still working. Now I will show you how to verify if the Irul is working under Statistics module statistics under local traffic. From our previous example, we selected pools. We also tried viewing the persistence records, but we failed. Now we can select I rules. As you can see, we have two I rules client IP and client browser. Okay? You will see that there are 63 total executions from the client IP, from the client browser 696. And the reason why it is always successful? Because under failures and abort, the counter is zero. So our two Irus’examples are working properly.

32. High Availability Overview Part 1

Five high availability. This is a characteristic of a system which aims to ensure a great level of operational performance usually uptime for a higher than normal period. Also take note that High Availability requires less human intervention to restore operation. An incomplete system and Ha specifically for F Five refers to a core system services being up and running on one or in the case of active active two device of two big IP system. We have two pairs.

We have active standby. This is a pair of devices where one device is actively processing traffic, meaning it can receive, it can send traffic to the pools and back to the client. And the other one is not doing anything but it’s ready to take over if failover occurs. Both device synchronize their configuration when I say synchronize their configuration, these are reconfiguration objects such as pools, virtual servers, I rolls but some of the configuration must be remain unique to the system such as Host or hostname self IP address license and so forth. We have also Active pair. These are the two pair of the devices that are actively processing traffic. Both devices are receiving and sending devices, receiving and sending traffic and ready to take over one another if a failover occurs. So what happens is both devices are active, right? But if one fails, obviously all of the load will be transferred to the newly active single device. And like active standby pair, active also synchronize two device configurations. All right, we also have failover communication method. Now I’m going to draw our FYB IP devices. The first one will be there you go. All right, so the first is the hardware failover.

Take note in our M Five B IP device there is a special serial port here and this is what we call the serial port or hardware port where there’s also special cable for this kind of setup. Now, if you use hardware failover, you have many limitations. First limitation is the Vigip appliance can only do active standby, pair only, no active only active standby. And in this special hardware cable it continues sending voltage. This is the only way it can detect that the other device is still up and running. Take note there are no other packets, there are no other protocols but using voltage. That is why they call it hardware failover because there is no other protocols, it’s using hardware communication which is voltage must be in a physical proximity of one another. Well, because there is a cable limitation of 50ft or 15 meters and that’s also another limitation make sure that they’re in the same rack or even not same rack. At least the rack sits next to each other.

We also have another recommendation. We recommend to use hardware failover in the combination with network failover. Well, here’s my take. If you’re going to use network failover, just use network failover. Because for me, if you combine both it will make it more complex. And another limitation for hardware failover is it’s only limited to two devices or devices. While in a network failover, you can add more devices, you can add three, you can have three devices, four device, five device. I believe it’s up to eight devices. So the point is, if you’re going to add not just two devices, forget about hardware failover. And if you are planning to do active setup or active pair, also forget hardware failover. Now, in the lab, obviously, since we’re using a virtual lab, we’re not going to test or not going to demonstrate how hardware failover works. We’re going to focus more on our second option, which is the network failover. Now, the good thing about network failover is the communication runs via Ethernet. So you can use your existing internal network.

You can also use your management network for unicast. Now, the network failover, as I mentioned, is not only good for active standby pair, but also used for Active or N plus one f five devices. N plus one means is N is the number of active like active and the plus one is standby. So Active plus standby is another example of N plus one. If you have four devices, it can also be active. The plus one is standby. Now, we can also have four active device. That’s also possible Heartbeat packets transmitted over the network. So unlike hardware failover, where it uses voltage on the specific hardware special hardware cable, the network failover uses Heartbeat to send over the network. And as I mentioned, you may use your existing internal network, or you can create another network dedicated for high availability packet containers, traffic and device status information.

So we’re going to talk about more on this network failover onto the Demonstration Device Service Clustering or DSC. This is an underlying architecture within our big IP Traffic Management operating system, or Big Aptos. DSC provides synchronization and failover of big IP configuration data. Now, you can configure your big IP devices on a network to do synchronization of all or some of our configuration data among several big IP devices. So this allows one big IP device with a new configuration to push it to the group of big IP device that has joined the cluster. We can also configure our big IP device to fail over to one of many available devices in the cluster.

And lastly, enable mirroring So how Mirroring works is like this. For example, we have an active standby pair and we have an existing long leave application such as Shy or FTP in the active device. So this is standby, this is active with FTP or Sh. If this big IP fails, it’s gone. This will take over the active role, but the long live applications such as SSH or FTP without mirroring will be disconnected. So Mirroring allows to maintain long lip connections if failover occurs. These are the steps on deploying a new high availability or DSC configuration. First thing we will do is prepare our DSC configuration and other requirements on our big IP devices.

This includes host names or device names must all be unique, configuration of VLANs must be completed and self IP addresses as well. We need to make sure that the clocks or the time settings are all synchronized or even if it’s not 100% synchronized, at least we have a very minimal difference. Also we need to archive our UCS or our configuration. This is not a requirement, but this is to make sure that we can restore our configuration if something wrong happens. And lastly, it is recommended to make all of our big IP device passwords all the same.

The second step is configure our DSC communications. We need to make sure that internal network we can reach all of the big IP devices that will join in the cluster again through that internal network. So we can add the internal self IP address of every big IP device that will join the cluster to the configuration, sync configuration, mirroring configuration and the failover heartbeat. Next is we establish device trust. Well Device Trust how it works is to make other devices do mutual authentication through certificate signing and device identity. This is telling us okay, I trust you, I also trust you, you can join to our group and we add these devices as device trusted peer by adding them from our Device trust list by providing the management IP address plus admin username and its password. So it also recommended to test the reachability of the management IP address of all of the big IP devices that will join the cluster. Next is establish a Sync Failover device group.

This will add devices that will participate in the Sync Failover cluster or Sync Failover cluster. Take note, by default the selected is sync only. Don’t choose that, you have to choose Sync Failover. Now this device group allows us to select the trusted peer. So if you have three or four devices you need to trust them first in order to add these devices onto their group. And under the device group configuration, you also need to make sure that the traffic group configuration is all configured correctly. What is traffic group anyway? Well, this is a container of objects related traffic processing and it includes the floating objects like floating self IP address and virtual addresses.

And we’re going to talk about more in this on the Active discussion. Next is or the last should I say is synchronized configuration data. Let’s say we are now completely activated active standby device pair. It is almost complete but the last thing we should do is to make sure the configuration of both devices are synchronized. And to do this I highly recommend to configure the primary device. Always configure the primary device.

So it is possible that the second device has no configuration at all, only the basic like the host name, the self IP address, the management IP address. So the first device or the primary device has all of the configuration. Includes pull, personal servers, nodes, profiles, idols, everything are configured in the primary device. You select the primary device and you push the configuration to the group. But in our case it’s only active standby. So we’re just pushing the configuration on the secondary device.

33. High Availability Overview Part 2

Let’s talk about active standby versus active. I have here a pair of big IP device and the first big IP has a self IP address as well as the floating IP address. We’re also going to add our virtual address. Now, maybe you’re thinking what’s the difference between virtual address and virtual servers? Well, virtual virtual servers has a listener of IP address plus port, while the virtual address is only an IP address. So in our case, Http vs and Https vs, both are sharing the same virtual address. And the virtual address of these two virtual servers are ten 1100. The reason for this, because a virtual address can flow from one VGIP device to the other. Not BS. It’s actually the virtual address. And I’m going to show it to you later in the lab demonstrations. We also have another virtual address. We have 1010 one, one two. And this is for the SSH virtual server. Okay, so here’s how it works.

The client sends traffic to the Http vs. For example, the virtual server will process it by doing the load balancing and selecting a pool member and pull member respond back to the big IP. The big IP respond back to the client. Same discussion we had from the previous lecture. How about on the ChBs, same goes the big IP sends traffic to the virtual address plus four, and it will select a pool member based on the pool configuration. So as you can see, both virtual address is running on the big IP one. So all of the traffic processing happens on the first big IP. The reason for that is because we have what we call the default traffic group. And the default traffic group.

I’ll just use traffic group touch one. This is active on the active node or active device on active. Excuse me. This traffic group one is active on the active device of the active standby setup. So meaning this device is active standby set up. I have the big IP one as the active and the big IP two as standby. How would we know? Well, we’re going to show you later. There is a status on the upper left of the F five big IP GUI. But this is how the active standby works. And what is the second device do? Nothing. It’s just sitting there waiting for the first big IP to die or to go offline. Okay, now under the traffic group one, we have configuration objects. I’m going to list down. This is the virtual address, an IP address of 1010. Let me just move it from here to here. 1010, 1100.

So this is the also have the 1010 one, one two. This is the Ships. We also have the floating self IP address, which is 1010 133 and 170 216 133. So we have four objects and these are all active on the first big IP. Good, right. So in order for us to enable the active pair or the active setup we need to create a new traffic group. I’m going to name the new traffic group TG Two. And not only that, I will also create a few more floating objects.

I’m going to create 1010 233, which is the loading external self IP address of peak IP two. I’m also going to add another floating IP address 170, 216, 233. Okay, so under the traffic group two, I have 1010 dot ten dot two, dot 33 and 172 dot 16 dot two, dot 33. Not only that, I’m going to move this to ten. Well, I’m going to move 1010 100, which is our http BS, to the second traffic group. So it is safe to say that big IP two will be activated or the traffic group two will be first activated in the active device. But we have an option to activate it to the second big IP. Again, I’m going to show you this later. So we created traffic group and we associate these three objects to traffic group two. Not only that, we activated traffic group two to the second big IP.

What will happen is this since traffic group two is active on the second big IP, you will notice first the status or the cluster status or device redundant status will become active. So this is now the start of active pair or the active setup. Now for us to test if the active works, if the traffic goes to, let’s say SSH, okay, the Vs will receive the traffic and then you process it. This will be processed by the first Beck device. Why? Because 1010 102 or the Sash’s is running or active in the first device because of the traffic group one. If there is traffic sent to ten 10 1100. Since this address is now active and associated to traffic group two and traffic group two is active on the second device, it will be processed by the second big IP device. And the big IP device will do the load balancing and forward the traffic down to the pool members. So this is how active standby versus active works.