F5 101 – Part 3: Maintaining Application Delivery Controller (ADC) Part 3

8. Device and Software Upgrade Demo

Now I’m back in my m five big IP GUI. And this time we’re going to upgrade our software image. Now I’m going to log in with my user admin, the password of Admin One. Now under system module, we select software management. And as you can see, the current version one is 13 one three, and it’s residing in our boot location, HD one. There is no other image available. That is why we need to import our new image. So we decided to just use version 14 one two. I’m going to select it from my desktop. I’m going to click Open now, I’m going to click Import. Now, it’s currently importing. This may take more or less a couple of minutes. It’s almost done. All right, we’re done now let’s go and verify if we have already imported the big IP version 14 one, two, three.

So we have it here under Available Image. And what we need to do next is install this image. All we need to do is click this tick box and click this button, install. As you can see, we are asked to specify and select which hard disk or HD. I will choose one because this is the only available. The second HD is not even available. It’s zero gaga. And we’ll just select this. But since the first volume is already taken by our first big IP software, version 13 one three, we’re going to specify the second volume. So I need to specify too. I’m going to click Install now.

Now, it’s currently installing. All right, it’s already 95%. And just to give you a review, guys, we imported our new software Bibi version 14, dot one, dot two. And we are currently installing it in our boot location, HD one two. And in less than a minute, we were able to completely install this new software. But we’re not done yet. Okay, we just imported and installed this new software image, but we still need to activate it. So I’m going to show you how easy it is to activate this new software.

All right, we’re done. So I will go to boot locations now. And as you can see, we have our new software image installed, version four one two, and it is currently again, installed in HD one two. So to activate this, all we need to do is click this link. And as you can see, it verifies that if we want to activate from 13 one three version to 14 one two version. And here’s what we’re going to do. We’re going to select installation configuration. Yes. So that our configuration objects will remain existing, such as virtual server pools, idols and many more.

So now I’m going to click Activate, and we need to confirm that we want to go to our new volume click. Okay, during the activation process, our big IP is required to reboot. So now we are rebooting the big IP. This may take a couple of more minutes. The rebooting and software activation has been completed. Now let’s log in to verify if our software upgrade has been successful. So I’m going to log in as Admin, the password of admin one and let’s go to our system module and we can verify under device under configuration. And then I will click general. As you can see, the current version that we are running is big IP 14 one two three.

Now, if I go to software management image list you will still see the previous version, the version 13 one three, but it’s not currently active. What is currently active is the new image, the 14 one two. You can also verify if the software upgrade has been successful via toms’. So I just logged in in our CLI TSH and under system module I can run show version. As you can see our current version is 14 one two and I can also do show software status. There you go. As you can see we have two imported images. These are 13 one three but it’s not active. The one that is active active is the 14 one two and our software upgrade has been completed. Unsuccessful.

9. Traffic Flow interpretation Part 1

I have here a client with an IP address of 1921-6811 and a server with an IP address of 109 21681 100, listening to port 80. Since this is port 80, this server is running an Http application. Now, assuming that all of the connectivity is good, the physical and the client can reach the server. And the client is about to send a request to the Http server. So it already completed the bits from layer one to layer two. The frames packet it encapsulated already in the transport layer, layer four. Now, the client starts initiating TCP scene and the server receives it with a reply of scene at. Now, this is the time that the client will also get a client random port from the range of 1024 to 65535. The client completes the TCP three-way handshake and this completes this session. Now, the client can now send data. Since this is an Http server. The client sends an Http request, the server receives it and it will respond within Http respond. Now, this is how a web application completes its transaction.

The ultimate goal is for the client to see its webpage. The previous example is a transaction from client to a server. It can be a directly connected transaction or in between layer three devices. Now what if if we have a client and the servers are behind the F five big IP device? Okay, let’s check. We have the pool numbers and we have three servers listening all in port 80. And we form a pool. We add all of these three servers to a pool. We name it http pool And Http pool is associated to our virtual server. Now, associating pools allows the big IP device to know there are external servers. And this is where our big IP forwards the traffic to.

