F5 BIG-IP¶

Clarity Transform reads the LTM load-balancing topology from an F5 BIG-IP over iControl REST: every virtual server with its pool, algorithm, health monitor and members, resolving each member back to a discovered device.

Where to find it¶

Go to Discover → Integrations, then select the F5 BIG-IP card. The card's category label is Network. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this¶

A migration wave that splits a load-balanced application produces an outage nobody predicted, because the servers looked unrelated.

What we collect¶

The appliance itself
Every virtual server with its virtual IP and port, pool, load-balancing algorithm and health monitor
Pool members, each resolved back to a discovered device so the dependency is recorded against real inventory rather than a bare address

What it adds¶

Load balancers hide a structural truth that network traffic alone obscures. Clients connect to a single published virtual service; behind it sits a pool of servers that are functionally one application.

Without this, a load-balanced application looks like a set of unrelated servers that happen to receive similar traffic. With it, there is explicit evidence for grouping them from the outset. It also makes the published entry point visible, which matters for sequencing: the virtual service is usually what has to be cut over, rather than the individual members.

Stronger evidence than a firewall rule

A firewall rule states that traffic is permitted. A virtual server states that traffic is actually forwarded to a named set of backends. That is a structural dependency rather than a permission, so it is materially better evidence when working out which devices make up an application.

What is deliberately not inferred¶

Deliberate decisions, some of which would be easy to get wrong:

Health is recorded, not used as a filter. A backend currently failing its health monitor is still a configured dependency, because the appliance will forward to it the moment it passes again. Filtering on health would make the discovered topology depend on what happened to be running at the moment discovery ran.
No dependency is inferred between peers. Two servers behind the same virtual service are load-balanced peers; neither calls the other. Clarity records that both sit behind that service, which is a strong grouping signal, but does not invent a relationship between them.
The caller is not inferred. The appliance knows where it forwards traffic, not who sends it. That question is answered by observed traffic instead.
No traffic, connection or statistics data. Configuration only.
No iRules, SSL profiles, keys or certificates.
No GTM, APM or ASM configuration. LTM only.
Nothing is written.

What we require¶

The requirement below is read from rb-pautol-f5-connect.ps1 in the Runbooks repository, which is where it is maintained. If it is wrong, the runbook is what gets corrected and this page follows on the next build.

Role required: the built-in Guest role, on all partitions. Not Administrator, not Resource Administrator, and not Manager. Guest is read-only and cannot change a single setting on the appliance. Discovery reads the LTM object graph only; it never writes.

Connectivity: HTTPS on TCP 443 from Clarity to the management interface.

A BIG-IP can hold a password that is correct but expired, and an expired password fails in a way indistinguishable from a wrong one. Where the account is created ahead of an engagement, confirm it can still log in before the first scheduled run rather than debugging a "wrong credential" that is not one.

A read-only account's write attempt returns HTTP 400 with a message resembling a malformed request, not 403 - see the note further down. So a 400 from this appliance may mean "not permitted" rather than "your JSON is wrong".

Verification before handover¶

Confirm the token exchange as the read-only account. POST to /mgmt/shared/authn/login. A token in the response proves read-only is sufficient, which is the assumption worth testing before handover.
Confirm the LTM graph is readable. Read /mgmt/tm/ltm/virtual and /mgmt/tm/ltm/pool. Both should return populated collections across every partition in scope.
Confirm the password has not expired. This is the check most worth doing. A BIG-IP can hold a password that is correct but expired, and it fails identically to a wrong one. Log in interactively once before the first scheduled run.

Configuring the endpoint¶

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
End Point	The management hostname or IP
Credential	The stored credential for the Guest-role account
Job Schedule	A five-field cron expression, for example `0 2 * * *` (daily). Virtual server membership changes more often than firewall policy
Enabled	Ticked. The box is unticked when the form opens

The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉〈hh〉〈day-of-month〉〈month〉〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access¶

Delete the user on the BIG-IP. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting¶

Symptom	Cause
HTTP 400 with a message about an unexpected argument	The account is read-only and the operation was a write. This appliance reports refusal as 400 rather than 403, so the payload is probably fine.
Login fails with a credential you believe is correct	The password may be correct but expired. That failure is indistinguishable from a wrong password on this appliance. Log in interactively to check.
Virtual servers found but no members	Pool members are a sub-collection. Reading the API by hand needs them requested explicitly.
Members do not resolve to devices	Their addresses are not in the CMDB yet. Run the hypervisor and operating system integrations first.
Nothing discovered in a non-Common partition	The Guest role was not granted on all partitions.