F5CAB2 Practice Questions

The exhibit reveals a configuration mismatch in the VLAN Tag settings between the high-availability (HA) peers. The Active Device (top) is configured with a Tag value of 121 (visible in the "Tag" field), while the Standby Device (bottom) has a mismatched Tag value (visually distinct, appearing as 122).

In a BIG-IP HA configuration, the network settings—specifically 802.1Q VLAN tags—must be identical on both units to match the upstream switch configuration. Since the Active unit is currently processing traffic successfully, its configuration (Tag 121) is correct for the network environment. The outage occurs upon failover because the Standby unit attempts to communicate using the wrong VLAN tag (122), causing the connected switch to drop the tagged frames. The administrator must modify the Standby device's Tag to match the Active device (121).

B. The interface on the Active device to 1.1: The Active device is currently working, meaning its interface configuration (using interface 1.2) is correct. Changing it would cause an immediate outage.

C. The Tag value on the Active device: Modifying the Tag on the Active device would break the currently functioning connection, causing an immediate outage instead of fixing the failover issue.

D. The Interface on the Standby device to 1.1: The screenshot shows that interface 1.2 is assigned on both devices (visible in the list below the "Add" button). The dropdown showing "1.1" is merely the selection state, not the active configuration.

F5 Networks. (n.d.). BIG-IP TMOS: Implementations - Configuring VLANs and VLAN Groups. F5 Tech Docs. (Confirming that VLAN tags identify traffic and must match the external switch configuration).

F5 Networks. (n.d.). K7534: Troubleshooting VLAN connectivity. MyF5 Support. Retrieved from https://my.f5.com/manage/s/article/K7534 (States that incorrect 802.1Q tagging is a common cause of connectivity failure).

F5 Networks. (n.d.). K1393: VLANs and 802.1Q tagging. MyF5 Support. Retrieved from https://my.f5.com/manage/s/article/K1393 (Explains that mismatched tags prevent successful L2 communication).

MAC masquerading is a feature specifically designed to minimize traffic disruption during a BIG-IP device failover. It assigns a unique, non-device-specific MAC address to a traffic group. When a failover occurs, the newly active unit takes over this same MAC address along with the floating IP addresses. This prevents upstream network devices, such as switches and routers, from needing to update their Address Resolution Protocol (ARP) caches with a new MAC address. By keeping the MAC address consistent, network convergence time is significantly reduced, resulting in a faster and more seamless failover.

A. External monitors are used to verify the health and availability of pool members (backend servers), not to manage the network impact of a BIG-IP system failover.

B. A clone pool is used to copy traffic to another interface or device, typically for monitoring or intrusion detection, and has no role in the failover process.

C. A OneConnect profile optimizes server-side TCP connections for performance and efficiency but does not address the Layer 2 network transition that occurs during a device failover.

1. F5 Networks, BIG-IP Device Service Clustering: Administration, Version 16.1, Chapter: Configuring High Availability.

Section: MAC masquerade address: "When a device fails over, the new active device begins processing traffic for the traffic group, using the MAC masquerade address. Because the MAC address has not changed, the upstream router and other network devices do not need to update their Address Resolution Protocol (ARP) caches. This prevents a disruption in traffic."

2. F5 Networks, BIG-IP Local Traffic Manager: Concepts, Version 16.1, Chapter: Monitors.

Section: About Monitors: "A monitor is a component of the BIG-IP system that you use to check the status of any network device, such as a pool member or node." This confirms monitors are for checking backend resources, not for managing failover impact.

3. F5 Networks, BIG-IP Local Traffic Manager: Concepts, Version 16.1, Chapter: Profiles.

Section: Understanding the OneConnect profile: "The OneConnect™ profile causes the BIG-IP system to minimize the number of server-side TCP connections by re-using existing connections for subsequent requests." This clarifies its purpose as connection optimization, not failover management.

