F5 101 – Application Delivery Controller (ADC) Part 4

  1. Configuring Persistence Part 1

I’m back in our M five big IP GUI and we’re going to do some lab demonstration for our source address persistence under local traffic. I will select virtual servers, virtual server list and let’s hit Http underscore vs. Let’s verify the destination. Ten one, 10, listening on port 80. As I scroll down, you will see there’s not much of the configuration because we accepted most of the defaults. Now, if I hit the resource tabs, you will see that default pool is associated to Http pool. Now, under persistence profile, there is no association. It is selected none because we configure the default. Now, what I’m going to do is I’m going to log in and access our Windows client and says this virtual server, I’m going to type the virtual server IP address 1010 100, and as you can see, it is selected Server two. Now if I hit refresh, it load balance to Server One or pool member one with an IP address of 170, 216, 21. If I hit refresh again, it went to server three, server three again and server two.

So the load balancing is working and we configure our pool to enable round robin load balancing method. Now we’re going back to our virtual server and this time we’re going to enable persistence under default persistence profile, I am going to select Source Adder or Source Address System Defined Persistence. I’m going to click Update and I’m going back to my Windows client. Now, currently in the page it says Server Two. It is connected to the second poll member. As I hit refresh, it should go to another server. Now it’s server one. And as I hit refresh, you will see that it bypass load balancing and it maintains its connection to server one every time I hit refresh. Now, these are multiple sessions because as you can see, the client IP address ports are changing. Hit refresh again, you can see it’s still connected to server one every time I hit refresh.

Now, maybe you’re thinking, how can we really verify if persistence is working? Well, yes, in this page we’re seeing that it’s connected to server One. But in the real world scenario, there is no such thing as application that’s showing us where it’s pool members connecting. Now we’ll go back to our fat GUI. This time we’ll click statistics Under Statistics module Statistics local Traffic under Statistics dots we’re going to select Persistence record. Now, maybe you’re thinking before we already use this. Yes, we selected pools, but this time we don’t want to view pool statistics. We want persistence records. So I’m going to hit persistence record. What is this? It says persistence record statistics display has been disabled in this GUI. And to enable, you have to go to toms’ or the Mossell and run the CLI, the modified Syds statistics. Right now what we’re going to do is we’re just going to go to the CLI, the toms’, and from there we’ll verify the persistence using the show persistence record command. Now I’m here in our f five big IP CLI. I’m currently in the advanced shell and I need to go to toms’ or the TMO shell. I will enter toms’ and I will also need to go to that LTM module and from here I can now run show persistence record. This allows us to view if there are persistence record added. And as you can see, we have the source address 1010 130, which is our client address or client Windows client IP address and it is connected to the Vs. This is our http underscore Vs and selected the first pool member 170, 216, 21. And if I rerun this command, it will shows us the same record from the source IP ten, 130. And maybe you’re thinking is this permanent? No, it’s not permanent. There will be some point that this will be removed.

This is when the timer expired or how can we see the timer or the time out value, the current time out value? We don’t see it right now. How can we view it? Well, we need to add or append all properties from show persistence profile. From here oops, it is actually time out already. Okay, so what we’ll do is we’re going to hit refresh again, right? There you go. And from here, let’s rerun. There you go. So we have now the record. It shows us not only the source IP address value, but also the countdown to expiration currently is five. We also have the virtual server name, the virtual server IP address and the port. And this is the Note address. But to me this looks like a full number because it has a port number. Okay, full name is http underscore pool and again the client address which is 1010, 130, which is our Windows client one.

Now let’s rerun again the show persistence. Now, it’s currently 48 seconds, so we still need to wait more than 100 seconds. Okay, it’s now almost 100 seconds. Sorry, it’s 63 seconds, so we still need to wait 100 more seconds. Now I just want to show you while waiting for the expiration, I just want to show you guys, if you go to local traffic and if you click Persistence, you will see here the system defined persistence and you cannot delete this. You cannot delete it. As you can see, there is no checkbox option. What you can delete and what you can edit are what we call the custom base persistent.

This is what we’re going to create in a bit. Now let’s go back to our CLI and let’s run show persistence record all properties. As you can see, we have 116 seconds. So we still need to wait 60 more seconds. And while we’re waiting 128 we’re still waiting. I have an idea guys. How about let’s play our music. There you go. So around ten more seconds. All right, five more seconds. Three more seconds, we expect this record to be gone. There you go. There’s the persistence record just expired. Now, this is how you view persistence record via CLI. Now, if you want to view in the GUI, we just need to run the command shown in the statistics page.

  1. Configuring Persistence Part 2

Now let’s create our custom source address persistence under local traffic profile persistence. I’m going to hit Create and I’m going to name our new source address persistence, source adder and under persistence type, I’m going to select Source Address Affinity. And as you can see and see, our default timeout value is 180 seconds. I’m going to change this to let’s say 90 seconds. Or maybe I will just increase it to 240. Now the prefix link, I am going to use IP version 424. Now we’re going to test our Windows client IP address and we’re going to use two different IP address. One is 1010 130 and the other is 1010 140. Let’s verify if both IP address will use or will be connected to the same pool member. I’m going to click Finish now.

