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

BIG-IP Priority Group Activation causes members in the highest-numbered priority group to receive traffic first. F5 defines the activation value as the minimum number of available members required before traffic can remain confined to the higher-priority group. If availability falls below that threshold, the system activates the next lower priority group.

Here, Priority Group 3 is the highest group. Of its three members, only 172.16.15.7:80 is available. Because one available member is less than the configured threshold of 2 , BIG-IP must activate Priority Group 2 as well.

In Priority Group 2, only 172.16.15.4:80 is available. Adding this member provides two available members across the currently activated priority groups: 172.16.15.7:80 and 172.16.15.4:80. The required availability threshold is therefore satisfied, so Priority Group 1 does not need to participate. F5 specifically documents that traffic expands into lower-priority groups when the required number of members is unavailable in the higher-priority set.

Because the configured load-balancing method is Round Robin , new connections are distributed across these two eligible members.

Study Guide References/Topics: Pools; Priority-Based Member Activation; Priority Groups; Pool Member Availability; Round Robin Load Balancing.

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).

A Forwarding (IP) virtual server is unique because it does not perform load balancing in the traditional sense.

No Pool Members: Unlike a Standard virtual server, which requires a pool to direct traffic, a Forwarding (IP) virtual server typically has no pool assigned .

Destination-Based Routing: The BIG-IP system looks at the destination IP address in the original packet header sent by the client. It then consults the BIG-IP system ' s local routing table to determine where to send the packet.

Transparency: It acts as a high-performance router/gateway, often used to forward traffic from internal servers to the internet or across different subnets while still allowing the BIG-IP to apply features like SNAT or bandwidth controllers.

Stateful Tracking: While it forwards traffic based on the routing table, it still creates an entry in the connection table to track the flow (unless it is a Stateless virtual server).

In the F5 BIG-IP system, virtual servers are categorized based on their destination address and mask. The system distinguishes between three primary destination scopes:

Host Virtual Server: A virtual server that has a specific IP address (e.g., 10.10.10.50) and a /32 mask.

Network Virtual Server: A virtual server that has a destination address representing a subnet (e.g., 192.168.10.0) and a specific mask (e.g., /24).

Wildcard Virtual Server: A virtual server that has a destination address of 0.0.0.0 (or :: for IPv6) and a mask of 0.0.0.0 (or /0).

While a " Forwarding (IP) " virtual server (Option D) is the Type (behavioral configuration) often used to route traffic without load balancing, the term Wildcard (Option C) is the specific administrative term used to define the " type " of virtual server based on the 0.0.0.0 destination address .

A common architectural use case is to create a Wildcard Virtual Server that listens only on an internal VLAN to act as a default gateway for outbound traffic (Internet access) for back-end servers. This ensures the BIG-IP system can process and forward traffic that does not match any other specific virtual server configuration.

BIG-IP uses a virtual server matching and precedence algorithm to determine which virtual server processes an incoming connection. This decision is made entirely in the data plane and is based on how specifically a virtual server matches the destination IP address and port.

BIG-IP Virtual Server Selection Rules (Simplified):

When multiple virtual servers could match a packet, BIG-IP selects the most specific match , using the following precedence:

Exact IP address and exact port

Exact IP address with wildcard port (port 0 / any)

Wildcard IP address with exact port

Wildcard IP address and wildcard port

Applying the Rules to This Scenario:

Incoming traffic destination: 1.0.0.10:8080

Option C: 1.0.0.10:8080

Exact IP match

Exact port match

Highest possible specificity

If the virtual server is available (green), it wins the match

Option B: 1.0.0.10:any

Exact IP match, but wildcard port

Lower priority than an exact IP + exact port match

Option D: 0.0.0.0:8080

Wildcard IP, exact port

Lower priority than an exact IP match

Option A: 0.0.0.0:any

Wildcard IP and wildcard port

Lowest priority, used only if no more specific virtual server exists

Final Determination:

Because a virtual server configured with destination 1.0.0.10:8080 exactly matches both the IP address and port of the incoming connection—and is available—it will always be selected to process the traffic.

Key Data Plane Concept Reinforced:

BIG-IP always processes traffic using the most specific matching virtual server . Exact destination IP and port matches take precedence over any wildcard or forwarding virtual server definitions.

===========

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.