Now the client in this time it will send a request to the virtual server and the virtual server receive the usual the TCP three way handshake. It will reply with the Scene app and the client completes with a TCP app plug. Now, this is the time that the client will start sending data. Since this is a web traffic, it will send Http request. The big IP will receive it, it will process it, will check the load balancing and will select a pool member. This time it selected the first pool member. 170, 216, 21, 418. Now, this is on the server side. We will also do a TCP three way handshake. Since this is a full proxy appliance, we separate the session from the client side and the server side.

Now, the big IP doesn’t only do the TCP three way handshake. As the three way handshake completes, it will also forward data traffic. In this case, it’s also an Http request. Now, as the server receives it and processes it, it will respond back to via VIP. And this is what we call Http response. Now, the big IP receives it and forwards it back to the client. Now here’s the summary of our traffic flow. First, on the client side, the client initiate with a TCP scene. The virtual server will reply a scene app. The client completes the TCP three way handshake with an app flag and this is the start where the client sends data. Since this is an Http server, it sends Http request. Now on the server side the VGIP select a pool member and initiate TCP three way handshake sin synac. It forms a session and it forwards Http requests the data traffic to that pool member. Now, as the server receives it, it will respond using Http response with all of the Http contents to the big IP or on the server side. And the big IP will respond back to the client with the same content coming from the server. Now let’s talk about IP addresses and how they are being translated. First, we have a client and it sends traffic to our virtual server. And as you can see, the source is 1010 130 with a client Ford, in this case 2001. It is communicating to our virtual server, which is the destination. Ten one dot 1100, listening on port 18. Now the big IP process the traffic and from the big IP perspective as it selects a pool member, the source it will use is the same source, the regional source, the client source 1010 130, port 2001.

Under this location now is the pool member that it has selected. 170, 216, 21, listening on port 80. Now for the response. Since the server received the traffic from the big IP, the source now will be the Server’s IP address and port which is 172, 1621, port 80 and it will reply back to the original source IP address, which is the client IP address 1010 130, listening on client port 2001. Now the big IP will just forwards it back to the client, the original source, which is ten dot, ten dot, one dot 32,001. But look at how the IP address has been translated. Okay, it returned or it translated back to the virtual server IP address, which is ten dot, ten dot, one dot, 1100 or 80. Now, on the client side or on the client perspective, it doesn’t need to know there are servers behind the big IP. So on his perspective, he’s just communicating on the vertical server IP address 1010, 1100, port 80 and he is expecting a response from the same IP address and port. So that’s how the translation is happening. Now to summarize, we have the source on the server side of IP addresses.

So this is the client side, this is the request with the client request traffic to the virtual server and this is a client side. We also have the server side. This is also a request, but this time it’s the big IP forwarding the traffic to the pool member. This is a server site and as the pool member receives the data coming from the big IP, it will respond back. This is the response and this is the server side. Now, the big IP will reply back to the original client. And as you see, the IP address has been translated back to the virtual server IP address in port. So this is the first transaction, and the second one is the server side. The third is when the server responds back by big IP. And the last one is when big IP completes the response back to the client. We may experience issues in a real-world scenario.

Why? Because these servers, it doesn’t have a default gateway or normally it doesn’t have a route back to the big IP. Usually you have a layer three device here, it can be a router or a layer three switch. And this serves as the default gateway of all of these servers. So what happens is when they receive the data from the big IP, they will say, hey, the source IP address is 1010 130. I don’t have this in my routing table. I will send it to our default gateway, which is again not the big IP, but an external layer three device such as router. Now, what happens is if the server reply via the router, obviously the session will be broken and it will not most probably receive the by the client. Okay, so the solution for this is to make sure the server responds back to the big IP.

10. Traffic Flow interpretation Part 2

This is what Snap or Source Network address translation is all about. Now we have a client that is sending requests to our virtual server and this is the same the source IP address, the client IP address with an IP of 1010, 130 and the station is the Vs IP address 1010 1100 listening on port 80. As the big IP received the request it will process it and select a pool member. Now the pool member, as it receives the request, it changed the source IP address to the big IP internal self IP address which is 170, 216, 131 and in this case we just use automapp that it will automatically use self IP address or if there’s a floating self IP address that will be more preferred. Okay? Now the server as it sees the request, it will process it and it will force to respond back to the big IP.

