F5 BIG-IP load balancer
The F5 BIG-IP load balancer pattern builds the BMC Discovery load balancer model based on additional F5 details obtained through SNMP for the following configured items:
- [GMT] Wide IPs, GTM Pools, GTM Pool Members, Data Centers and Servers.
- [LTM] LTM Virtual Servers, LTM Pools and LTM Pool Members.
Any configuration no longer reported is removed from the model.
For F5 BIG-IP hardware-based appliances that can run virtual instance (vCMP Host) pattern creates corresponding Virtual Machines and links these VMs to virtual Network Devices (vCMP Guests):
Starting from TKU May 2021, F5 iRules are supported to create relationships between Load Balancer Servers and Pool.
Starting from TKU November 2021, F5 LTM policies are supported to create relationships between Load Balancer Servers and Pool.
Load Balancer Model
F5 BIG-IP uses the following conceptual model for LTM-based load balancers: Virtual Server (n) - (1) Pool (n) - (n) Member
A Virtual Server is modeled as a Load Balancer Service.
A Pool is modeled as a Load Balancer Pool.
A Member is modeled as a Load Balancer Member.
F5 BIG-IP uses the following conceptual model for GTM-based load balancers: Wide IP (n) - (n) Pool (n) - (n) Pool Member
A Wide IP is modeled as a Load Balancer Service.
A Pool is modeled as a Load Balancer Pool.
A Pool Member is modeled as a Load Balancer Member.
Supported virtual server types
- poolbased - The virtual server is based on a pool.
- ipforward - The virtual server only supports IP forwarding. There is no load balancing on this type of virtual server.
- l2forward - The virtual server only supports L2 forwarding. There is no load balancing on this type of virtual server.
- reject - All connections going to this virtual server will be rejected, and resets will be sent.
Supported virtual server states
- unknown
- enabled
- disabled
- disabledByParent
Supported device failover state
- Unknown
- Offline
- ForcedOffline
- Standby
- Active
Credentials and minimal permissions required
- For SNMP credentials discovery requires access to the following OIDs:
Mandatory OIDs (break discovery):
| OID | Purpose |
|---|---|
| .1.3.6.1.4.1.3375.2.2.10.1.2.1 | LTM virtual servers (name, IP, port, type, default pool) |
| .1.3.6.1.4.1.3375.2.2.5.3.2.1 | LTM pool members (pool-to-member mapping, member IP/port/name) |
| .1.3.6.1.4.1.3375.2.2.10.13.2.1 | LTM virtual server status/state |
| .1.3.6.1.4.1.3375.2.1.14.5.2.1 | Traffic group status (HA/DSC failover group membership and state) |
| .1.3.6.1.4.1.3375.2.1.2.14.1.2.1 | Device entries in cluster (device names/hostnames/IPs) |
| .1.3.6.1.4.1.3375.2.1.1.1.1.10.0 | Legacy failover active mode (pre-v11 logic) |
| .1.3.6.1.4.1.3375.2.1.1.1.1.19.0 | Legacy failover state (deprecated unit mask/state) |
| .1.3.6.1.4.1.3375.2.1.1.1.1.20.0 | Legacy failover unit ID |
| .1.3.6.1.4.1.3375.2.2.1.1.6.0 | Legacy failover peer/mirror IP |
| .1.3.6.1.4.1.3375.2.1.14.3.1.0 | v11+ failover state |
Optional OIDs (data enrichment):
| OID | Purpose |
|---|---|
| .1.3.6.1.4.1.3375.2.1.13.1.2.1 | vCMP guests (guest name, host, state, mgmt IP, base MAC) |
| .1.3.6.1.4.1.3375.2.3.12.1.2.1 | GTM Wide IP objects |
| .1.3.6.1.4.1.3375.2.3.12.5.2.1 | GTM Wide IP to pool mapping |
| .1.3.6.1.4.1.3375.2.3.6.1.2.1 | GTM pools and their algorithms |
| .1.3.6.1.4.1.3375.2.3.6.4.2.1 | GTM pool members |
| .1.3.6.1.4.1.3375.2.3.11.1.2.1 | GTM virtual servers (IP/port/server references) |
| .1.3.6.1.4.1.3375.2.3.9.1.2.1 | GTM servers and data center association |
| .1.3.6.1.4.1.3375.2.2.10.5.2.1 | LTM virtual server to profile mapping (used to tie VS to SSL profiles) |
In the F5 Configuration Utility (System > SNMP > Agent > Access) the OID field would need to be set to the following top-most node to ensure access to all of the OIDs:
.1.3.6.1.4.1.3375.2
- For REST API credentials:
Endpoint URI Method Minimum Role Required Recommended Role /mgmt/tm/ltm/profile/client-ssl GET Guest — lowest role; can read LTM configuration objects Operator — consistent read access across LTM namespace; Guest has documented partition-visibility edge cases /mgmt/tm/ltm/virtual?expandSubcollections=true GET Guest — can read virtual server config including sub-collections Operator — ensures sub-collection expansion works reliably; Guest may return incomplete data on some BIG-IP versions /mgmt/tm/ltm/rule GET Guest — can read iRule objects Operator — iRule content is fully readable at Operator level without version-specific restrictions /mgmt/tm/ltm/policy?expandSubcollections=true GET Guest — can read LTM policy objects including rules/actions sub-collections Operator — policy rules/actions sub-collection expansion is stable at Operator level /mgmt/tm/sys/file/ssl-cert/<cert-id> GET Guest — can read sys file objects; however, cert content visibility depends on partition access Operator — sys namespace access for Guest is restricted on several BIG-IP versions; Operator is the lowest role with reliable sys file read access
Modeled Load Balancer Components
Load Balancer Instance
The pattern creates a Load Balancer Instance with the following attributes:
Attributes | Value |
|---|---|
key | A hash of the device key and load balancer type. |
type | A load balancer type (F5 BIG-IP). |
name | A %LB_TYPE% on %device.name%. |
version | A version of the device OS. |
failover_type | A failover type used on the device. |
failover_state | A failover state reported by the device. |
failover_unit_id | No sample. |
__failover_group | No sample. |
__failover_paired_ipaddr | No sample. |
The pattern models a network service relationship between the device and the Load Balancer Instance.
Load Balancer Member
The pattern creates a Load Balancer Member with the following attributes:
Attributes | Value |
|---|---|
key | A hash of the instance key, IP address and port of the real server. |
ip_addr | A server IP address. |
port | A server port. |
name | A pair of server IP address and port. |
_config_hash | Contains a hash of the server ip address, port, and type. |
The pattern models a containment relationship between the Load Balancer Pool and a Load Balancer Member.
Load Balancer Service
The pattern creates a Load Balancer Service with the following attributes:
Attributes | Value |
|---|---|
key | A hash of the instance key, virtual server name, ip address, and port. |
name | A virtual server name. |
ip_addr | A virtual server IP address. |
port | A virtual server port. |
type | A virtual server type. |
state | A virtual server state. |
dns_names | A dns name of a virtual server IP address. |
_config_hash | Contains a hash of the virtual server name, IP address, port, type,protocol, and state. |
The pattern models a containment relationship between the Load Balancer Instance and a Load Balancer Service.
The pattern also models a containment relationship between the Load Balancer Service and a Load Balancer Pool.
Load Balancer Pool
The pattern creates a Load Balancer Pool with the following attributes:
Attributes | Value |
|---|---|
key | A hash of the instance key and pool name. |
name | A pool name. |
_config_hash | Contains a hash of the pool name, and protocol. |
The pattern models a containment relationship between the Load Balancer Pool and Load Balancer Member.
Virtual Machine
The pattern creates a Virtual Machine for every virtual instances and populates the following attributes:
Attributes | Value |
|---|---|
key | A hash of the instance name, physical device key. |
name | Virtual Machine name |
short_name | Virtual Machine short name |
type | "BIG-IP vCMP" |
vm_type | "vCMP" |
vm_name | Virtual Load Balancer name |
version | vCMP version |
vm_guest_os | Virtual Load Balancer OS |
product_version | vCMP product version |
state | Virtual Machine state |
The pattern models a relationships between the Virtual Machine and physical, virtual Load Balancer.