To meet the requirement of fault tolerance when one interface goes down , BIG-IP must use link aggregation so 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 provides redundancy (and possibly bandwidth aggregation).

VLANs are assigned to interfaces or trunks. If you need multiple VLANs on the same trunk , they must use 802.1Q tagging (because you can only have one untagged VLAN per interface/trunk).

Self IPs are 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 have two physical interfaces and you want resiliency if one fails → put both interfaces into one trunk with LACP enabled .

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

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

Why the other options are incorrect

A : Two VLANs cannot both be untagged on 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.

===========

An Application Delivery Controller (ADC) provides application traffic-management functions between clients and application servers. Two fundamental ADC capabilities represented here are SSL offloading and load balancing .

SSL offloading allows the BIG-IP system to terminate client-side SSL/TLS connections and perform the cryptographic processing that would otherwise consume application-server resources. F5 specifically describes SSL offload as the BIG-IP system performing the SSL handshake and encryption/decryption functions normally performed by the destination server. Client SSL profiles are commonly applied to virtual servers to implement this functionality.

Load balancing is another core ADC function. BIG-IP LTM uses pools and configured load-balancing algorithms to select an appropriate pool member for each connection or request. For example, with Round Robin, BIG-IP distributes incoming requests sequentially across available pool members. F5 identifies the load-balancing method as a fundamental property of a server pool.

Log collecting can occur as part of system administration and telemetry, but it is not one of the fundamental ADC functions being tested here. Screen sharing is an end-user collaboration capability and has no role in ADC traffic delivery.

Study Guide References/Topics: Application Delivery Controller Functions; SSL/TLS Offload; Virtual Servers and SSL Profiles; Pools; Load-Balancing Methods.

===============

The BIG-IP system uses a specific precedence algorithm to determine which virtual server (listener) should process an incoming packet when multiple virtual servers might match the criteria. Since BIG-IP version 11.3.0, the system evaluates three primary factors in a fixed order of importance:

Destination Address: The system first looks for the most specific destination match. A " Host " address (mask /32) is preferred over a " Network " address (mask /24, /16, etc.), which is preferred over a " Wildcard " (0.0.0.0/0).

Source Address: If multiple virtual servers have identical destination masks, the system then evaluates the source address criteria. Again, a specific source host match is preferred over a source network or a wildcard source.

Service Port: Finally, if both destination and source specifications are equal, the system checks the port. A specific port match (e.g., 80) is preferred over a wildcard port (e.g., or 0).

Following this logic, a virtual server configured with a specific destination host , a specific source host , and a specific service port represents the highest level of specificity and thus the highest preference.

Although remote authentication (LDAP, RADIUS, TACACS+) is a control-plane / management-plane feature, it directly affects availability and resiliency of administrative access , which is a critical operational HA consideration.

How BIG-IP Remote Authentication Works:

BIG-IP can authenticate administrators against:

LDAP

RADIUS

TACACS+

When remote authentication is enabled, BIG-IP by default relies on the remote server for user authentication

If the remote authentication server becomes unreachable, administrators may be locked out unless fallback is configured

Why “Fallback to Local” Is Required:

The Fallback to Local option allows BIG-IP to:

Attempt authentication against the remote authentication server first

If the remote server is unreachable or unavailable , fall back to:

Local BIG-IP user accounts (admin, or other locally defined users)

This ensures:

Continuous administrative access

Safe recovery during:

Network outages

Authentication server failures

Maintenance windows

This behavior is explicitly recommended as a best practice in BIG-IP administration to avoid loss of management access.

Why the Other Options Are Incorrect:

A. Configure a second remote user directory

Provides redundancy only if both directories are reachable

Does not help if remote authentication as a whole is unavailable

B. Configure a remote role group

Maps remote users to BIG-IP roles

Does not affect authentication availability

D. Set partition access to “All”

Controls authorization scope after login

Has no impact on authentication success

Key Availability Concept Reinforced:

To maintain administrative access resiliency , BIG-IP administrators should always enable Fallback to Local when using remote authentication. This prevents lockouts and ensures access even during authentication infrastructure failures.

===========

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 prevents new sessions from being established.

Forced Offline : This state is more restrictive; it allows existing connections to complete but rejects all 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 to Forced 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.

In a large-scale BIG-IP environment with hundreds of virtual servers, the Network Map is the most effective tool for visualizing and auditing the relationships between various ADC objects.