And just to remind you guys, if you want to change a specific value or parameter, you have to click this custom tick box. Okay? Again, what we did is click the custom tick box and change the parameter based on your preference. Again, the prefix length should be IP version four. And we’re going to use slash 24. I will click finish now. Now we’ll go back to our virtual server. I’m gonna click Http underscore vs under Resources. I’m going to change this to our new source address persistence. I’m going to click Update now, or before I click Update, let’s go to our Windows client.

And what you see here, it is connected to Server Three. Based on our previous verification, this source IP address is maintained to the storage server. Now I’m going to click Update going back to my Windows client. I’m going to hit refresh. Now it is connected to Server One. And as you can see, as I hit refresh, it doesn’t change to other server, but Server One. Right? Now the next thing I will do is I’m going to change the IP address of this client. Currently we’re using 1010 130. And what I will do is I’m going to change this to 1010 140. And based on our theory, since we’re using a new source address persistence and we set the prefix to slash 24, if we change this IP address to 1010 140, since they are using the same three octaves 1010 one, they will be using also or maintain the same server, which is Server One. So what I will do is I will verify the IP configuration.

All right, so it’s ten 140, it’s all good, and I will open the same web browser and I’m going to hit Refresh. Okay? And as you can see, it didn’t load balance. Instead it maintained a connection to Server One. So I’ll keep refreshing and I will go back to our tmSh. All right, we’re back in our tmSh. And in our previous result, it returns zero records because we’ll let the timer expired. Now I’m going to run the same command, show persistence, persistence record and I’m going to remove all properties. We want to see the two source IP address ten 130 and ten 140. I’m going to hit it down and look. We have a source address of 1010 10. Now, the reason why we see this source address is because we are using a prefix of 24. Record shows that it is connecting to our Vs 1010 100 and selecting the same server 170 216, 21. And that’s how we create a custom persistence with a prefix value of 24.

  1. Configuring Persistence Part 3

Now let’s configure cookie persistence. So I’m here under local traffic, virtual servers, virtual server list, and this time we’re going to use Https underscore Vs. Now I’m going to click Https underscore Vs. And if we verify our configuration, we have the destination IP address 1010 1100. Same with our http underscore BS. But the difference is the port is now using four, four, three or Https. Now if you go down below from the many profile configurations, the only profiles we set are SSL profiles and SSL profiles. One is client, one is server and we use the system defined client and server SSL profiles. So everything else are all defaults. Now if we go to the Resources tabs, you see the Https pool underscore pool is the one that we are using and nothing else. For the persistence profile, it is set to none, both the default and the fullback. Now let’s test the load balancing.

I’m now in my client PC and if I enter 1010 1100, this is Http. Let’s add https ten 1100 https okay, so I’ll just have to click Proceed because we are getting an Https error, all right, or certificate error. Excuse me. Now as you can see, it’s currently connected to server one. And let’s ask first the load balancing. If I hit refresh, it goes to server two. Refresh again, it goes to server three. Another refresh, it goes to server one. So it’s low balancing on all full members, server one, two and three. Now we’re going to enable cookie persistence. We’re not going to create custom based cookie persistence.

We’re just going to use the system defined cookie persistence and it is available when you click the select box. So I’m going to select cookie. Okay, so this is our cookie persistence. I’m going to click Update now. Oh, what is this? It cannot be updated. Why? Because cookie persistence requires what? Profile again? Okay, if you recall, we have what we call profile dependencies. And as I mentioned before, cookie persistence require Http profile. An Http profile require a layer for profile TCP. So let’s go to the properties again. And as I mentioned, we did some configuration default except for the client and server SSL profile under Http profile, it is set to none.

Now we selected http profile now as I mentioned again, by default when you create a Vs, it is already selected TCP profile. So there’s nothing much to change under this layer for protocol profile. So it’s TCP Http. And let me click Update first before we update our resources for the persistence. It’s loading. I’m going to click Resources now and I’m going to click again Cookie and click Update. Okay, now we successfully saved the configuration. So we go back again to our Windows client. Now it is connected to server one. If I hit refresh, it will do a load balancing and from there it will maintain that particular server. Okay, I’m going to hit refresh now, all right. So it’s now connected to server three. If I continue hitting refresh, it doesn’t go to any other full member. But it’s stuck in server three. Not stuck, it’s maintaining the connection to server three.

Okay, so even if I hit refresh multiple times, it’s always connected to server three. And it is using cookie persistence. It doesn’t use any persistence record like our source address affinity. And to show you the value of the cookie or the cookie information, all I need to do is we go from our browser. This is a Google Chrome. So I’m going to show you how to do it in Google Chrome. So I’m going to select this three dotted icons on the upper right and we’ll click Settings. There you go. It will open a new tab. And under Privacy and Security, I’m going to click site settings. And under site settings, we’ll click cookies on site data. Okay, now do you see the option here? See all cookies and site data. We’ll click that and as you can see, we now have a cookie from 1010 one 10, which is our Https underscore Vs. If I click this cookie, it will tell us the name of the cookie.

