Discover, inventory, and search F5 BIG-IP iRules, LTM traffic policies, and internal data groups in Versus — with full Tcl source, computed "referenced by" links to virtual servers, and built-in detection so system objects stay out of your way.
F5 BIG-IP steers traffic with more than pools and profiles. iRules (event-driven Tcl scripts), LTM traffic policies (declarative match/action rules), and data groups (named lookup tables) carry a lot of the real logic on a mature ADC — redirects, header rewrites, content switching, allow-lists, and maintenance pages. Versus discovers all three as first-class inventory objects so they are searchable, versioned in your synced snapshot, and cross-linked to the virtual servers that use them.
These objects are read-only in Versus today: they are imported from the box and surfaced for inventory, audit, and change-planning. Versus never writes iRule or policy definitions back to a device outside of an approved workflow.
When you connect an F5 BIG-IP (see F5 BIG-IP Integration), the discovery job pulls these objects from the iControl REST API, per partition, alongside virtual servers, pools, monitors, and certificates:
| Object | Source endpoint | What is stored |
|---|---|---|
| iRule | /mgmt/tm/ltm/rule | Full Tcl source (definition), name, partition |
| LTM policy | /mgmt/tm/ltm/policy | Strategy, status, and the expanded rules/conditions/actions as raw_config |
| Data group | /mgmt/tm/ltm/data-group/internal | Type (string / integer / ip), record count, and records |
Discovery is a full reconcile, not an append. Each import run tracks the objects it saw and deletes any iRule, policy, or data group that no longer exists on the device — so removing an iRule on the F5 and re-syncing removes it from Versus too. LTM policies are filtered to their published version; the in-progress Drafts copy that BIG-IP keeps while a policy is being edited is not imported.
Everything is stored per device + partition + name, which is the unique key F5 itself uses, so the same object name in Common and in a tenant partition are tracked as distinct rows.
The iRules view lists every iRule across all discovered devices, with a per-row line count and an expandable panel that shows the complete Tcl source exactly as it lives on the box:
when HTTP_REQUEST {
if { [class match [HTTP::host] equals maintenance_hosts] } {
HTTP::respond 503 content "Down for maintenance"
return
}
if { [HTTP::uri] starts_with "/api" } {
pool api_pool
}
}
Search matches on iRule name. The same source is also reachable from a virtual server's TMSH tab on its detail page, where any iRule attached to that VS is rendered inline with the generated configuration.
Each iRule row shows which virtual servers reference it. Because BIG-IP does not store a reverse link from an iRule back to its consumers, Versus recomputes the relationship the same way the device resolves it at config-apply time: it scans each virtual server's stored rules list for this iRule by full path (/Common/my_rule) or bare name, since TMOS records one or the other depending on version. The result is a set of live links straight to the virtual servers that run the rule.
F5 ships a set of system iRules (the _sys_* helpers and a handful of named defaults such as /Common/_sys_https_redirect). Versus flags these with a Built-in badge so they are visually separated from the rules your team actually wrote. Built-in detection matches against a known list of system names plus the _sys_ prefix, and is shared with the unused-object scanner so both features agree on what counts as an F5 default.
LTM policies are BIG-IP's declarative alternative to iRules for common match/action work — routing on host or path, inserting headers, forwarding to a pool — without writing Tcl. Versus imports each policy's strategy (for example first-match), its status, and the full expanded body (rules, conditions, and actions) into raw_config, so you can review exactly what a policy does and which pools or profiles it selects.
Policies are surfaced through the same inventory model as iRules and share the device/partition/name identity scheme. Where a virtual server attaches a policy, that relationship is preserved from the imported configuration and used when Versus resolves the objects a VS depends on.
Data groups are named lookup tables — string, integer, or IP — that iRules and policies consult with class match. Versus imports internal data groups (records stored in the config, as opposed to external file-backed groups) with their type and every record.
Data groups have no structured back-reference anywhere in the F5 configuration: an iRule names a data group as a plain string inside its Tcl body. Versus therefore computes a data group's "referenced by" links with a text search — it lists every iRule on the same device whose definition text mentions the data group's name. This reliably surfaces likely usage, but because it is a substring match rather than a parsed reference, treat it as a strong hint, not a guarantee. This limitation is intentional and called out in the product so operators do not over-trust it.
All three object types are exposed as read-only, paginated REST collections. Authenticate with a JWT bearer token exactly as described in Running Workflows via the API.
GET /api/irules/
GET /api/policies/
GET /api/datagroups/
Authorization: Bearer eyJhbGc…
Responses are standard paginated envelopes (count, next, previous, results). iRule entries carry the computed line_count, referenced_by, and is_builtin fields alongside the raw definition:
{
"count": 84,
"results": [
{
"id": 512,
"device_name": "bigip-dc1-active",
"name": "maintenance_page",
"partition": "Common",
"line_count": 9,
"definition": "when HTTP_REQUEST {\n ...\n}",
"referenced_by": [
{ "type": "virtual_server", "name": "Common/vs_app_https",
"url": "/applications/virtual-servers/318" }
],
"is_builtin": false
}
]
}
Filter and search with query parameters:
| Collection | Filters | Search |
|---|---|---|
/api/irules/ | device, partition | name |
/api/policies/ | device, partition | name |
/api/datagroups/ | device, partition, dg_type | name |
For example, list only the data groups of type ip on device 7:
GET /api/datagroups/?device=7&dg_type=ip
These endpoints are read-only (GET list and detail); there are no create/update/delete operations, matching how the objects are managed — sourced from the device and reconciled on each sync.
irules list so infrastructure-as-code exports stay faithful to the live config._sys_* rules so it only surfaces genuinely orphaned objects. This is how you find dead iRules safe to clean up.iRules, policies, and data groups are ordinary rows in the same relational system of record as the rest of your ADC inventory (see Platform Architecture). That means they are searchable next to your virtual servers, appear in the same synced snapshot the generated IaC views render from, and participate in the reference graph Versus computes across pools, nodes, iRules, certificates, and TLS profiles. Because discovery reconciles on every run, what you see in Versus tracks what is actually on the box — which is exactly what you want when auditing what a virtual server really does before you change it.