Skip to main content

f5audit

CI PyPI Python

Read-only audit tool for F5 BIG-IP LTM. It collects configuration and statistics via iControl REST (GET only), correlates object references, and produces a multi-sheet Excel report identifying unused objects (nodes, pools, virtual servers, monitors) as input for a human-driven, change- controlled cleanup.

This tool never modifies the device. The "suggested command" columns in the report are informational text only; nothing is ever executed.

Safety design

  • The HTTP client (F5ReadOnlyClient) exposes a single get() method. There are no post/patch/put/delete methods. The only internal write is the token login, hardcoded to /mgmt/shared/authn/login. This is enforced by structural tests.
  • No tmsh/bash execution endpoints are used or referenced anywhere.
  • No explicit logout (deleting the token would be a write); tokens expire on their own (~20 minutes).
  • Passwords are read from an interactive prompt (getpass) or the F5_PASS environment variable — never from a CLI argument, and never written to disk or logs.
  • Management-plane friendly: sequential requests only, $top/$skip pagination, per-request delay (--delay, default 0.1 s), 30 s timeout, max 2 retries with exponential backoff.

Requirements

  • Python >= 3.9, requests, openpyxl
  • An account with a read-only role (Auditor/Guest) and iControl REST access on the BIG-IP
  • Network access to the management interface (TCP 443)

Installation

pip install f5audit

From source: pip install . — or without installing, from the project directory: python -m f5audit ...

Usage

1. Validate access first

f5audit validate --host 192.0.2.1 --user auditor --insecure

Probes login plus the key GET endpoints and prints a diagnosis per response code (bad credentials, missing REST access, denied endpoints, old BIG-IP versions, network timeouts).

2. Collect once, analyze offline N times

f5audit collect --host 192.0.2.1 --user auditor --insecure --save-raw ./raw/
f5audit analyze --from-raw ./raw/ --out report.xlsx

collect saves every raw JSON response (with timestamps) to disk; analyze --from-raw re-analyzes from that cache without touching the F5 again. This is the recommended workflow: one collection per session, all further analysis offline.

One-step alternative

f5audit analyze --host 192.0.2.1 --user auditor --insecure --save-raw ./raw/ --out report.xlsx

Options

Flag Meaning
--user / F5_USER Username (password via prompt or F5_PASS)
--login-provider Token auth provider (default tmos; set for TACACS+/RADIUS)
--insecure Skip TLS verification (self-signed mgmt certs); prints a warning
--delay Seconds between requests (default 0.1)
--top Pagination page size (default 100)
--format xlsx|csv Excel workbook or one CSV per sheet
--allow-standby On a standby unit, emit traffic- and availability-based verdicts marked UNRELIABLE (standby) instead of skipping them

Exit codes: 0 OK · 1 connection/auth error · 2 analysis completed with warnings (standby device, denied partitions, missing endpoints).

Verdicts

Verdict Meaning
ORPHAN Not referenced by anything (node: no pool membership; pool: no VS/iRule/policy reference; monitor: no user). Only issued when the inventory is complete and no dynamic iRules are active.
MANUAL REVIEW A dynamic iRule (pool $var, pool [...], datagroups) or a missing ltm/rule endpoint means the object could be referenced at runtime. Never auto-cleanup these.
INACTIVE Configured and referenced, but disabled or zero total connections since the last counter reset.
OFFLINE (decommission candidate) Referenced, but the whole dependency chain is monitor-offline: every member of the pool is down, so the pool and its virtual servers are offline. A deletion candidate to confirm with the config owner — availability is point-in-time, so it may also mean maintenance. A node is only included when it is dead in every pool it belongs to; a node alive in another pool stays IN USE ("in use elsewhere"). Only issued on the ACTIVE unit; capped at MANUAL REVIEW while dynamic iRules are attached.
UNRELIABLE (standby) Traffic-based verdict computed on a standby unit (only with --allow-standby).
UNRELIABLE (incomplete inventory) Some partitions were not readable; a reference could exist in an invisible partition.
IN USE Everything else.

