F5CAB2 BIG-IP Administration Data Plane Concepts (F5CAB2) exam Question and Answers

WithLeast 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 apersistence profileis applied, BIG-IP will continue sending a client (or client group) to thesame pool memberbased 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 beuneven 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 disabledPriority 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 appliedA 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 methodLeast 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:

Apersistence profileis the most common and expected reason that active connections becomeunevenly distributed, because persistencetakes precedence overthe Least Connections load-balancing decision.

SNAT Automapis a feature that automatically selects a self-IP address to use as the source address for translated packets. The selection logic follows a strict hierarchy to ensure that traffic is routable back to the BIG-IP:

Egress VLAN Priority:The BIG-IP first looks at the VLAN through which the traffic is exiting toward the pool member (the egress VLAN).

Floating Self-IP Preference:If the egress VLAN has afloating self-IP address, the BIG-IP will always prefer it for SNAT Automap. This is critical for High Availability (HA) because, during a failover, the floating IP moves to the new active device, allowing existing connections to be maintained or correctly timed out.

Non-Floating Fallback:If no floating self-IP is available on the egress VLAN, the system will use a floating self-IP from a different VLAN. If no floating IPs exist at all, it will then fall back to the non-floating self-IP.

Key Data Plane Concept:

The management IP is never used for data plane traffic. In this scenario, since the administrator has configured a floating self-IP, that specific address becomes the source for all SNAT Automap traffic leaving that VLAN to ensure symmetric routing during HA events.

To meet the requirement offault tolerance when one interface goes down, BIG-IP must uselink aggregationso that loss of a single physical link does not isolate the VLAN(s).

How the objects relate (data plane view)

Interfaces= physical links.

Trunk (LACP)= bundles multiple interfaces into one logical link that providesredundancy(and possibly bandwidth aggregation).

VLANsare assigned to interfaces or trunks. If you needmultiple VLANs on the same trunk, they must use802.1Q tagging(because you can only have one untagged VLAN per interface/trunk).

Self IPsare then placed on the VLANs to provide BIG-IP presence and routing/ARP functions, but self IPs are not what provides link resiliency—the trunk does.

Why Option D is correct

You havetwo physical interfacesand you want resiliency if one fails → put both interfaces intoone trunk with LACP enabled.

You needboth external and internal VLANson those same two links → both VLANs should be configured astaggedon that trunk, so they can coexist on the same aggregated link.

If either physical interface fails, the trunk remains up via the remaining interface, keepingboth VLANs operational.

Why the other options are incorrect

A: Two VLANs cannot both beuntaggedon the same trunk/interface. Only one untagged VLAN is possible; additional VLANs must be tagged.

B: Two trunks “each with one VLAN” would typically mean splitting VLANs across separate trunks. With only two interfaces total, that becomes one interface per trunk—if one interface goes down, the VLAN on that interface is down (no redundancy for that VLAN).

C: Same redundancy problem as B, and disabling LACP removes the negotiated aggregation behavior expected when the switch engineer specifically requested LACP.

===========

When handling high-volume UDP traffic where the BIG-IP does not need to maintain any session history or relationship between packets, aStatelessvirtual server is the appropriate choice.

No Connection Tracking:A stateless virtual server does not create or maintain entries in the BIG-IP connection table. This means the system processes each packet as an individual event, without "considering previous connections" or packets from the same source.

High Performance:Because the system bypasses the overhead of state management, stateless virtual servers provide the highest possible throughput for UDP and ICMP traffic.

Use Cases:This is ideal for services like DNS (stateless queries) or some types of syslog traffic where each packet is independent and doesn't require the persistence or protocol inspection typically provided by a full-proxy.

Why other options are incorrect:

Forwarding:While a Forwarding (IP) virtual server can handle UDP, it still maintains a state entry in the connection table to ensure return traffic is handled correctly.