The name is Big IP server https underscore Pool. Take note, this is the default cookie name and it’s based on big IP plus the pool name we have configured in our virtual server. So by default, the cookie information is not so secure. And let me add more on that when it comes to insecurity. So this is the name and look at the content. This allows us to know what pool member our Vs has selected. Well, you can see it is decoded. But I will tell you this is not very secure. You can always decode these values. Okay, the main is 1010 100. And that’s it. Now I will show you how to decode this. Before, there are some sites available on the Internet that you can just copy and paste this and the website will decode it. But now there is an easier way. This is actually a Google Chrome extension. If you search Google, you can search for Google Chrome F five cookie encoder or decoder. Decoder. There you go, decoder. Now the first result, big IP cookie decoder. Click that.

So this is an extension. It’s already added in our browser here. So we don’t need to add it, we don’t want to remove it because I want to show you what’s the value of the selected pull member. Anyway, if you’re doing your own lab, you may just add this, the big IP cookie decoder from Google Chrome web browser. And this is what we’ll show you. This is how it works. We already know that our server is connected. Well, our Vs is connecting our client PC to server three. Now I’m going to show you the value of that cookie. If I click this icon, this is our big IP cookie decoder. Which we added in our Google Chrome web browser as an extension. It already identified our cookies. The cookie name is again the IP server and our pool name https underscore pool. If I click this it shows us the pool member 170 216 23 listening on port 43. Sorry. Now is this the same as this? Yes, this is the pool IP address plus the port number. So again this is the default cookie and as you can see it’s not very secure. It’s not part of the scope how to encrypt the cookie or change the cookie name, but there’s feature can be enabled using custom cookie persistence and custom http profile.

  1. Introduction to iRules Part 1

What is an iro? Well, an Iro is a scripting tool based on TCL or tickle that allows us to create custom functionality and apply it to our virtual server. An Arul is used when the functionality or you want to create a task that is not available in our big Ipcli or GUI. Now, we can also use for custom logging in other devices like Cisco, router switches and firewall. They have what we call debug. Okay, this is a tool that provides real-time event information. You will see what’s going on like traffic protocols and other processes. Now, big IP doesn’t have this tool, but we can use custom logging. So you can log an event based on something or condition. Okay? We can also use Irull for custom or automated selection. So you can create an Iro and based on the condition or rule, it will choose a pool member and a server for you. So in short, it will bypass load balancing.

Now, Irol is also commonly used for, as I mentioned, customize the pool and server selection. It is also used for Http to https redirection. So if you’re familiar on other websites and if you visit a URL and by default your web browser will use Http and all of a sudden it redirects to Https. So that function is also available in Fib IP and there’s already an iron or system defined Iran that is available in your IRL configuration. So you don’t need to create this. We can also use Iru for universal persistence. This allows us to persist our connection to a server with the use of hidden values. This can be a parameter value or something in your URL or Uri. You can also use Irol for intelligent snap. So based on the condition, it will select a specific translation address every time you send a connection to your Vs down to the servers. Now, we have components in our Irol.

We have first the event. This defines the activity that triggers the Iro. And event can be based on client connection or if the client starts sending data. We also have operator. This is used in conditional expression. Now, here is our conditional expression and it is inside the event. The IRL will always trigger inside the event. So event is very important. You should know what event that you will use inside the event. Again, there’s a condition expression and this is where you use the operator and the command. We have two commands. First is the command where you want to get the information. It can be Http header, it can be based on TCP or IP and both operator and command is configured or written inside the condition expression. If that condition matches, it will do an action.

What are this action? It can be pull selection, it can be redirect, logging or snap translation. Okay, there are many different kinds of action. Now in this example, it’s very straightforward. If the first condition matches, it will do this action. If it doesn’t match the first condition but it matches the second condition, it will then process the second action. Now if it doesn’t matches the first and second, the default action is this under the L statement the next question is what kind of I rule should we use when we are creating our script? So we’re going to talk about the traffic process and from which process we can use a specific Irol event. Now let’s say the client starts sending data, so it will start with TCP three-way handshake, CP three way handshake. As the TCP three way handshake completed and this session is start to be created, this Iru event is called Client Accepted and from this event you will be able to utilize and gather information from the network and transport layer. So you will get the IP information as well as the TCP information. Now, as I mentioned, after the TCP three way handshake the session is created and it will start sending data to the vigil.

As it starts sending data, the big IP or your I rule can now process and in your script you can now use an event called Client data. So you will get some data traffic. But this is not specific to any application. There is an event that is very common, this is specific to an Http application. And for Irul to be able to examine and get the values of Http header, you should use an event called Http request. Once the big IP received the data, it will do server selection from the load balancing method and the big IP will start creating sessions as the TCP three way handshake is completed.

The Irish event that we can use on the server side is what we called Server connected. And if the big IP starts sending data in this case to the pool member one, the server will respond back to the big IP and the big IP will receive it. Now, the big IP or your IRL script can now process an event called Server Data. This is non specific data from many different application, but if you’re using a specific application same as on the client side, we use Http request. The response from the server backed to the big IP is called Http risk ponds. So there are many irrelevant events, but I would say this is the most common.

img