"Identify and report current device status" sounds like one task; on a BIG-IP it is a tour of surfaces, each with its own vocabulary. The efficient administrator knows which one answers the question at hand.
The physical layer: LCD warnings
On hardware platforms the front-panel Liquid Crystal Display (LCD) reports hardware-level conditions - fan, power, temperature alarms - before you ever log in. A blinking alarm on the panel is the device's way of saying the problem predates the operating system. The same alerts land in the system logs, but the panel is the zero-login view.
The overview layer: dashboard
The dashboard graphs the vital signs - Central Processing Unit (CPU), memory, connections, throughput - as rolling time series. It answers "is the device generally healthy right now" and "did something change in the last hour." It is a gauge, not a microscope: when the dashboard shows a cliff, the next stop is statistics and logs to name the cause.
The object layer: the Network Map
The Network Map draws the delivery tree - virtual servers, pools, pool members - as colored shapes, and the shapes are a language worth learning precisely. A green circle is available; a red diamond is offline because a monitor says so; a blue square means unknown, typically no monitor assigned; a yellow triangle is unavailable, often a connection limit reached; black means disabled by an administrator. One glance answers "what does the device believe about my application's health," and the hover details name the deciding monitor. The map reflects belief, not truth: a green member behind a broken monitor is green because the monitor is happy, which is exactly the trap the troubleshooting exams set.
The command layer: TMSH
The Traffic Management Shell (TMSH) reports everything the graphical surfaces show, scriptably. show sys hardware, show sys cpu, and show sys memory cover the platform; show cm sync-status and show sys failover cover the cluster picture, including high availability (HA) and device trust status; show ltm virtual and show ltm pool (with members) cover the traffic objects, and the statistics variants add counters. Interpreting traffic object statistics - requests distributed across members, current versus maximum connections, bits in and out - is how you confirm functionality with numbers rather than colors: a pool whose members all show traffic is balancing; a member at zero while siblings climb is the anomaly worth explaining.
The socket layer: netstat and service status
The blueprint's netstat objective is a Linux literacy check with a BIG-IP accent. netstat -pan (or the modern ss equivalent) lists sockets with owning processes; filtering for LISTEN answers "which services are up and on which ports." The inference direction matters: given output showing a listener on Transmission Control Protocol (TCP) 443 owned by httpd, you conclude the configuration utility is up; a listener on 22 is sshd; 4353 is the device-to-device management channel. Conversely, "is the service listening on this port" is answered by the presence or absence of the row. Pair it with tmsh show sys service for the daemon-status view, and you can distinguish active from inactive elements of the delivery stack without leaving the shell - which is precisely what the exam scenario asks.
This series, in order
This article opens the series BIG-IP troubleshooting and operations. It names the surfaces a device reports its condition on; the parts go from reading to capturing to handing over: the statistics and the logs, then tcpdump and the metadata TMM writes into a capture, then the evidence you send to support or keep for yourself (the snapshot, the hardware tests, the backup), and finally what watches the box when you are not looking.
- Reading BIG-IP statistics. Why a stats response arrives in three envelopes, the high and low halves of a counter, and why one sample is never a rate.
- The BIG-IP Log Files: a Map of /var/log. Which log answers which question: traffic objects, who got in, who changed what, and the severity ladder.
- BIG-IP tcpdump: How It Differs from Standard tcpdump. The same tcpdump binary, but interfaces that are not NICs: the special 0.0 interface and the F5-only suffixes.
- Capturing Safely on a Production BIG-IP. Bounding the capture, watching the disk, choosing the detail: capturing on a box that is carrying live traffic.
- What the BIG-IP writes into your capture. What TMM knew about each packet, written after it: slot, TMM, virtual server, flow IDs, the reset cause, even TLS secrets.
- Reading a BIG-IP Capture: The F5 Trailer in Wireshark. The f5ethtrailer dissector turning those extra bytes into readable fields in Wireshark.
- TMM Detail Levels and Peer Flows (:n, :nn, :nnn, :p). The colon suffixes :n, :nn, :nnn and :p, how much metadata each attaches, and capturing both sides of a connection.
- qkview and iHealth: the Support Snapshot Workflow. The device's diagnostic self-portrait, uploaded to iHealth and read through its heuristics.
- EUD: BIG-IP Hardware Diagnostics Before You RMA. The offline test battery for memory, storage, sensors and interfaces, run before opening a return merchandise authorization ().
- UCS Archives: the BIG-IP Backup That Contains Everything. The full-device backup, including the private keys people forget, and how to create and restore it.
- Custom Alerting on BIG-IP: SNMP Traps, Email, and Remote Syslog. The alerting pipeline that watches the log stream, and custom alerts by trap, email or remote syslog.
- AVR: Application Visibility and Reporting on BIG-IP. The on-box analytics that turn traffic into latency by virtual server, member, URL and response code.