Module 4 – Challenge Labs

Modify and Troubleshoot Pools and Virtual Servers

Modify and Troubleshoot Virtual Servers

Troubleshooting virtual servers

Q1. Where would you start?

I would go on the BIG-IP and test connectivity from the BIG-IP to the pool members.

Q2. Attempt to ping one of the pool members. Does it work? What does this tell you?

The ping should be successful. This means the server IP is up and I have basic connectivity.

Q3. Attempt a curl -i against a pool member. Does it work? What does this tell you?

The curl should be successful and you should see the request come back. The application is running.

Q4. Since the problem affects all pool members, what would you suspect as a possible issue?

Since I can see all pool members are functioning I would suspect the monitor is the issue. You could start debugging the monitor directly, or you could put the default HTTP monitor and see if the pool members come up. If they do, then the monitor is the issue and needs correction. You would check the Send and Receive strings. I would use a curl -i (to include the header and response codes) to look for the receive string. If you cannot find the receive string then you will have to alter the receive to something that is returned in the page. In this case the Receive String f5 vlab demo is not the response (the monitor is not case sensitive), but f5 vlab is, so you can simply delete demo.

Note

The default HTTP monitor usually, but does not always, work on an HTTP application.

Q5. Did you correct the issue?

Yes

Q6. Now the pool is working and purple_vs is available can you access the page through the virtual?

No

Q7. What do you think would be the next step in debugging the issue would be?

I would clear the virtual server statistics and try again and see if the traffic is hitting purple_vs. The virtual server statistics should show traffic being processed.

Q8. What command(s) could you use to watch traffic hit the virtual server and leave toward the pool?

I would create two tcpdumps one on the client-side and the other on the server-side. I would want to limit the captures to watch for my PC IP address 10.1.10.6. You will need two terminal windows.

Terminal Window 1 (Client to BIG-IP)

tcpdump -i client_vlan -X -s0 host 10.1.10.6 and 10.1.10.105

(This command will only watch client-side traffic between the PC and virtual server. The -s0 command will dump the entire packet -X command will dump hex and ascii code of the packet. You will be able to see the HTTP request and response in the dump)

Terminal Window 2 (BIG-IP to Pool)

tcpdump -i server_vlan -X -s0 host 10.1.10.6

(This command will only watch server-side traffic from the PC and to the pool. The -s0 command will dump the entire packet -X command will dump hex and ascii code of the packet. You will be able to see the HTTP request and response in the dump)

Q9. Did you see traffic hit the virtual server? Did you see BIG-IP send traffic to a pool member?

You should have seen traffic hit the virtual server in Window 1 and in Window 2 BIG-IP should have picked a pool member and sent traffic to it.

Q10. Did you see the return traffic? If there was no response, what is your step?

No, you did not received a response. Because the BIG-IP is not the default gateway for the server, so the response went someplace else.

• In this case you will need to add a SNAT Pool or do SNAT Automap on the virtual server.
• You could modify the default gateway of the server to point to an IP address on the BIG-IP. The self IP address should be a floating IP in traffic_group_1 so that the default gateway for the server is still available upon failover.

Working with profiles

Q1. Did site work? Why not?

You met with an SSL protocol error, we are coming in on port 443 but there is not certificate exchange.

Q2. Did site work? What did the traffic look like on either side of the tcpdumps?

Yes, the page should have been received. In the tcpdump on the client side the request was encrypted. On the server side the request was readable.

Q3. What was needed to add cookie persistence?

http profile

Q4. What is the name of the cookie inserted begin with?

BIGipServerwww_pool

Upgrading a BIG-IP Device Service Clusters (DSC)

No questions in this section.

iApps and Analytics

Create iApps Analytics

Q1. Did both pool members respond? Why?

No, only one responded because cookie persistence was built using the iApp

Q2. Can you determine which page took the longest to load?

If you select Latency > Page Load Time from the top bar you will find /bigtext.html took longest.

O3. Could you add the pool member? Why?

No, because iApp strictness is on by default and the application can only be changed by going to the iApp application and selecting Reconfigure from the top bar