F5CAB2 Exam Dumps - F5-CA Questions and Answers

iRules are event-driven scripts that allow for advanced traffic manipulation.

Universality of Events: Every packet that passes through t 21 he BIG-IP data plane triggers events. Even non-HTTP traffic triggers events such as CLIENT_ACCEPTED (when the TCP connection is established 22 ) or CLIENT_DATA (when raw data is received). Therefore, all client traffic—regardless of protocol—has data that can trigger an iRule event.

Event Specificity: Events are not universal (Option C is false). For example, HTTP_REQUEST only occurs after a full HTTP header is parsed. You cannot trigger an HTTP_RESPONSE event before a request has been sent to a server.

Protocol Agnostic: iRules are not limited to HTTP (Option A is false); they can handle TCP, UDP, DNS, FTP, SIP, and more.

Error Handling: If an iRule references an event that never triggers (e.g., an HTTP_REQUEST event in a purely TCP virtual server), the iRule code for that event simply never executes. It does not terminate the connection (Option D is false).

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.

In BIG-IP LTM, a Wildcard virtual server is defined by using a destination IP address of 0.0.0.0. These virtual servers are designed to handle traffic that does not match any more specific Virtual Server destination address.

0.0.0.0 Destination: This address acts as a " catch-all " for IP traffic.

VLAN Specificity: While the destination address is generic, a Wildcard virtual server is typically restricted to a specific VLAN (such as the Internal VLAN) to process outbound traffic from backend servers.

Service Ports: A wildcard virtual server can be configured for a specific port (e.g., 0.0.0.0:80) or for all ports (0.0.0.0:0).

Data Plane Usage: It is commonly used for transparently intercepting outbound traffic for the purpose of Source NAT (SNAT), bandwidth shaping, or directing traffic to a gateway pool.

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.

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.

For BIG-IP to send or receive traffic on a VLAN, that VLAN must be bound to a physical interface or a trunk . Creating a VLAN object and a Self IP alone is not sufficient to establish data-plane connectivity.

From the exhibit:

The VLAN ( vlan_1033 ) exists and has a tag defined.

A Self IP is configured and associated with the VLAN.

However, traffic cannot reach servers on that VLAN.

This indicates a Layer 2 connectivity issue , not a Layer 3 or HA issue.

Why assigning a physical interface fixes the problem:

BIG-IP VLANs do not carry traffic unless they are explicitly attached to:

A physical interface (e.g., 1.1), or

A trunk

Without an interface assignment, the VLAN is effectively isolated and cannot transmit or receive frames, making servers unreachable regardless of correct IP addressing.

Why the other options are incorrect:

A. Set Port Lockdown to Allow All Port Lockdown controls which services can be accessed on the Self IP (management-plane access), not whether BIG-IP can reach servers on that VLAN.

B. Change Auto Last Hop to enabled Auto Last Hop affects return traffic routing for asymmetric paths. It does not fix missing Layer 2 connectivity.

D. Create a Floating Self IP address Floating Self IPs are used for HA failover. They do not resolve reachability issues on a single device when the VLAN itself is not connected to an interface.

Conclusion:

The servers are unreachable because the VLAN has no physical interface assigned . To restore connectivity, the BIG-IP Administrator must assign a physical interface (or trunk) to the VLAN , enabling Layer 2 traffic flow.

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.

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.

In a BIG-IP high availability (HA) configuration, Auto-Sync is a device trust feature that automatically synchronizes configuration changes from the Active device to the Standby device within a Sync-Failover device group.

Key principles from BIG-IP Administration Data Plane Concepts:

The Active device is always the authoritative source of configuration

Configuration changes are intended to be made only on the Active device

With Auto-Sync enabled , any time the Active device configuration changes, the system automatically pushes the configuration to all Standby members of the device group

Configuration changes made directly on a Standby device are not preserved

In this scenario:

The administrator modifies a Virtual Server on the Standby device

That change is local only and does not alter the device group’s synchronized configuration

When Auto-Sync next runs (triggered by a change on the Active device or an internal sync event), the Active device configuration overwrites the Standby configuration

As a result, the configuration change made on the Standby device is undone .

Why the Other Options Are Incorrect:

A – The change is not undone only when another change is made; it is undone during the next Auto-Sync operation

B – Changes made on the Standby device are never propagated to the Active device

D – Auto-Sync does not merge or promote Standby changes into the HA pair configuration

Best Practice Reinforced:

Always perform configuration changes on the Active BIG-IP device when Auto-Sync is enabled to ensure consistent and predictable HA behavior.

===========

In a BIG-IP environment, load balancing and persistence work together but serve different purposes. While a load balancing method like Least Connections attempts to distribute traffic based on current connection counts, a persistence profile overrides this logic for returning clients.

Persistence Overrides Load Balancing: When a persistence profile (such as Source Address or Cookie persistence) is applied to a Virtual Server, the BIG-IP system tracks which client was sent to which backend member.

Sticky Sessions: If a client with a valid persistence record returns, the BIG-IP will send that client to the same pool member it was previously assigned to, regardless of the load balancing algorithm ' s current preference.

Uneven Distribution: If certain clients generate significantly more traffic or stay connected longer than others, the persistence table will " lock " those high-volume flows to specific members, resulting in an uneven distribution of connections across the pool.