This time there will be no layer three device such as Router or Firewall because the server or the pool member and the internal self IP address are in the same network we are using 16 anyway. So the server is automatically responding back to the big IP internal self IP address. As you can see, the source is 170, 216, 21, pool number one and the destination is the self IP address 170, 216, 131. Now the big IP needs to send a response back to the client and same as previews, the IP address is translated back to our virtual server.

So in the client perspective again he is just communicating or sending transaction to the virtual server. So he is expecting a response from a source of virtual server IP address and port. Now, just to summarize the IP addressing and the translation both on the client and server side, this is our request and this is on the client side and this is what client sees send a request to our virtual server ten dot, ten dot, one dot, 100 okay? And this will be processed by the big IP as it selects a pool member. In this case, this is where the Snap kicks in. It is now changed to the internal self IP address 170, 216, 131. Now, as the server received the request it will respond back to the VGIP again, no more layer three device because the source IP address which is the big IP, is in the same network of our server. So this is the response and this is the server side.

Now the big IP will respond back to the client and as you see, the source has changed to the virtual server because on the client’s perspective he sent a request to the virtual server and he’s requesting us respond back to the same destination IP address which is ten, 100. This is the first transaction, the second, the third and the response back to the client. Now let’s compare Snap and not Snap or our source network address translation uses one too many mapping. Auto maps is the type of Snap that we’re going to use later. And this translates server side source IP address to the internal self IP address. Or in our case, in the lab, we’re going to use floating IP address.

And in the real world scenario, if you have too many transactions, because you have not just thousands of clients, even hundreds or millions of clients, you may experience port exhaustion. Well, this may occur because the port is only 16 bit and the maximum connections we have is around 64,000, 1024 to 6535. And if it reached that 64,000 maximum, it may drop the succeeding connections. So the solution for this is to use snap pool and add not just one, but multiple source IP address. Or you can also use more floating IP addresses. We also have network Address translation or map. Well, not in fib IP. This is one to one mapping. If you compare it to our previous discussion, this is analogous to the static map. We know where we map the server excuse me, where we map the server IP address to another IP address that can be routable or it can be exposed on the external network. It’s also bi directional. And take note, all ports are open.

And this can be potential security risk. The VIP provides graphical interpretation of system traffic and other critical information. This can be found under statistics, performance reports, traffic report, and I’m going to show you more on this later. We also have SNMP or simple network management protocol. This is an industry standard protocol for monitoring devices on IP networks. Now, we use SNMP to monitor not just few devices, but can be hundreds or thousands. And this is very common in most industries, in most organizations. And we monitor many different things such as interface of our network devices, such as router switches or even F five big IP devices.

We also monitor routing and traffic reports. We also monitor VPN tunnel excuse me, and some performance of our network devices. Not only network devices, but also performance of our servers and applications. We also use SNMP to monitor security related events. SNMP is very common in many appliances. For big IP, we can configure SNMP traps an SNMP agent that sends data to an SNMP manager. Now, this is how it looks like on the SNMP manager perspective.

And we can translate this because in the exam they may provide a graph like this with questions related to the graph. So we need to do some interpretations. So in this case, we have total number of connections, right? And there is a point here where it reached the maximum. If we ask, or if we are asked what is the maximum connections on this duration, it’s around at this point, and this may be around 213 to 216 connections. We may also be asked for an average connection on this duration. The average is somewhere around this point. And it’s very close to 162, but it’s a little above. So I would say this is 165 or above. Okay. We may also be asked, what is the current connections or the total current connections? So we should look at this side, and I say this is also close to 162, a little higher than the average. So I would say around 170 or more. Bye.

11. Traffic Flow Interpretation Demo Part 1

