F5CABR (BIG-IP Recert) study materials
F5CABR (BIG-IP Recert) study resources

F5CABR (BIG-IP Recert): BIG-IP Platform Architecture and Local Traffic Management Fundamentals

F5CABR (BIG-IP Recert) · Work through your exam, one topic at a time.

All guide sections

BIG-IP Platform Architecture and Local Traffic Management Fundamentals

Domain 1 - BIG-IP Platform Architecture and Local Traffic Management Fundamentals

This domain tests how a BIG-IP is put together and how local traffic is processed end to end. Expect questions on TMOS, the data plane versus control plane, module roles, and the basic LTM object chain.

Core architecture

BIG-IP runs TMOS. TMM is the data-plane process that handles packets in user space and applies LTM, SSL, and other module logic; mcpd, icrd, and restjavad support configuration and API access on the control plane. LTM is a full proxy: the client-side TCP connection terminates on the BIG-IP and a separate server-side connection is opened to a pool member. That is why profiles, persistence, and iRules can act on flows.

The key object chain is virtual server (listener: destination IP and port) → pool → pool member (node address plus service port) → node. A virtual server must match traffic by address and port, wildcard, or network before LTM can load balance. Without a matching listener, traffic is not accepted by that virtual server. Monitors attach to nodes or members and decide whether they are eligible.

Modules and planes

Modules include LTM, ASM (WAF), APM (access), AFM (network firewall and DoS), DNS, and GTM/DNS. The control plane stores configuration; the data plane forwards. Management access is separate from data traffic; a management IP and a self IP serve different purposes.

Worked example

A client requests 203.0.113.10:443. A virtual server 203.0.113.10:443 has a client SSL profile and a pool with members 10.0.0.11:443 and 10.0.0.12:443. The BIG-IP matches the listener, terminates TLS, selects a member, opens a new server-side connection, and returns the response. If both members fail their HTTPS monitor, the virtual server has no available member and the configured action applies, rather than silently forwarding traffic.

Traps

  • Thinking BIG-IP bridges packets like a layer-2 switch; LTM is a proxy.
  • Confusing a node with a pool member: a node has no port; a member adds a port.
  • Assuming a virtual server matches any port by default; it is specific unless wildcarded.
  • Mixing control-plane and data-plane traffic paths.
  • Treating a monitor as optional when pool availability depends on it.