Common F5 BIG-IP LTM Troubleshooting Scenarios

Most BIG-IP LTM issues fall into a handful of patterns. Recognising the pattern early saves hours. Below are six of the most common, with the first things worth checking for each.

The commands below are examples for orientation. Replace the placeholders with your own object names and addresses, check the syntax against the documentation for your BIG-IP version, and be careful running anything on a busy production system.

1. Pool members are marked down, but the server looks fine

The health monitor decides whether a member is up, so start with the monitor rather than the server.

• Check the monitor type. A TCP monitor only proves the port is open. An HTTP or HTTPS monitor checks an actual response.
• Check the send and receive strings. A receive string that no longer matches what the application returns, for example after a release, will mark every member down.
• Check the Host header. Many applications return an error or redirect when the request has no Host header or the wrong one.
• Test from BIG-IP itself. The monitor runs from BIG-IP's own addresses, so routing, firewalls or server ACLs can block it even when your desktop can reach the server.

tmsh show ltm pool <pool_name> members
curl -vk -H "Host: app.example.com" https://<member_ip>:<port>/health

2. The virtual server is available, but requests hang

A classic cause is asymmetric routing. BIG-IP forwards the request to the server, but the server sends its response directly to the client instead of back through BIG-IP. The client never receives a valid reply.

• Check whether SNAT is configured on the virtual server.
• If it isn't, check whether BIG-IP is the default gateway for the servers.
• Look at the virtual server and pool statistics. Traffic going in with nothing coming back is a strong hint.

tmsh show ltm virtual <virtual_name>

3. TLS handshake failures

Handshake failures usually come down to the certificate, the protocol or cipher configuration, or SNI.

• Certificate chain. A missing intermediate certificate in the client SSL profile breaks some clients but not others.
• Protocols and ciphers. Clients and BIG-IP must share at least one protocol version and cipher. The same applies between BIG-IP and the servers when a server SSL profile is used.
• SNI. When several client SSL profiles are attached to one virtual server, BIG-IP uses the server name requested by the client to choose between them, so one profile must be set as the default for clients that don't send a name.

You can test the handshake as a client sees it:

openssl s_client -connect <virtual_ip>:443 -servername app.example.com

4. Users keep losing their session

If the application stores session state on individual servers, users must keep returning to the same pool member.

• Is persistence configured at all?
• Source address affinity and NAT. Many users behind one corporate NAT share an IP address, which can overload one member. Their address can also change mid-session on mobile networks.
• Cookie persistence needs an HTTP profile. Without one, BIG-IP can't insert or read the cookie.
• Timeouts. A persistence timeout shorter than the application session will cause unexpected switches.

5. Connections are being reset

BIG-IP can send a TCP reset for many reasons: no pool member available, an iRule action, a timeout or a protocol error. BIG-IP can log the reason for the resets it sends, which narrows things down quickly. This is controlled by a system database variable:

tmsh modify sys db tm.rstcause.log value enable

Reset cause messages are then written to the LTM log. On busy systems this can generate a lot of log entries, so enable it for the investigation and disable it again afterwards.

6. HTTP 5xx errors: from BIG-IP or from the server?

Before changing anything, establish who generated the error. A packet capture on both sides of BIG-IP answers this quickly. Capturing on interface 0.0 includes all VLANs, and the :nnn suffix adds BIG-IP metadata that shows which virtual server and flow each packet belongs to.

tcpdump -ni 0.0:nnn -s0 -w /var/tmp/case.pcap host <client_ip> or host <member_ip>

If the server returns the 5xx in the server-side capture, the problem is in the application or its dependencies. If the server-side connection never completes, or BIG-IP resets it, the problem is between BIG-IP and the server.

Packet captures can contain sensitive data such as cookies and personal information. Keep them only as long as needed and share them only through secure channels.

A general approach

1. Define the symptom precisely: who is affected, since when, and what exactly they see.
2. Check what changed recently.
3. Follow the request flow and find the first step where things go wrong.
4. Change one thing at a time, and record what you did.

This article is general guidance. Behaviour and command options can differ between BIG-IP versions, so confirm details in F5's official documentation for your version.