The "Fallback to Local" option is a specific setting within the remote authentication configuration (e.g., RADIUS, LDAP, TACACS+) on a BIG-IP system. When enabled, it instructs the BIG-IP to attempt authentication against its local user database if the configured remote authentication servers are unreachable or fail to respond. This mechanism ensures that administrators can still gain access to the BIG-IP device for management purposes, even during a remote authentication service outage, thereby meeting the requirement for continued login capability.

A. Configure a second remote user directory: This provides redundancy for the remote authentication service but does not enable a fallback to the BIG-IP's local user database if all remote servers are unavailable.

B. Configure a remote role group: This is an authorization function that maps remote user groups to BIG-IP administrative roles and partitions. It does not affect the authentication fallback process.

D. Set partition access to All: This is an authorization setting that grants a user account access to all administrative partitions. It is unrelated to authentication methods or fallback procedures.

1. F5 Networks, BIG-IP System: User Account Administration, Version 17.1. In the chapter "Remote User Account Management," the section "Configuring TACACS+ authentication for BIG-IP system users" describes the setting: "Fallback to Local: When you enable this setting, if the remote TACACS+ servers are unavailable for authentication, the BIG-IP system attempts to authenticate the user against the local user database." This same principle and setting name apply to other remote authentication methods like RADIUS and LDAP. (Reference: F5 BIG-IP v17.1 Documentation, support.f5.com)

2. F5 Networks, BIG-IP System: Authentication and Single Sign-On, Version 16.1. The chapter "BIG-IP System Authentication" details the various authentication methods. In the section for configuring remote authentication sources, the fallback option is consistently presented as the mechanism to ensure local login is possible when remote servers are down. (Reference: F5 BIG-IP v16.1 Documentation, support.f5.com)

3. F5 Knowledge Base Article K93018455: Configuring remote user authentication and authorization. This article outlines the steps for setting up remote authentication and explicitly mentions the "Fallback" setting as the means to "allow local authentication to be used if the remote authentication servers are unavailable." (Reference: MyF5 Knowledge Base, my.f5.com)

The requirements are for hardware-accelerated performance for an HTTP application without needing any HTTP-specific (Layer 7) optimization features. A Performance (Layer 4) virtual server with a fastL4 profile is the ideal choice. This configuration operates at the transport layer (L4), leveraging the Packet Velocity ASIC (PVA) for hardware acceleration to forward packets at very high speeds. It does not inspect or modify the HTTP payload, which perfectly aligns with the requirement that no HTTP optimization is needed, thus providing maximum throughput with minimal processing overhead.

A. Type: Stateless Protocol Profile: fastL4

A Stateless virtual server is for connectionless protocols like UDP. HTTP requires a stateful TCP connection, making this type unsuitable.

B. Type: Standard Protocol Profile: tcp-wan-optimized

A Standard virtual server is a full proxy, which introduces more overhead than a performance-optimized type. The tcp-wan-optimized profile is for high-latency networks, not general hardware acceleration.

D. Type: Performance (HTTP) Protocol Profile: fasthttp

This type provides some HTTP processing (like OneConnect), which contradicts the requirement that no HTTP optimization features are needed. It is less performant than a pure L4 configuration.

1. F5 BIG-IP LTM Concepts Guide (v15.1), Chapter: "Virtual Servers", Section: "Virtual server types".

Page 2-4: Describes the Performance (Layer 4) virtual server: "A Performance (Layer 4) virtual server is one that has a FastL4 profile associated with it. A Performance (Layer 4) virtual server increases the speed at which the virtual server processes traffic." This directly supports using this type for performance.

2. F5 BIG-IP LTM Concepts Guide (v15.1), Chapter: "Profiles", Section: "Protocol profiles".

Page 3-2: Explains the FastL4 profile: "The FastL4 profile is a protocol profile that you can use to speed up packet processing. The FastL4 profile does this by using the BIG-IP system's Packet Velocity ASIC (PVA) to accelerate traffic." This confirms its role in hardware acceleration.