Operational warning

  • Collect on the ACTIVE unit of the HA pair. On a standby unit traffic counters are zeros and the tool will skip traffic analysis (or mark it UNRELIABLE with --allow-standby).
  • Traffic counters reset on reboot / stats reset. Ideally collect after several weeks of uptime; the report includes the failover-state age as context.
  • INACTIVE means "no traffic since the counters started", not "safe to delete". Use the planned compare workflow (v2) — two collections some weeks apart — to distinguish real zero traffic from a recent reset. The raw cache already stores per-file timestamps to enable this.
  • Availability is point-in-time: an OFFLINE chain reflects monitor state at collection time and may mean maintenance rather than decommissioning. Always confirm with the config owner before requesting deletion.

Report sheets

  1. Summary — hostname, version, HA state, uptime context, partitions, verdict counts, active warnings.
  2. Inventory — one row per pool member (plus rows for pool-less nodes), fully correlated: node ↔ pool ↔ virtual server ↔ monitor ↔ iRule/policy references, statuses, traffic and verdict.
  3. Orphan Nodes · 4. Orphan-Inactive Pools · 5. Inactive Virtual Servers — filtered views with informational tmsh commands for the change request.
  4. Dead Chains — one row per pool with an OFFLINE (decommission candidate) verdict, grouping the whole chain (virtual servers → pool → member nodes) with per-object verdicts and the informational tmsh delete lines to take to the config owner. Nodes still alive in another pool get no delete line here.
  5. Orphan Monitors — filtered view with informational tmsh commands.
  6. Manual Review — objects touched by dynamic logic, with the iRule/policy that causes the doubt.

Color coding: red = ORPHAN · yellow = MANUAL REVIEW / UNRELIABLE · orange = INACTIVE · purple = OFFLINE · green = IN USE.

Development

pip install -e ".[dev]"
ruff check f5audit tests && ruff format --check f5audit tests
pytest

No test touches the network; everything runs from anonymized JSON fixtures and mocked HTTP sessions. Structural tests assert the client exposes no write verbs and that no forbidden endpoint appears in the source. CI runs lint plus the test suite on Python 3.9 through 3.14; all checks must pass before a PR can merge.

Releases are published to PyPI automatically: bump __version__ in f5audit/__init__.py, merge, and create a GitHub release tagged v<version>. The release workflow verifies the tag matches the package version, builds, and publishes via PyPI Trusted Publishing (no stored API tokens).

Metadata

Release files for f5audit 0.2.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for f5audit 0.2.0
File Size Uploaded
f5audit-0.2.0.tar.gz 43.5 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for f5audit 0.2.0
File Interpreter ABI Platform
f5audit-0.2.0-py3-none-any.whl Python 3 none any Details

Total release size: 76.0 kB

Release files / f5audit-0.2.0.tar.gz

Download URL f5audit-0.2.0.tar.gz
Size 43.5 kB
Tags Source
SHA-256 checksum
How to use checksums
5cc37b967fd296fd998049d89f2217a996fa6900dfec4a052af758e325e363da
BLAKE2b-256 checksum
How to use checksums
ff6a92aefa70f180d010cd80742bdf68bf34a4df528f38cf675dc96f08cd20f5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 20, 2026.

Transparency log

Release files / f5audit-0.2.0-py3-none-any.whl

Download URL f5audit-0.2.0-py3-none-any.whl
Size 32.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
b02c17996cdc7c213ee1fcfcdc40ee0aff16e7dd5d0fb1683546c484c031e332
BLAKE2b-256 checksum
How to use checksums
94d9d7226727a7d63f6eefb8cabcf2d6b76dea7cbde1b2d6c50defaed1a58ce6
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 20, 2026.

Transparency log

Release history Release notifications | RSS feed

0.6.1

2 release files

0.6.0

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.4

2 release files

0.2.3

2 release files

0.2.2

2 release files

0.2.1

2 release files

This release

0.2.0 This release

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page