Skip to main content Home Creators automateyournetwork netclaw f5-troubleshoot
f5-troubleshoot F5 BIG-IP troubleshooting - virtual server failures, pool member health, connection issues, SSL/TLS problems, iRule errors, persistence issues, and performance degradation. Use when a VIP is not responding, pool members are marked down, users report SSL errors, the application is slow, or iRule TCL errors appear in logs.
Jump to install Skills Marketplace Discover and explore AI skills built by the community.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Show prompt details A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/automateyournetwork/netclaw --skill f5-troubleshootThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Download Zip Downloading... More from this repository
Related occupations SOC
Based on SOC occupation classification
name f5-troubleshoot description F5 BIG-IP troubleshooting - virtual server failures, pool member health, connection issues, SSL/TLS problems, iRule errors, persistence issues, and performance degradation. Use when a VIP is not responding, pool members are marked down, users report SSL errors, the application is slow, or iRule TCL errors appear in logs. license Apache-2.0 user-invocable true metadata {"openclaw":{"requires":{"bins":"[Truncated]","env":"[Truncated]"}}}
F5 BIG-IP Troubleshooting
Troubleshooting Principles
Define the problem -- What exactly is broken? Who reported it? What is the expected vs actual behavior?Gather facts -- List objects, check stats, read logs. Never assume.Consider possibilities -- Based on facts, list likely root causesCreate action plan -- Test one variable at a timeImplement and verify -- Make one change, verify, documentDocument -- Record what was found and what fixed it
How to Call the Tools
The F5 MCP server provides 6 tools. Call them via mcp-call with the required environment variables:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " <tool_name> '{"param":"value"}'
Available Tools for Troubleshooting Tool Purpose When to Use list_toolList and inspect object configuration Verify config is correct show_stats_toolShow live statistics and counters Identify traffic flow issues show_logs_toolShow system logs Find errors and event correlation update_toolModify object configuration Apply fixes create_toolCreate new objects Add missing objects delete_toolRemove objects Remove problematic objects
Symptom: "Virtual Server Not Responding to Clients" Clients report they cannot connect to the application VIP.
Step 1: Verify Virtual Server Exists and Is Enabled IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"vs_webapp_https","object_type":"virtual"}'
Does the virtual server exist? If not, it was deleted or never created.
Is it enabled: true? If disabled, someone took it out of service.
Is the destination (VIP:port) correct?
Is a pool assigned?
Is sourceAddressTranslation configured? (Without SNAT/automap, return traffic may bypass the BIG-IP.)
VS does not exist -> Recreate it (use f5-config-mgmt skill)
VS is disabled -> Re-enable: update_tool with {"enabled":true}
VS has no pool -> Assign pool: update_tool with {"pool":"pool_name"}
VS has no SNAT -> Check if servers have BIG-IP as default gateway; if not, add automap
Step 2: Check Virtual Server Statistics IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_stats_tool '{"object_name":"vs_webapp_https","object_type":"virtual"}'
Metric Healthy Indicator Problem Indicator Status availability availableoffline or unknownCurrent connections > 0 during business hours 0 on production VIP Total connections Incrementing Flat or zero Client-side bits in > 0 Zero (no client traffic arriving) Server-side bits out > 0 Zero (no traffic reaching backend) Client bits in, server bits out = 0 - VIP not processing traffic at all Client bits in > 0, server bits out = 0 - Traffic arriving but not forwarded to pool
If status is offline:
The virtual server is marked down because the associated pool has no available members. Proceed to Step 3.
If current connections = 0 but status is available:
The VIP is healthy but no clients are connecting. The issue is upstream of the BIG-IP:
DNS not resolving to the VIP address
Firewall blocking traffic to the VIP
Client network routing issue
VIP is on wrong VLAN/subnet
Step 3: Check the Associated Pool IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"pool_webapp","object_type":"pool"}'
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_stats_tool '{"object_name":"pool_webapp","object_type":"pool"}'
Are any members available? If all members are offline, the pool is down.
What monitor is assigned? Is it appropriate for the service?
Are members enabled or disabled? Disabled members were intentionally drained.
What is the member-to-connection distribution? Is one member handling all traffic?
If all members are offline -> Go to "Pool Member Marked Down" section below.
Step 4: Check Logs for Errors IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_logs_tool '{"lines_number":"200"}'
01010028 -- No members available in pool (confirms pool down)01010025 -- Connection limit reached on virtual server0107142f -- SSL handshake failure01070417 -- HTTP parse error01010240 -- Connection queue fullTimestamps correlating with the reported outage
Step 5: Check Profiles and iRules IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"","object_type":"profile"}'
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"","object_type":"irule"}'
Is the correct SSL profile assigned for HTTPS virtual servers?
Is the HTTP profile assigned when HTTP inspection is needed?
Are any iRules rejecting or redirecting traffic incorrectly?
Is a persistence profile causing traffic to stick to a down member?
Symptom: "Pool Member Marked Down" Health monitor is marking one or more pool members as offline.
Step 1: Identify Which Members Are Down IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"pool_webapp","object_type":"pool"}'
Record: Which members are offline, which are available, which are disabled.
Step 2: Check Pool Statistics for the Down Member IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_stats_tool '{"object_name":"pool_webapp","object_type":"pool"}'
When did the member go down? (Check stats timestamps)
Was there a gradual decline or sudden failure?
Are connections draining from the down member?
Step 3: Check Logs for Monitor Failure Details IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_logs_tool '{"lines_number":"500"}'
Log Message Meaning Common Cause 01071681 Pool member ... monitor status downHealth check failed Server not responding 01071682 Pool member ... monitor status upHealth check recovered Server came back 01010028 No members availableAll members down Total pool failure FQDN ... cannot be resolvedDNS resolution failure DNS issue for FQDN pool members monitor ... instance ... timed outMonitor timeout Server too slow or unreachable
Common root causes for pool member down:
Server is actually down -- The application crashed, the OS is down, or the server was rebootedNetwork path issue -- Firewall between BIG-IP and server blocking health check traffic, or routing issue on server VLANMonitor mismatch -- HTTP monitor expecting 200 but application returns 301/302 redirectMonitor URI wrong -- Health check URI returns 404 because the page does not existPort mismatch -- Monitor checking wrong port (e.g., monitor on 80 but server on 8080)SSL mismatch -- HTTP monitor used but server requires HTTPS (or vice versa)Response timeout -- Server responds but too slowly for the monitor interval/timeoutReceive string mismatch -- Monitor expects specific string in response that changed after app deploymentSource IP issue -- Server firewall blocking the BIG-IP self-IP used for health checks
Step 4: Verify Monitor Configuration IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"pool_webapp","object_type":"pool"}'
From the pool config, identify the monitor name and verify:
Type: HTTP, HTTPS, TCP, ICMP, or customInterval/timeout: Is the timeout shorter than the interval? (Must be: timeout < interval * 3+1 for 3 failures)Send string: What request is sent? (e.g., GET /health HTTP/1.1\r\nHost: app.example.com\r\n\r\n)Receive string: What response is expected? (e.g., 200 OK or healthy)Destination: Is it *:* (use member address:port) or a specific IP:port?
Step 5: Remediation If the server is healthy but the monitor is wrong, fix the monitor:
Update the pool with a correct monitor:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"monitor":"tcp"},"object_type":"pool","object_name":"pool_webapp"}'
If a member needs to be temporarily removed (graceful drain):
Update the pool without the problematic member:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"members":["10.1.1.10:80","10.1.1.11:80"]},"object_type":"pool","object_name":"pool_webapp"}'
WARNING: This removes the member entirely. Existing connections will be terminated. For graceful drain, disable the member instead if the API supports it.
If a replacement member needs to be added:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"members":["10.1.1.10:80","10.1.1.11:80","10.1.1.14:80"]},"object_type":"pool","object_name":"pool_webapp"}'
Symptom: "Connection Limits / Persistence Issues" Users report intermittent connectivity, session drops, or being load-balanced to a different server mid-session.
Step 1: Check Virtual Server Connection Statistics IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_stats_tool '{"object_name":"vs_webapp_https","object_type":"virtual"}'
Check for connection limit issues:
Is connectionLimit set and being reached?
Are clientsideCurConns near the limit?
Is the connection queue filling up? (Check logs for 01010240)
If connection limit is being hit:
Either increase the limit or scale out with additional pool members:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"connectionLimit":0},"object_type":"virtual","object_name":"vs_webapp_https"}'
Setting connectionLimit to 0 removes the limit entirely.
Step 2: Check Persistence Configuration IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"vs_webapp_https","object_type":"virtual"}'
Persistence troubleshooting:
Issue Symptom Resolution No persistence configured Users lose session on every request Add cookie or source-addr persistence Source-addr persistence with SNAT All users from same SNAT IP go to same member Switch to cookie persistence Cookie persistence but app on HTTP Persistence cookie not inserted Ensure HTTP profile is assigned Persistence timeout too short Users lose session during idle Increase persistence timeout Persistence timeout too long Sessions stick to drained member Lower timeout or use cookie Fallback persistence not set When primary persistence fails, connections randomize Set fallback persistence
Step 3: Check Pool Member Connection Distribution IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_stats_tool '{"object_name":"pool_webapp","object_type":"pool"}'
If one member has vastly more connections than others:
Persistence is sticking too many sessions to one member
Consider changing from source-address to cookie persistence
Consider changing load balancing method from round-robin to least-connections
Step 4: Check Logs for Connection Errors IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_logs_tool '{"lines_number":"300"}'
01010025 -- Connection limit reached01010240 -- Connection queue full01060102 -- Rate limit reachedTCL error -- iRule causing connection dropsreset cause -- Connection resets (RST) from server or BIG-IP
Symptom: "SSL/TLS Certificate Problems" Users see certificate warnings, SSL handshake failures, or HTTPS connections fail entirely.
Step 1: Check SSL Profile Configuration IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"","object_type":"profile"}'
Check the SSL client profile assigned to the virtual server:
Is a client SSL profile assigned? (Required for HTTPS VIPs)
Which certificate and key are referenced?
What TLS versions are enabled? (TLS 1.2 and 1.3 should be enabled; TLS 1.0 and 1.1 should be disabled)
What cipher suites are configured?
Issue Symptom Log Pattern Expired certificate Browser shows "Not Secure" 0107142f SSL handshake failedWrong certificate (hostname mismatch) Browser shows certificate warning Client disconnects after handshake Missing intermediate CA Works in some browsers, fails in others 0107143c certificate verification failedWeak cipher suite only Modern browsers refuse to connect 0107142f with no common cipherTLS version mismatch Client can't negotiate 0107142f protocol versionClient cert required but not sent Connection refused 01071065 peer did not return certificateSNI misconfiguration Wrong cert served for hostname Client sees cert for different domain
Step 2: Check Virtual Server for SSL Profile IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"vs_webapp_https","object_type":"virtual"}'
Verify the correct SSL profile is assigned in the profiles list with context: clientside.
Step 3: Check Logs for SSL Errors IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_logs_tool '{"lines_number":"300"}'
Log Code Meaning Action 0107142fSSL handshake failure Check cipher/version/cert compatibility 0107143cCertificate verification failure Check cert chain completeness 01071065Peer certificate missing Client cert auth configured but client has no cert 01070417HTTP request on HTTPS port Client sending plain HTTP to SSL VIP SSL routines:ssl3_read_bytes:sslv3 alertSSL alert received from peer Version/cipher mismatch
Step 4: Remediation Update SSL profile ciphers to modern standards:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"ciphers":"TLSv1.2:TLSv1.3:!SSLv3:!RC4:!3DES:!EXPORT"},"object_type":"profile","object_name":"clientssl_webapp"}'
Assign the correct SSL profile to a virtual server:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"profiles":[{"name":"clientssl_webapp","context":"clientside"},{"name":"http"},{"name":"tcp-wan-optimized","context":"clientside"},{"name":"tcp-lan-optimized","context":"serverside"}]},"object_type":"virtual","object_name":"vs_webapp_https"}'
WARNING: The profiles list is a full replacement. Include ALL desired profiles.
Symptom: "iRule Errors in Logs" Logs show TCL errors or iRule-related failures.
Step 1: Pull Recent Logs IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_logs_tool '{"lines_number":"500"}'
Scan for iRule error patterns:
Pattern Meaning Common Cause TCL errorTcl script runtime error Syntax error, undefined variable, missing command can't read "variable"Variable not defined Variable used before assignment or in wrong event command not foundInvalid Tcl or iRule command Typo or deprecated command HTTP::collect without HTTP::releasePayload collection started but never released Missing release in all code paths (memory leak) invalid command name "pool"Pool command in wrong event pool used outside HTTP_REQUEST eventtoo many re-entering callsRecursive iRule invocation iRule triggering itself exceeded CPU time limitiRule taking too long Complex regex or infinite loop abortiRule explicitly aborted Error condition in catch block
Step 2: Identify the Problematic iRule IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"","object_type":"irule"}'
Cross-reference the iRule name from the log error with the iRule inventory. Check which virtual servers have this iRule assigned.
Step 3: Review iRule Content IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"problematic_irule","object_type":"irule"}'
Common iRule bugs to check for:
Variables used across events without being set in all code paths
HTTP::collect without corresponding HTTP::release in all branchesMissing default case in switch statements
Regex patterns that can cause catastrophic backtracking
log statements in high-traffic events (performance issue, not error)String operations on binary data
Missing error handling (catch) around operations that can fail
Step 4: Fix the iRule IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"apiAnonymous":"when HTTP_REQUEST {\n catch {\n switch -glob [string tolower [HTTP::uri]] {\n \"/api/*\" { pool pool_api_backend }\n default { pool pool_webapp }\n }\n } err {\n log local0. \"iRule error: $err\"\n pool pool_webapp\n }\n}"},"object_type":"irule","object_name":"uri_routing"}'
Alternatively, if the iRule is causing critical failures, remove it from the virtual server immediately:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"rules":[]},"object_type":"virtual","object_name":"vs_webapp_https"}'
This removes all iRules from the virtual server. Traffic will flow to the default pool without any iRule processing. Fix the iRule, then re-attach it.
Symptom: "Performance Degradation" Application is slow, high latency, or throughput has dropped.
Step 1: Check Virtual Server Statistics IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_stats_tool '{"object_name":"vs_webapp_https","object_type":"virtual"}'
Connection count near the limit -> Bottleneck at the VIP
High bits/sec relative to interface capacity -> Bandwidth saturation
Connection rate spike -> Possible DDoS or legitimate traffic surge
Asymmetric traffic (high client-side, low server-side) -> Backend not keeping up
Step 2: Check Pool Member Distribution IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_stats_tool '{"object_name":"pool_webapp","object_type":"pool"}'
Uneven connection distribution -> Some members overloaded, others idle
Single member with most connections -> Persistence issue or members down
All members at high connection count -> Need more backend capacity
High server-side connection time -> Backend application slow
If distribution is uneven, consider changing load balancing:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"loadBalancingMode":"least-connections-member"},"object_type":"pool","object_name":"pool_webapp"}'
Step 3: Check for Pool Members Down (Reduced Capacity) IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"pool_webapp","object_type":"pool"}'
If members are down, the remaining members are handling more traffic than designed. This is the most common cause of "slow application" reports -- not a BIG-IP issue but a capacity issue.
Step 4: Check System Logs for Errors IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_logs_tool '{"lines_number":"500"}'
Performance-related log patterns:
Pattern Meaning Action 01010025Connection limit reached Increase limit or add capacity 01010240Connection queue full Increase queue depth or backend capacity 01060102Rate limit reached Review rate limiting config 01070727Pool member rate limit Member receiving too much traffic memoryBIG-IP memory pressure Check for memory leaks, iRule issues disk_usageBIG-IP disk pressure Check for log rotation issues tmm_semaphoreTMM (Traffic Management Microkernel) contention BIG-IP itself is overloaded aggressive_modeMemory aggressive mode enabled BIG-IP is under severe memory pressure
Step 5: Check iRules for Performance Impact IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"","object_type":"irule"}'
iRule performance killers:
log statements on every request -> Disk I/O bottleneckComplex regex matching -> CPU overhead
HTTP::collect large payloads -> Memory consumptionDNS::lookup in data path -> Blocking operation, adds latencyMultiple iRules with same events -> Event processing overhead
persist uie with large strings -> Persistence table bloat
Step 6: Scale Out (If Root Cause Is Capacity) If the root cause is insufficient backend capacity, add more pool members:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " update_tool '{"url_body":{"members":["10.1.1.10:80","10.1.1.11:80","10.1.1.12:80","10.1.1.13:80","10.1.1.14:80"]},"object_type":"pool","object_name":"pool_webapp"}'
WARNING: Members list is a full replacement. Include ALL desired members (existing + new).
Symptom: "HA Failover or Sync Issues" Logs indicate high-availability state changes, failover events, or configuration sync failures.
Step 1: Check System Logs for HA Events IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " show_logs_tool '{"lines_number":"500"}'
Pattern Severity Meaning ha_status active -> standbyCRITICAL This unit has gone standby -- failover occurred ha_status standby -> activeCRITICAL This unit has become active -- peer failed failoverCRITICAL Failover event in progress config_sync failedHIGH Configuration not synchronizing between peers device_trustHIGH Device trust certificate issue heartbeat lostCRITICAL HA heartbeat lost -- peer may be down network_failoverCRITICAL Network-based failover triggered
Step 2: Verify Object State After Failover After any failover event, immediately verify all virtual servers and pools:
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"","object_type":"virtual"}'
IP_ADDRESS=$F5_IP_ADDRESS Authorization_string=$F5_AUTH_STRING python3 $MCP_CALL "python3 -u $F5_MCP_SCRIPT " list_tool '{"object_name":"","object_type":"pool"}'
Confirm all virtual servers are available and all pool members are healthy on the now-active unit.
Common F5 Error Code Quick Reference Code Severity Meaning First Action 01010025HIGH VS connection limit reached Check stats, increase limit 01010028CRITICAL No pool members available Check pool health 01010029CRITICAL Pool member monitor down Check member + monitor 01010240HIGH Connection queue full Check capacity 01060102HIGH Rate limit reached Review rate config 0107142fCRITICAL SSL handshake failure Check cert + ciphers 01070417HIGH HTTP parse error Check client requests 0107143cWARNING Cert verification fail Check cert chain 01071681WARNING Pool member marked down Check member health 01071682INFO Pool member marked up Recovery event 01070727WARNING Member rate limit Check distribution TCL errorHIGH iRule error Check iRule code
Troubleshooting Decision Flowchart Client reports application down
|
+-> Check VIP status (list_tool + show_stats_tool virtual)
|
+-> VIP offline?
| +-> Check pool (list_tool + show_stats_tool pool)
| +-> All members down? -> Check servers + monitors
| +-> Some members down? -> Reduced capacity, check remaining
| +-> No pool assigned? -> Assign pool (update_tool)
|
+-> VIP available but 0 connections?
| +-> DNS, firewall, or routing issue upstream of BIG-IP
|
+-> VIP available, connections present, but errors?
+-> Check logs (show_logs_tool)
+-> SSL errors? -> Check profiles + certs
+-> HTTP errors? -> Check iRules + backend health
+-> Connection limits? -> Scale out or increase limits
Integration with Other Skills Skill Integration Point f5-health-check Run health check first to scope the problem f5-config-mgmt Apply fixes using proper change workflow servicenow-change-workflow Create incident tickets for CRITICAL findings drawio-diagram Visualize traffic flow for complex troubleshooting markmap-viz Create troubleshooting decision trees
GAIT Audit Trail After completing a troubleshooting session, record findings and resolution in GAIT:
python3 $MCP_CALL "python3 -u $GAIT_MCP_SCRIPT " gait_record_turn '{"prompt":"F5 troubleshoot: vs_webapp_https not responding to clients","response":"Investigation: VIP status offline due to pool_webapp all members down. Root cause: HTTP health monitor expecting 200 but app returning 301 redirect after deployment. Fix: updated monitor receive string to accept 301. Verification: all 3 pool members now available, VIP status available, client connections incrementing. Logs clear of 01010028 errors.","artifacts":["f5-troubleshoot-report.txt"]}'
