An Advanced CLI Field Guide

Outside-the-box troubleshooting commands for F5 BIG-IP, NGINX, and F5 Distributed Cloud.

Field Guide · Troubleshooting

The GUI is where you configure. The CLI is where you find out what is really happening. These are the commands I reach for when a problem does not match the dashboard, grouped by platform. Placeholders in angle brackets are examples, and a few subcommands vary by version.

F5 BIG-IP

BIG-IP hides its best signal inside TMM. The tcpdump peer-flow suffix and tmctl expose flow and stat detail the GUI never shows, and clsh lets you sweep an entire chassis in one shot.

# See client-side AND server-side of one connection in a single capture (the :nnnp peer-flow suffix)
tcpdump -ni 0.0:nnnp host 203.0.113.10
# Live connection table filtered to one client
tmsh show sys connection cs-client-addr 203.0.113.10
# Raw TMM internal stat tables the GUI never surfaces
tmctl -w 200 tmm/flow_stats
# Fan one command out across every chassis blade at once
clsh 'tmsh show sys performance'
# Flip SSL handshake logging to debug with no restart
tmsh modify sys db log.ssl.level value Debug
# Watch per-TMM CPU live
watch -n1 "tmctl -c tmm/tmm_stat"
# Full diagnostic snapshot for iHealth heuristics
qkview -s0
# Tail the LTM event log while you reproduce
tail -f /var/log/ltm

F5 NGINX and NGINX Ingress Controller

The Plus API is the fastest path to upstream truth, and nginx -T ends every argument about which include won. Inside Kubernetes, read the rendered config from the pod itself rather than trusting the manifest.

# Dump the FULL running config including every include
nginx -T | less
# Live upstream health and latency from the NGINX Plus API
curl -s http://127.0.0.1:8080/api/9/http/upstreams | jq
# Community ingress-nginx or F5 NGINX Ingress Controller?
kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].metadata.labels.app\.kubernetes\.io/name}'
# Render the config from inside the ingress pod
kubectl exec deploy/nginx-ingress -n nginx-ingress -- nginx -T
# NGINX IC custom resources and their status
kubectl get vs,vsr,policy,transportserver -A
# Watch App Protect WAF blocks in real time
tail -f /var/log/app_protect/security.log
# Reload gracefully with zero dropped connections
nginx -s reload

F5 Distributed Cloud

XC feels API-first, but every Customer Edge is a Linux and Kubernetes node you can get into. vesctl from your workstation plus kubectl on the CE is the power-user path, and the raw API is always there when the console is not enough.

# Pull a load balancer object as YAML straight from the CLI
vesctl configuration get http_loadbalancer -n <namespace> <lb-name>
# Enumerate objects in a namespace
vesctl configuration list http_loadbalancer -n <namespace>
# A Customer Edge is a hardened Linux and K8s node, so kubectl works on it
kubectl get pods -A
# Customer Edge platform status and tunnels to the Regional Edges
vpm status
# Query the XC API directly with a token
curl -H "Authorization: APIToken <token>" https://<tenant>.console.ves.volterra.io/api/config/namespaces/<ns>/http_loadbalancers
# Follow Customer Edge control-plane logs
vpm log -f

The theme across all three: get under the abstraction, read the primary source of truth, and let the platform tell you what it is actually doing.