3. F5 BIG-IP LTM Concepts Guide (v15.1), Chapter: "Virtual Servers", Section: "Virtual server types".

Page 2-5: Describes the Performance (HTTP) virtual server: "A Performance (HTTP) virtual server is a virtual server with a Fast HTTP profile associated with it. A Performance (HTTP) virtual server is designed to speed up certain types of HTTP connections..." This shows it is intended for when some HTTP-level features are desired, which is not the case here.

To achieve fault tolerance with two physical interfaces, they must be aggregated into a single logical link, known as a trunk. Enabling Link Aggregation Control Protocol (LACP) on the trunk allows the BIG-IP system to dynamically negotiate with the upstream switch, providing robust link failure detection and redundancy. To transport traffic for two distinct VLANs (external and internal) over this single logical trunk, the traffic for each VLAN must be identifiable. This is accomplished using IEEE 802.1Q VLAN tagging, where each frame is tagged with the ID of the VLAN to which it belongs. This configuration correctly provides both fault tolerance and multi-VLAN support.

A. A single link or trunk can only have one untagged (native) VLAN; configuring both VLANs as untagged is an invalid configuration.

B. Creating two separate trunks is not a valid or efficient design with only two physical interfaces, as a trunk requires member interfaces for aggregation.

C. This option is invalid as two trunks cannot be created from only two interfaces, and this design does not correctly implement multi-VLAN transport.

1. F5 Networks, BIG-IP TMOS: Implementations, v17.1.0, Chapter: Working with VLANs and Trunks.

Section: About trunks: "A trunk is a combination of two or more interfaces and is used to increase bandwidth and provide redundancy." This supports the use of a trunk for fault tolerance.

Section: About VLANs: "When you configure a trunk on the BIG-IP system, you can associate the trunk with one or more VLANs. When you associate a trunk with more than one VLAN, the BIG-IP system tags the frames that it sends on that trunk." This directly confirms that a trunk with multiple VLANs requires tagging.

2. F5 Networks Knowledge Base, K6133: VLAN-tagged and untagged traffic, Published: Feb 23, 2015.

Section: Summary: "A VLAN-tagged interface can process traffic for multiple VLANs... An untagged interface can process traffic for only a single VLAN." This reference invalidates option A, which suggests using two untagged VLANs on one trunk.

3. F5 Networks Knowledge Base, K7214: Overview of BIG-IP LACP, Published: Feb 23, 2015.

Section: Description: "The Link Aggregation Control Protocol (LACP) is part of the IEEE 802.3ad specification. LACP provides additional link aggregation functionality and failover." This confirms that LACP is the standard protocol used to enable fault tolerance in a trunk.

The End-User Diagnostics (EUD) utility is a hardware testing tool that runs independently of the main Traffic Management Operating System (TMOS). When a BIG-IP appliance fails to boot, network interfaces, including the management port and data plane VLANs, are not yet initialized and are therefore inaccessible. The only reliable method to interact with the system at a pre-boot level is through a direct serial connection to the console port. This provides access to the boot menu, from which the administrator can select and launch the EUD utility to diagnose hardware issues.

B. Internal VLAN interface: This is a data plane interface that is only available after the system has successfully booted and the Traffic Management Microkernel (TMM) is running.

C. External VLAN interface: Similar to the internal interface, this is a data plane port that requires a fully booted system and running TMM to be accessible.

D. Management Port: This port requires the control plane's networking stack to be active for IP-based access (e.g., SSH, HTTPS), which is not guaranteed on a system that fails to boot.

1. F5 Networks Knowledge Base, K7736: Running the End-User Diagnostics utility.

Reference: In the "Running the EUD" section, the first prerequisite step states: "To run the EUD, you must have a console connection to the BIG-IP system." This explicitly confirms that console access is mandatory.

2. F5 Networks Platform Guide: rSeries.

Reference: In the chapter "Maintaining the rSeries System," the section "Running the End-User Diagnostics" states: "To run the EUD, you must have a console connection to the BIG-IP system." This instruction is consistent across various F5 hardware platform guides.