Standard:This is a full-proxy virtual server. It is inherently stateful and requires a connection table entry for every flow it manages.

Reject:This is a special virtual server type that simply drops incoming traffic and, in the case of TCP, sends a reset (RST) or, for UDP, sends an ICMP unreachable message. It is not a load balancing type.

Configuring networking objects in BIG-IP requires using the correctTMSH module pathandverb.

Module Path:Trunks are networking objects, so they reside under the /net module, not /sys.

Verb:Since the trunk already exists, the modify verb must be used to update its properties rather than create.

Syntax:The correct syntax to append physical interfaces to an existing trunk is tmsh modify /net trunk [name] interfaces add { [port list] }.

Data Plane Impact:Adding interfaces to a trunk (Link Aggregation) increases the total aggregate bandwidth available to the system and provides additional hardware redundancy.

On BIG-IP systems,physical interface bandwidth is fixedby the link speed (for example, 1GbE or 10GbE). When traffic demand exceeds the capacity of a single interface, BIG-IP provideslink aggregationthroughtrunks.

Key concepts involved:

InterfacesA single physical interface (such as 1.1) is limited to its negotiated link speed. You cannot exceed this capacity through software tuning alone.

Trunks (Link Aggregation)Atrunkcombines multiple physical interfaces into a single logical interface.

BIG-IP supports LACP and static trunks.

Traffic is distributed across member interfaces, increasingaggregate bandwidthand providingredundancy.

VLANs are then assigned to thetrunk, not directly to individual interfaces.

Why optionBis correct:

Creating atrunk with two interfacesallows BIG-IP to use both physical links simultaneously.

This increases total available bandwidth (for example, two 10Gb interfaces → up to 20Gb aggregate capacity).

This is thedocumented and supported methodfor scaling bandwidth on BIG-IP.

Why the other options are incorrect:

A. Increase the MTUMTU changes affect packet size and efficiency,not total bandwidth capacity.

C. Assign two interfaces to the VLANBIG-IP doesnotsupport assigning a VLAN to multiple interfaces directly. VLANs must be associated withone interface or one trunk.

D. Set the media speed manuallyMedia speed can only be set up to the physical capability of the interface and connected switch port. It cannot exceed the hardware limit.

Conclusion:

To increase total available bandwidth on BIG-IP when a single interface is insufficient, the administrator must create atrunk object with multiple interfacesand move the VLAN onto the trunk. This aligns directly with BIG-IP data plane design and best practices.

This scenario combinessession continuity,multiple protocols (HTTP and FTP), andHA failover behavior, which directly implicatespersistence handling across devices and services.

Key Requirements Breakdown

Samepool member for entire session

Session must survivefailover

Session must spanmultiple services (HTTP and FTP)

Why Persistence Mirroring + Match Across Services Is Required

Persistence Mirroring

Ensurespersistence records are synchronizedfrom the active BIG-IP to the standby BIG-IP.

Without mirroring:

After failover, the standby device hasno persistence table

Clients are load-balanced again

Sessions break, forcing users to restart

Persistence mirroring is essential forsession continuity during failover

Match Across Services

Allows asingle persistence recordto be shared acrossmultiple virtual servers / protocols

Required when:

HTTP and FTP must use thesame pool member

Multiple services are part of a single application session

Together, these settings ensure:

Persistence survivesdevice failover

Persistence is honoredacross HTTP and FTP

Why the Other Options Are Incorrect

A. Cookie persistence and session timeoutCookie persistence only applies to HTTP and does not address FTP or failover synchronization.

B. Stateful failover and Network Failover detectionStateful failover applies toconnection state, notpersistence records, and does not link HTTP and FTP sessions.

D. SYN-cookie insertion threshold and connection low-water markThese are DoS / SYN flood protection settings, unrelated to persistence or HA behavior.

The BIG-IP processing flow follows a specific sequence of events as a packet moves through the system.