I am back in my Fib IP GUI and let’s check our virtual server configuration. We have Http vs. And if I verify our translation configuration, I just scroll down and as you can see, source address translation is set to none and we can test this. Actually, I will go to my Windows client and I’m going to initiate a connection to our Http virtual server 1010 10, and I can send multiple requests. All I need to do is hit refresh multiple times. As you can see, the client IP address doesn’t change. It is always ten 130. And as you can see, it’s also load balancing to the three servers. Server one, server two. On server three, we can actually click this link to just also verify that the source address doesn’t change. It’s always 1010, 130. Now, I’m going to also open multiple SSH connections. Okay, now we have two transactions. We have SSH, excuse me, two applications, but multiple transactions. Multiple for SSH, but on Http we tried multiple transactions, but Http is not a long live application.

So some of those transactions is already gone. I’m now in my team in Sikh and I will go to the Sys module and we’re going to view all of the connections. As you can see, we have more than eight SSH connections and one Http connections. This is the client side. And as you can see, our client IP address is ten, 130 and the server, which is the virtual server is 102 for SSH, 100 for Http. This is the server side. And as you can see the server side, the source IP address is still the original client source IP address and the destination is the pool members it has selected. And this is changing from pool member one to pool member two, pool member 3172, 1621, two and three. Okay, so there is no address translation that is enabled yet. So we are expecting on the server side, it’s still the client source IP address. Now let’s go back to our GUI and this time we’re going to change the address translation to Automap down here by default, selected none.

And I’m going to use AutoMap. Quick update, I’m back in the Windows client and this result is from the previous testing. If I click Refresh button, we are expecting the source address to be changed to 170, 216, 133, which is the floating IP address on our internal VLAN. Okay, I’m going to hit refresh now. There you go. If I hit refresh multiple times, you will see that the source IP address doesn’t change. Now if I go back to our original web page, you will see here that the source IP address is again, doesn’t change. It’s always 170, 216, 133. And this is multiple different connections because the client ports are always changing. Now back in our tmSh, I’m going to run the same command show connections. And this time the transaction to our 1010 100 changes its source IP address on the server side to 107, 216133. But all of our SSH connections is still the same. It doesn’t change. Since this is a long lived connection, we are still using the same session we have from this previous output. Now I’m going to create another virtual server. We’ll click Virtual server list and I’m going to create our Https vs. I will use 1010, 1100, port, four, four, three. And I’m going to create also our pool. Because we still don’t have Https pool. I’m going to add three pool members 1213. I’m going to click Finish now and let’s verify. The name is correct, the destination address is correct, the service port is correct, and let’s click Finish Now. All right, so we have now three virtual servers.

Now let’s test our new virtual server. I’m going to open a tab and I’m going to specify the IP address. But this time we’ll be using Https protocol and we get the certificate error. All I need to do is click Proceed and there you have it from our previous testing and discussion. If you see red, this means it is Https on the server side. So the servers is responding with Https four, four, three. Now, as you see the source, it’s still ten dot 1010 dot one, dot 30. If I click source IP address. Okay, it’s still ten dot, ten dot one, dot 30. Why is that? Because Snap is not enabled. Now we’re going to enable Snap on our tmSh. Here in tmSh we will edit our configuration objects.

This time is the virtual server. So I’m here in the sys module. I’m going to exit and go to LTM module. And I’m going to also go inside the component virtual or the virtual server and edit Https. Sorry, modify is the correct command. I’m going to modify Https underscore vs and I’m going to change the source address translation.

The type is AutoMap. There you go. And I’m going to do. Save sysconfig. Now we’re saving the current configuration to our configuration files. Now let’s go and test our address translation. Now I’m back in our Windows client and this is http vs https. Excuse me. And it was 1010, 130. If I hit refresh, it should change to the floating IP address, which is 170, 216, 133. I just hit refresh. And there you go. Okay, so our CLI modify command works. Now I’m going to change it back to source address translation to be disabled or to set it to none. I’m back in my tmSh and I’m going to use the same command that we executed. Modify https underscore Vs source address translation But I’m going to change the type to none. Okay, if I save our configuration to our system, this can configuration files. We will now test if the configuration that we change is taking effect. I’m going to hit refresh now. Now the source address is back to the client source IP 1010, 130.