3. F5 Networks BIG-IP System: Initial Configuration.

Reference: In the section "Connecting a serial terminal to the BIG-IP system," the documentation describes the console port as the primary means for initial setup and for troubleshooting when network access is unavailable, which includes boot failure scenarios.

In a standard BIG-IP high-availability (HA) active/standby pair with Auto-Sync enabled, the configuration on the Active device is considered the master or source configuration. The primary purpose of Auto-Sync is to ensure the Standby device's configuration is a mirror of the Active device's. When an administrator makes a change directly on the Standby device, that device becomes temporarily out-of-sync. The next time a synchronization event occurs (which is automatically triggered by a configuration save on the Active device), the system will propagate the configuration from the Active device to the Standby device. This synchronization process will overwrite any local changes made on the Standby unit, effectively undoing them.

A. This describes the most common trigger for the synchronization, but option C more accurately describes the mechanism that undoes the change.

B. Configuration synchronization propagates from the Active to the Standby device. A change on the Standby will not be propagated to the Active device.

D. The change made on the Standby device will be overwritten and lost during the next sync; it will not take effect across the HA pair.

1. F5 Networks, BIG-IP Device Service Clustering: Administration, Version 16.1.

Chapter: Managing BIG-IP Device Groups

Section: Synchronizing configuration data > Understanding automatic synchronization

Quote: "However, if you have a standard active/standby configuration, you should make configuration changes on the active device only. If you make a change on the standby device, that change is lost when the active device synchronizes its configuration to the standby device." This directly confirms that changes on the standby are undone by the synchronization process.

2. F5 Networks, K14856: The 'Recommended' and 'Not Recommended' ways to configure device groups.

Section: Not Recommended

Content: This knowledge base article reinforces the principle that in an active-standby pair, all configuration changes should be performed on the active unit. Making changes on the standby unit can lead to a loss of those changes upon the next configuration synchronization from the active unit. This supports the conclusion that the change will be undone.

To increase the total available bandwidth beyond the capacity of a single physical interface, the BIG-IP Administrator should use link aggregation. On a BIG-IP system, this is implemented by creating a trunk object. A trunk combines multiple physical interfaces into a single logical link, effectively summing their bandwidth. The existing VLAN can then be associated with this new, higher-capacity trunk object instead of the single, saturated interface. This allows traffic to be distributed across the member interfaces of the trunk, overcoming the single-link bottleneck.

Why Incorrect Options are Wrong

A. Increase the MTU on the VLAN using interface 1.1

Increasing the MTU allows for larger packet payloads, which can slightly improve efficiency but does not increase the physical link's fundamental bandwidth (bits per second).

C. Assign two interfaces to the VLAN

Assigning multiple interfaces to a VLAN makes the BIG-IP act as a simple Layer 2 switch for that VLAN; it does not aggregate the bandwidth for traffic flows.

D. Set the media speed of interface 1.1 manually

The media speed is limited by the physical hardware. The question implies the interface is already at its maximum capacity, which cannot be increased via a software setting.

---

References

1. F5 Networks, BIG-IP TMOS: Implementations, v17.1, Chapter: Trunks.

Section: About Trunks

Content: "A trunk is a combination of two or more interfaces and Link Aggregation Control Protocol (LACP) that you can create to increase bandwidth. When you create a trunk, the BIG-IP system can treat the trunk as a single interface. The system then balances traffic across all interfaces in the trunk." This directly supports creating a trunk to increase bandwidth.

2. F5 Networks, BIG-IP TMOS: Implementations, v17.1, Chapter: VLANs.

Section: About VLANs

Content: The documentation describes how a VLAN is a logical collection of hosts and that interfaces are assigned to it. It explains that assigning multiple interfaces creates a broadcast domain but does not mention bandwidth aggregation in this context, which is the specific function of a trunk. This clarifies why simply assigning multiple interfaces (Option C) is not the correct approach for bandwidth aggregation.