TCP Handshake:Before any application-layer data (like HTTP) can be processed, a TCP connection must be established.

The First Event:The very first event triggered when a client completes the 3-way handshake with the virtual server isCLIENT_ACCEPTED.

Profile Influence:Even if an HTTP profile is attached, the system must first "accept" the connection at the protocol level. HTTP_REQUEST only triggersafterthe client sends data that the BIG-IP recognizes as a valid HTTP request. If a client connects but never sends a request, CLIENT_ACCEPTED will have fired, but HTTP_REQUEST will not.

In BIG-IP traffic management,persistence profilescause existing client connections (and subsequent requests) to be repeatedly sent to the same pool member. When persistence is enabled, simply preventing new connections is not sufficient if the requirement is toimmediately remove all existing connections.

Key behavior of pool member states:

Forced Offline

Immediately removes the pool member from load balancing.

Terminates all existing connections, regardless of persistence.

Prevents new connections from being established.

This is the correct state when urgent maintenance or troubleshooting is required.

Disabled

Preventsnew connectionsfrom being sent to the pool member.

Allows existing connections to continue, which is not acceptable when persistence is configured and connections must be cleared immediately.

Offline (non-forced)

Similar to Disabled behavior depending on context.

Doesnot guarantee immediate terminationof existing connections.

Manually deleting connections via the command line

Is unnecessary and operationally inefficient.

BIG-IP already provides a supported mechanism (Forced Offline) to cleanly and immediately remove traffic.

Conclusion:

To immediately removeall existing connections, including those maintained by persistence, the BIG-IP Administrator must set the pool member to aForced Offlinestate. This directly satisfies the requirement without additional manual steps.

In BIG-IP, atrunkis a Layer 2 network object used to aggregate multiple physicalinterfacesinto a single logical link. This aggregation providesincreased bandwidthandlink resiliency, commonly in conjunction with LACP.

Key concepts that apply here:

Trunks are managed under the/net trunktmsh hierarchy

Physical interfaces are added or removed using themodifycommand

Thecreatecommand is used only when defining a brand-new trunk, not when updating an existing one

Because the trunk already exists and the goal is toadd interfaces, the correct operation is:

tmsh modify /net trunk trunk_A interfaces add {1.3 1.4}

This command:

Modifies the existing trunk named trunk_A

Adds interfaces 1.3 and 1.4 to the trunk

Immediately increases available bandwidth and redundancy

Why the Other Options Are Incorrect

Buses the /sys hierarchy, which is not used for trunks

Cattempts to create a trunk that already exists

Duses an incorrect hierarchy and an incorrect operation

To select the correct virtual server type, an administrator must balance the need for L7 intelligence versus raw throughput and hardware offloading:

Performance (Layer 4) Virtual Server:This type is designed for maximum speed. It uses thefastL4profile, which allows the BIG-IP system to leverage theePVA (Embedded Packet Velocity Accelerator)hardware chip. When a Performance (L4) virtual server is used, the system processes packets at the network layer (L4) without looking into the application payload (L7). This fulfills the requirement for hardware acceleration and avoids the overhead of HTTP optimization features, which are not needed in this scenario.

Performance (HTTP) Virtual Server:While fast, this type uses thefasthttpprofile to provide some L7 awareness and optimization (like header insertion or small-scale multiplexing). Since the requirement specifically states HTTP optimization isnotrequired, the L4 variant is more efficient.

Standard Virtual Server:This is a full-proxy type. While it offers the most features (SSL offload, iRules, Compression), it processes traffic primarily in the TMOS software layer (or via high-level hardware assistance), which is "slower" than the pure hardware switching path of the Performance (L4) type.

Stateless Virtual Server:This is typically used for specific UDP/ICMP traffic where the system does not need to maintain a connection table. It is not appropriate for standard HTTP (TCP) applications requiring persistent sessions or stateful load balancing.