The Network Map Functionality: The Network Map provides a hierarchical view of the local traffic objects. It allows an administrator to see the status and dependencies of Virtual Servers, Pools, Pool Members, and associated iRules all in one screen.

Search and Filter: By navigating to Local Traffic > Network Map , the administrator can use the Advanced Filter . This feature allows for searching specifically for an iRule name or a string within an iRule definition. Once the filter is applied, the system displays only the Virtual Servers that are associated with that specific iRule.

Efficiency: While the " Virtual Server List " (Option D) can be customized to show columns for iRules, it is often cumbersome to scroll through hundreds of entries. The " iRules List " (Option B) displays the scripts themselves but does not provide a reverse-lookup list of all associated virtual servers in a single view as efficiently as the Network Map.

Summary of Relationships: The Network Map is specifically designed to answer the question, " What is this object connected to? " making it the primary administrative interface for impact analysis during configuration changes.

When handling high-volume UDP traffic where the BIG-IP does not need to maintain any session history or relationship between packets, a Stateless virtual 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.

In the BIG-IP object hierarchy, the destination port for backend traffic is defined at the Pool Member level. While a Virtual Server listens on a specific port, the Pool determines where that traffic is directed after the load balancing decision is made.

Pools and Pool Members : A pool is a collection of devices, often called pool members, to which the BIG-IP system passes traffic. Each pool member is defined by an IP address and a service port.

Port Translation : When an administrator needs to change the port the BIG-IP uses to communicate with backend servers, they must navigate to the specific Pool and modify the service port for each member within that pool.

Logical Separation :

Virtual Servers define the " front-end " port where clients connect.

Pools define the " back-end " port where the application resides.

Nodes represent the physical server ' s IP address and do not contain port-specific configuration.

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.

F5 BIG-IP uses a ConfigSync mechanism to ensure that all members of a Device Service Cluster (DSC) share the same configuration.

Manual Synchronization: By default, configuration changes made on one device (the " source " ) do not automatically propagate to other members.

Direction of Sync: Once a Virtual Server is created on device 1, that device ' s configuration is now " newer " than the rest of the group. The administrator must initiate a synchronization from the modified device (device 1) to the Sync-Failover group .

Consistency: This ensures that if a failover occurs, device 2 (the standby) will have the exact same Virtual Server configuration and can take over traffic immediately without interruption.

Configuring networking objects in BIG-IP requires using the correct TMSH module path and verb .

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.

When managing a large environment with hundreds of Virtual Servers, the most efficient way to identify the relationship between an iRule and the objects it manages is to view the properties of the iRule itself.

iRule Properties: Within the BIG-IP Configuration Utility, navigating to Local Traffic > iRules and selecting a specific iRule provides a " Statistics " or " Usage " tab (depending on the version). This view explicitly lists all Virtual Servers currently associated with that specific iRule.

Centralized Management: Instead of manually checking 235 individual Virtual Servers under the " Virtual Servers " menu, the iRules menu acts as a central point of reference for that specific logic.

Data Plane Impact: Because iRules can modify traffic flow, headers, and load balancing decisions, seeing the full list of affected Virtual Servers is critical before making adjustments to avoid unintended side effects across the application portfolio.

On BIG-IP, a disabled pool member is deliberately treated differently from a member that is unavailable because of a failed health monitor or one that has been forced offline . Disabling a pool member removes it from normal load-balancing selection for new, unrelated sessions, but BIG-IP can continue sending traffic associated with existing active connections and existing persistence sessions to that member.

F5 documentation states specifically that when a pool member is disabled, it continues to process active connections and connections belonging to the current persistence session. F5 also describes the disabled state as allowing “persistent or active connections” while preventing ordinary new load-balanced connections.

The relevant persistence configuration is attached to the virtual server , making A correct. When a client has an existing persistence record—for example, source-address affinity—the persistence decision can continue directing that client ' s connections to its previously selected pool member even though that member has subsequently been disabled.

Slow Ramp Time serves a different purpose: it gradually increases connection allocation to a newly available pool member so that it is not immediately overwhelmed. It does not explain continued access to disabled members. A persistence profile is not configured on the pool itself, eliminating D.

Study Guide References/Topics: Pool Member States; Disabled versus Forced Offline; Persistence Profiles; Virtual Server Persistence; Connection Processing; Slow Ramp Time.