3. F5 Networks, BIG-IP TMOS: Implementations, v17.1, Chapter: Interfaces.

Section: Working with Interfaces

Content: This section details the configuration of physical interface properties like media speed and MTU. It clarifies that media speed settings are constrained by the physical capabilities of the hardware, supporting the reasoning that Option D is incorrect. It also shows MTU is a packet size setting, not a bandwidth setting, making Option A incorrect.

To avoid overloading a pool member immediately after it becomes active (or returns to service), the administrator should configure Slow Ramp Time. This feature allows the BIG-IP system to gradually increase the amount of traffic sent to a newly available pool member over a specified period (in seconds), rather than sending a full proportion of traffic instantly. By default, when a member becomes available, load balancing methods like "Least Connections" might otherwise direct a flood of new requests to it because it has zero current connections. Slow Ramp Time prevents this "thundering herd" effect, ensuring the server warms up gracefully before handling its full share of the load.

B. Different Ratio for each member: Ratio load balancing distributes traffic based on server capacity weights (e.g., 3:1) continuously, but it does not throttle the rate of new connections specifically when a member first comes online.

C. Action On Service Down to Reselect: This setting determines how the system handles existing connections when a pool member fails (goes down), ensuring clients are redirected, but it does not manage the traffic flow when a member comes up.

D. Same Priority Group to each member: Priority Groups control the activation order of servers for redundancy (e.g., active vs. standby servers within a pool), not the rate at which traffic is applied to a specific member once it becomes active.

F5 Networks. (n.d.). BIG-IP Local Traffic Management: Pools - Configuring Slow Ramp Time. F5 Tech Docs. (States: "Slow Ramp Time... allows a pool member to gradually accept connections over a specified period of time... to prevent the pool member from being overloaded").

F5 Networks. (n.d.). K10430: Overview of the Slow Ramp Time feature. MyF5 Support. Retrieved from https://my.f5.com/manage/s/article/K10430 (Explains that this feature prevents a newly available node from being swamped with connections).

F5 Networks. (n.d.). BIG-IP Local Traffic Management: Implementations. Chapter: Managing Pool Members. (Documentation on using Slow Ramp Time to smooth load distribution during member recovery).

F5 Networks. (n.d.). K15095: Overview of the Action On Service Down feature. MyF5 Support. Retrieved from https://my.f5.com/manage/s/article/K15095 (Defines this feature as handling traffic for members that have become unavailable, not those becoming available).

The BIG-IP system selects a virtual server based on the principle of most specific match. The matching logic prioritizes the destination IP address first, followed by the destination port. A virtual server configured with the exact destination IP and port (1.0.0.10:8080) is the most specific match for the incoming connection. This exact match takes precedence over any virtual servers configured with wildcard IP addresses (e.g., 0.0.0.0) or wildcard ports (e.g., any or 0). The virtual server's availability, indicated by a green status, is also a prerequisite for it to process the connection.

A. This is the least specific match, using a wildcard for both IP and port, and would only be selected if no more specific virtual server exists.

B. This is less specific than an exact IP and port match because it uses a wildcard port, even though the IP address matches.

D. This is less specific than an exact IP and port match because it uses a wildcard IP address, which has a lower precedence than a specific IP.

1. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, 16.1. "About Virtual Servers," Section: "Virtual server matching." The documentation states, "The BIG-IP system checks for a virtual server that is a specific match for the destination IP address and service port of the packet."

2. F5 Networks. (2021, May 18). K14800: Order of precedence for virtual server matching. F5 Knowledge Base. This article explicitly details the matching order, confirming that a specific destination IP address and port is the highest priority match.

3. F5 Networks. (2021). BIG-IP Local Traffic Manager: Concepts, 16.1. "About Virtual Servers," Section: "Virtual server availability." This section explains that a virtual server's availability (e.g., green status) determines its ability to process traffic.