By choosingPerformance (Layer 4)with thefastL4profile, the organization ensures that the traffic is handled by the hardware acceleration chips, providing the lowest latency and highest throughput possible for their HTTP application.

In BIG-IP high availability (HA) configurations, MAC Masquerade is used to speed up failover by allowing traffic-group-associated Self IPs to retain the same MAC address when moving between devices. This prevents upstream switches and routers from having to relearn ARP entries during a failover event, resulting in near-instant traffic recovery.

By default, MAC masquerade applies one MAC address per traffic group, regardless of how many VLANs the traffic group spans. This can create problems in some network designs because the same MAC address appearing on multiple VLANs may violate network policies or confuse switching infrastructure.

To address this, BIG-IP provides Per-VLAN MAC Masquerade, enabled by the database variable:

`tm.macmasqaddr_per_vlan = true`

When this feature is enabled:

BIG-IP derives a unique MAC address per VLAN

The base MAC address configured on the traffic group remains the first four octets

The last two octets are replaced with the VLAN ID expressed in hexadecimal

The VLAN ID is encoded in network byte order (high byte first, low byte second)

### VLAN ID Conversion:

VLAN ID: 1501 (decimal)

Convert to hexadecimal:

1501₁₀ = 0x05DD

High byte: 05

Low byte: DD

### Resulting MAC Address:

Base MAC: `02:12:34:56:00:00`

Per-VLAN substitution → last two bytes = `05:DD`

Final MAC address:

`02:12:34:56:05:dd`

### Why the Other Options Are Incorrect:

A (01:15) – Incorrect hexadecimal conversion of 1501

B (dd:05) – Byte order reversed (little-endian, not used by BIG-IP)

D (15:01) – Uses decimal values instead of hexadecimal

### Key BIG-IP HA Concept Reinforced:

Per-VLAN MAC Masquerade ensures Layer 2 uniqueness per VLAN while preserving the fast failover benefits of traffic groups, making it the recommended best practice in multi-VLAN HA deployments.

Managing the lifecycle of a pool member requires understanding the difference between "Disabled" and "Forced Offline" states, especially when persistence is involved.

Disabled (User-Disabled): This state allows existing connections and persistent sessions to continue until they naturally time out or are closed by the client/server. It only preventsnewsessions from being established.

Forced Offline: This state is more restrictive; it allows existing connections to complete butrejectsall new connections, including those with existing persistence records.

Immediate Removal: Neither "Disabled" nor "Forced Offline" will instantly kill currently active, established TCP connections. To meet the requirement of "immediately" removing all connections, the administrator must first set the member toForced Offline(to prevent persistence from bringing in new traffic) and then use the command line (e.g., tmsh delete sys connection ss-server-addr [IP]) to clear the current connection table entries.

When establishing a redundant pair, each device must know where to send its health heartbeats and sync data.

The Peer IP:TheFailover Peer IPis the IP address belonging to theotherBIG-IP device in the HA pair. This is typically a34Self-IP on a dedicated "HA" or "Internal" VLAN, or the Management IP.

Purpose:It identifies the destination for the "Heartbeat" (the "Are you alive?" check).

Setup Context:During the initial setup, you tell Device A to look for Device B at its "Failover Peer IP," and you tell Device B to look for Device A at its respective "Failover Peer IP."

Understanding the default behavior of aStandard Virtual Serverregarding address and port translation is fundamental to BIG-IP administration.

Source Address Translation (SNAT):By default, the BIG-IP system doesnotperform Source Address Translation (SNAT). This means that the packet's source IP address (theClient 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 Serveralwaysperforms Destination Address Translation. The BIG-IP system changes the destination IP from the Virtual Server's IP address to the IP address of the specificPool Memberselected by the load balancing algorithm. Consequently, the server-side destination IP is different from the client-side destination IP.

Port Translation:By default,Port Translationis 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, thesettingallows for change, whereas the default SNAT setting (None) ensures the client IP remains static.