F5 F5CAB2 - BIG-IP Administration Data Plane Concepts (F5CAB2) exam

With Least Connections (member) , BIG-IP attempts to send new connections to the pool member with the fewest current connections. In a perfectly “stateless” scenario (no affinity), this often trends toward a fairly even distribution over time.

However, persistence overrides load balancing :

When a persistence profile is applied, BIG-IP will continue sending a client (or client group) to the same pool member based on the persistence record (cookie / source address / SSL session ID, etc.).

This means even if another pool member has fewer connections, BIG-IP may still select the persisted member to honor session affinity.

The result can be uneven active connection counts , even though the configured load balancing method is Least Connections.

Why the other options are not the best cause:

A. Priority Group Activation is disabled Priority Group Activation only affects selection when priority groups are configured; disabling it does not inherently create uneven distribution under Least Connections.

B. SSL Profile Server is applied A server-side SSL profile affects encryption to pool members, but it does not by itself cause skewed selection across pool members. (Skew could happen indirectly if members have different performance/latency, but that’s not the primary, expected exam answer.)

D. Incorrect load balancing method Least Connections is a valid method and does not itself explain unevenness unless something is overriding it (like persistence) or pool members are not all eligible.

Conclusion:

A persistence profile is the most common and expected reason that active connections become unevenly distributed , because persistence takes precedence over the Least Connections load-balancing decision.

A Traffic Group is a collection of related configuration objects that fail over together from one BIG-IP device to another. Only " floating " objects can be members of a traffic group.

Virtual Addresses (C): A virtual address (the IP part of a Virtual Server) is a floating object. It is assigned to a traffic group so that the entire IP moves to the standby unit during a failover.

Floating Self IPs (E): These are used as gateways for backend servers or SNAT addresses. By associating them with a traffic group, they remain reachable by the backend network regardless of which BIG-IP is currently active.

Why other options are incorrect:

iRules (A): iRules are configuration logic files; they are synchronized across devices but are not " hosted " by a traffic group.

VLANs (D): VLANs are local to the hardware interfaces/trunks of each specific device and do not fail over.

The diagram illustrates a specific TCP handshake sequence where the BIG-IP system acts as a transparent forwarder rather than a full proxy. The key indicators that identify this as a Forwarding (IP) virtual server are as follows:

Initial Packet Processing : The diagram explicitly states that the LTM evaluates the packet looking only at the destination IP address . This is the fundamental characteristic of a Forwarding IP virtual server, which uses the system ' s routing table to make forwarding decisions instead of load balancing to a pool of members.

Handshake Sequence : Unlike a Standard virtual server, which completes the three-way handshake with the client (SYN, SYN-ACK, ACK) before initiating a separate connection to the server, the Forwarding IP virtual server passes the client ' s original SYN packet directly to the destination node.

Response Timing : The BIG-IP system waits for the SYN-ACK from the destination node before it sends a SYN-ACK back to the client. It essentially " passes through " the handshake signals while still maintaining a state entry in the connection table to track the flow.

Packet-by-Packet Logic : While it tracks the state, it does not perform address translation (unless SNAT is specifically configured) or deep packet inspection like a full proxy would.

Why other options are incorrect:

Standard virtual server : A Standard virtual server is a " full proxy. " It would finish the handshake with the client first and only then open a second, independent TCP connection to the backend server.

Stateless virtual server : A stateless virtual server does not track connections in the connection table. The diagram shows the system meticulously passing sequence numbers ($seq\_num$) and acknowledgment numbers ($ack\_num$) between the two sides, which requires stateful tracking of the TCP flow.

4647

Virtual Servers have a setting called VLAN and Tunnel Traffic which defines where the BIG-IP " listens " for new connections. 4849

Ingress Logic: A virtual server is an entry point. It must be enab 50 led on the VLAN where the Client resides. If a client is on the " 51 Internal " VLAN, the Virtual Server must be enabled there to receive the traffic.

