> ## Documentation Index > Fetch the complete documentation index at: https://docs.serval.com/llms.txt > Use this file to discover all available pages before exploring further. # F5 BIG-IP > Connect Serval to an F5 BIG-IP so workflows can read load balancer inventory, sync devices and virtual servers into Serval, and drain or re-enable pool members for maintenance. ## About F5 BIG-IP F5 BIG-IP is an application delivery controller. Its Local Traffic Manager (LTM) publishes applications through **virtual servers**, which send traffic to **pools** of backend **pool members**. Serval connects to a BIG-IP's iControl REST API on its management interface. The integration is marked **Beta** in the connect screen. **Authentication:** A BIG-IP username and password. Serval stores the password encrypted and sends it to the configured BIG-IP only, using HTTP Basic authentication on each request. **Data sync:** No background sync starts when you connect. Two installable ingestion workflows sync BIG-IP devices and virtual servers into Serval as assets. ## What the F5 BIG-IP integration enables | Capability | Description | | - | - | | iControl REST access | Workflows use the "F5 BIG-IP API request" action to call the iControl REST API under `/mgmt/tm/`: devices and device groups, partitions, local users, virtual servers, pools, pool members, nodes, self IPs, VLANs, and SSL certificates, plus saving and syncing the configuration. | | Device ingestion | "Ingest Devices from F5 BIG-IP" syncs the devices in the connected BIG-IP's trust domain (for example, both units of an HA pair), with hostname, management IP, platform, chassis serial, software version, and failover state. | | Virtual server ingestion | "Ingest Virtual Servers from F5 BIG-IP" syncs LTM virtual servers as application service assets, with destination address and port, default pool, iRules, and enabled state. | | Pool member maintenance | "Disable Pool Member", "Force Pool Member Offline", and "Enable Pool Member" take a backend server out of load balancing and bring it back, then save the configuration. They require approval by default. | | Status and reporting | "Get Virtual Server Status" reports which members of a virtual server's pool are up and accepting new connections. "List Expiring SSL Certificates" reports certificates that have expired or expire within a given number of days. | | Connection health checks | Four built-in checks confirm the credentials work and that the account can read virtual servers, pools, and SSL certificates. | ## Before you connect **1. Create a local BIG-IP user for Serval** In the BIG-IP Configuration utility, go to **System**, then **Users**, then **User List**, and create a local user. Set **Terminal Access** to **Disabled**. **2. Choose its role and partition access** What Serval can read and change is exactly what this user can. The health checks, ingestion, and status workflows only read, so a read-only role such as **Guest** or **Auditor** is enough for them. The pool member workflows change member state and save the configuration, so they need a role with write access to the partitions that hold your pools. Before relying on those workflows, run **Disable Pool Member** and **Enable Pool Member** against a non-production member to confirm the role is sufficient. **3. Make the management interface reachable** Management interfaces are usually on a private network. To reach a private BIG-IP, enable **Run on self-hosted workers** in the connection's settings so requests run from a worker inside your network. Whichever path you use, the BIG-IP must present a TLS certificate that Serval (or your worker) trusts. A BIG-IP using its factory self-signed certificate fails to connect until you install a trusted certificate on the management interface or make your worker trust it. ## Connect in Serval **1. Open the F5 BIG-IP connect form** Add a new F5 BIG-IP connection (marked Beta) from your Serval integrations page. **2. Enter the management address** The **Management address** is the hostname or URL of the BIG-IP management interface, such as `bigip.example.com`. Include the port if it is not 443 - for example `bigip.example.com:8443` on a single-NIC BIG-IP. Any `https://` prefix or path is removed. Enter the address of the unit you want Serval to talk to; for an HA pair, one connection per unit lets you reach whichever is active. **3. Enter the username and password** Both are required. To change the password later, edit the connection and enter the new one; leaving the password blank keeps the stored one. Changing the management address always requires entering the password again: "Enter the password again when changing the management address." **4. Submit the form, then run the health checks** The credentials are not tested at save time, so run the health checks right after connecting. ## Verifying the connection * **Validate API connection** - reads the device inventory. On success it reports the hostname, software version, and failover state of the BIG-IP that answered. On failure: "Unable to connect to F5 BIG-IP. Verify the management address, the account's username and password, that the device presents a trusted TLS certificate, and that it is reachable from this worker." * **List virtual servers** - reports how many virtual servers the account can see. * **List pools** - reports how many pools the account can see. * **List SSL certificates** - reports how many certificates are installed. A "Connected, but the account can see no..." result is a working connection whose account has nothing visible, usually because its partition access does not include the partition that holds your objects. ## Using the API in workflows BIG-IP names objects by partition. In API paths, iControl REST writes `/Common/pool_web` as `~Common~pool_web`; the "F5 BIG-IP API request" action accepts either form in path parameters and converts the slash form for you. Pool member names include the port (`/Common/10.0.0.10:443`); IPv6 members separate the port with a dot (`/Common/2001:db8::10.443`). Changes made through the API apply to the running configuration. The pool member workflows save the configuration afterwards so the change survives a reboot. On a device group that does not sync automatically, fill in **Sync to device group** with the group's name so the peer gets the change too - otherwise a failover brings the member back. ## Gotchas and troubleshooting > [accordion] Every request fails with a TLS or certificate error > > The BIG-IP is presenting a certificate Serval does not trust - most often the self-signed certificate it ships with. Install a certificate from a trusted authority on the management interface, or route the connection through a self-hosted worker that trusts it. > [accordion] Requests through a self-hosted worker fail with an upgrade message > > On a connection that uses **Run on self-hosted workers**, the worker checks every request against the allowed paths before attaching the credential. A worker too old to do that is refused with a message beginning "F5 BIG-IP refuses credentials for path", which ends by asking you to upgrade it. Upgrade the worker to the current release. > [accordion] 401 Unauthorized with a valid password > > Use a local BIG-IP user. Serval authenticates with HTTP Basic, and accounts that authenticate against a remote server (LDAP, RADIUS, or TACACS+) may be refused. Also confirm the account is not locked out after earlier failed attempts. > [accordion] Health checks pass but objects are missing > > The account sees only the partitions its role grants. Give it access to every partition that holds the virtual servers, pools, and certificates you need, or **All** partitions. > [accordion] Which endpoints are reachable > > Only the resources listed under "iControl REST access" above are reachable: devices and device groups, partitions, local users, virtual servers, pools and pool members, nodes, self IPs, VLANs, SSL certificates, and saving or syncing the configuration. Everything else is refused, including anything that runs commands or scripts on the device (`util`, iCall, tmsh scripts) and `/mgmt/shared/` (including AS3 declarations). > [accordion] How synced assets are identified > > Devices are keyed by chassis serial number (falling back to their configuration name) and named by hostname. Virtual servers are keyed and named by their full path, such as `/Common/vs_web_443`. The full BIG-IP record is attached to each asset. *** Need help? Contact **[support@serval.com](mailto:support@serval.com)** for assistance with your F5 BIG-IP integration. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.