Egress Logic: The BIG-IP system uses the TMM Routing Table and Self-IPs to reach pool members. It does not need the Virtual Server to be " enabled " on the destination VLAN (External) to send traffic there.

Default Behavior: By default, Virtual Servers are enabled on " All VLANs. " However, if restricted for security, the administrator must ensure the Virtual Server is active on the client-facing (ingress) VLAN.

Understanding the default behavior of a Standard Virtual Server regarding address and port translation is fundamental to BIG-IP administration.

Source Address Translation (SNAT): By default, the BIG-IP system does not perform Source Address Translation (SNAT). This means that the packet ' s source IP address (the Client IP ) remains preserved as it passes through the BIG-IP to the pool member. This is critical for backend servers to identify the original client for logging and security purposes. Therefore, the client IP address is unchanged between the client-side and server-side connections.

Destination Address Translation (DAT): By default, a Standard Virtual Server always performs Destination Address Translation. The BIG-IP system changes the destination IP from the Virtual Server ' s IP address to the IP address of the specific Pool Member selected by the load balancing algorithm. Consequently, the server-side destination IP is different from the client-side destination IP.

Port Translation: By default, Port Translation is enabled. If a Virtual Server is listening on port 80 and the selected pool member is configured for port 8080, the BIG-IP will translate the destination port. Even if the ports happen to be the same, the setting allows for change, whereas the default SNAT setting (None) ensures the client IP remains static.

The configuration shown matches a Performance Layer 4 virtual server because it is explicitly using a FastL4 profile:

The screenshot shows Protocol: TCP and Protocol Profile (Client): fastL4 . In BIG-IP data plane terms, FastL4 is the hallmark of a Performance (Layer 4) virtual server, designed to process connections at Layer 4 with minimal overhead (high throughput/low latency) compared to full proxy L7 processing.

The screenshot also shows HTTP Profile (Client): None (and HTTP server profile effectively not in use). A Standard virtual server commonly uses full-proxy features and frequently includes L7 profiles (like HTTP) when doing HTTP-aware load balancing, header manipulation, cookie persistence, etc. In contrast, a Performance L4 virtual server typically does not use an HTTP profile because it is not doing HTTP-aware (Layer 7) processing.

It is not a Forwarding IP virtual server: A Forwarding (IP) virtual server is used to route/forward packets (often without load balancing to pool members in the same way as Standard/Performance VS) and is selected by choosing a forwarding type. The presence of a TCP protocol with a FastL4 client profile aligns with a Layer 4 load-balancing style virtual server, not a packet-forwarding virtual server type.

Conclusion: Because the configuration is TCP-based and explicitly uses fastL4 with no HTTP profile, the expected BIG-IP virtual server type is Performance Layer 4 (Option C) .

In the Traffic Management Shell (TMSH), there is a distinct difference between list and show commands.

List Command : Used to view the configuration of an object (what is stored in the config file). list net route would show you the static routes you have manually configured.

Show Command : Used to view the status, statistics, and real-time state of an object.

TMM Routes : Because the routing table (RIB/FIB) is a dynamic entity that includes both static routes and learned routes (such as those from a routing protocol or connected subnets), the show net route command is required to see the active routing table as it exists in the Traffic Management Microkernel (TMM).

Key Command Breakdown :

show net route: Displays the active TMM routing table, including destination, gateway, and the status of the route.

The behavior of a health monitor is determined by its Send String and Receive String .

Default HTTP Monitor: The pre-configured default HTTP monitor on a BIG-IP system has an empty Receive String .

Success Criteria: When the Receive String is blank, the BIG-IP system considers the health check successful if it receives any valid HTTP response from the server.

Status Code Interpretation: Because a 404 Not Found is a valid HTTP status code (it is a properly formatted response from a running web server process), the BIG-IP interprets this as the application being " alive " .

Result: All three members (including the two returning 404s and the one returning 200) will be marked as UP/Available (Green).