F5CABR (BIG-IP Recert) common mistakes
F5CABR (BIG-IP Recert) · Understand the traps and how to avoid them.
Assuming a Standard virtual server automatically load balances across all pool members without checking the load balancing method and pool member health monitors. Candidates often select 'Round Robin' as the default and overlook that the default method is actually 'Least Connections (member)' and that pool members are only eligible if their health monitor is green.
The default load balancing method for a new pool is Least Connections (node), not Round Robin, and many candidates confuse the two. Also, virtual server defaults to a TCP profile and a default pool with no monitor, so all members appear available regardless of actual health.
What to do instead
Memorize the default pool load balancing method (Least Connections (node)) and verify monitor status on each member. In the GUI, check Local Traffic > Pools > [pool] > Members and confirm the 'Availability' column is green. For the exam, remember that a virtual server forwards traffic to a pool only if the pool has at least one available member; otherwise, it sends a reset or uses a fallback host if configured.
Configuring a virtual server with a destination address of 0.0.0.0/0 and expecting it to match only traffic to the virtual server's IP, when in fact it becomes a wildcard virtual server that can conflict with other virtual servers and cause unexpected traffic redirection.
Candidates confuse a wildcard virtual server (used for transparent traffic steering) with a standard virtual server. The 0.0.0.0/0 destination matches any destination IP, and if placed before other virtual servers in the precedence order, it can capture traffic intended for them.
What to do instead
Use specific destination IP addresses for standard virtual servers. Reserve wildcard virtual servers for cases like a default gateway for outbound traffic or for a catch-all when explicitly needed. Understand virtual server precedence: host address > network address > wildcard, and port-specific > wildcard port. Check the order in Local Traffic > Virtual Servers and adjust the 'Order' or use a more specific destination.
Creating a client SSL profile with a certificate and key but forgetting to attach it to the virtual server, or attaching it but not setting the virtual server's destination port to 443, resulting in SSL handshake failures or traffic not being decrypted.
Candidates focus on the profile configuration and overlook the binding step. They may also assume that simply creating the profile enables SSL termination. Additionally, they might not realize that the virtual server must listen on the correct port (usually 443) and that the SSL profile must be selected in the virtual server's 'SSL Profile (Client)' setting.
What to do instead
After creating the client SSL profile, edit the virtual server, set the destination port to 443 (or the appropriate port), and under 'SSL Profile (Client)' select the profile. Verify with 'tmsh list ltm virtual ' that the profile is listed. Test with 'openssl s_client -connect :443' to confirm the certificate is presented.
Misunderstanding persistence: configuring a persistence profile on a virtual server but not enabling it, or using the wrong persistence type (e.g., source address affinity when cookie persistence is required), leading to sessions being redistributed to different pool members.
Candidates often think that simply creating a persistence profile is enough, but it must be attached to the virtual server's 'Default Persistence Profile' setting. They may also confuse persistence with load balancing methods and choose source address persistence for HTTP applications where cookie persistence is more appropriate.
What to do instead
Attach the persistence profile to the virtual server under 'Default Persistence Profile'. For HTTP applications, use cookie persistence (insert mode) to ensure session stickiness. Verify persistence by checking 'tmsh show ltm persistence persist-records' and ensuring entries exist. Understand that persistence overrides the load balancing method for subsequent connections from the same client.
Configuring a SNAT pool or automap for outbound traffic but forgetting to configure a self IP and a default route, resulting in outbound connections failing or being SNATed to an unexpected address.
Candidates focus on the SNAT configuration itself and overlook the underlying network prerequisites: the BIG-IP needs a self IP on the VLAN, a default route to the gateway, and the SNAT address must be routable. They may also confuse SNAT with SNAT pool and not realize that automap uses the self IP of the egress VLAN.
What to do instead
Verify that the BIG-IP has a self IP on the internal and external VLANs, a default route pointing to the external gateway, and that the SNAT pool contains valid IP addresses. Use 'tmsh list net self' and 'tmsh list net route' to confirm. For automap, ensure the egress VLAN's self IP is the intended source address. Test with 'tcpdump' on the external VLAN to see the source IP.
Setting up a sync-failover device group but not assigning traffic groups to the correct device, or not configuring network failover, so that failover does not occur or traffic groups do not float as expected.
Candidates understand the concept of device groups and traffic groups but miss the step of assigning traffic groups to devices and configuring the failover method (network failover or hard-wired failover). They may also forget to synchronize the configuration after changes, leading to inconsistent states.
What to do instead
In Device Management > Traffic Groups, ensure each traffic group has a 'Failover Method' (usually network failover) and that the 'Auto Failback' setting is appropriate. Verify that each device has a self IP for network failover. Use 'tmsh run cm config-sync' to synchronize. Check 'tmsh show cm sync-status' and 'tmsh show cm failover-status' to confirm the active/standby state.
When configuring an access policy with APM, forgetting to attach the access profile to the virtual server, or not configuring the appropriate iRule or access policy results in the access policy not being enforced.
Candidates create the access profile and policy but miss the binding to the virtual server. They may also not realize that the access profile must be selected in the virtual server's 'Access Policy' setting, and that the virtual server must have an HTTP profile to process the authentication redirects.
What to do instead
Edit the virtual server, under 'Access Policy' select the access profile. Ensure the virtual server has an HTTP profile attached. Verify with 'tmsh list ltm virtual ' that the access-policy is listed. Test by accessing the virtual server and confirming the login page appears.
Configuring an AFM policy with a rule to block traffic but not applying it to the correct context (global, virtual server, or route domain), or not enabling the policy, so that the rule does not take effect.
Candidates create firewall rules and policies but forget to enforce them. AFM policies can be applied globally, per virtual server, or per route domain. They may also not realize that the policy must be enabled and that the rule order matters (first match wins).
What to do instead
After creating the AFM policy, apply it to the desired context: for global, go to Security > Network Firewall > Active Rules and ensure the policy is assigned; for virtual server, edit the virtual server and select the policy under 'Firewall Policy'. Verify with 'tmsh list security firewall policy' and 'tmsh show security firewall active-rules'. Test by sending traffic that should be blocked.
Assuming that a health monitor is automatically associated with pool members when creating a pool, or using the default TCP monitor without customizing it, leading to false positives or negatives in member availability.
Candidates think that creating a pool with members automatically adds a health monitor. In reality, the default monitor is 'tcp' only if explicitly selected, and many pools are created with no monitor. They may also not understand that the monitor must be assigned to the pool or individual members, and that the monitor's interval and timeout settings affect failover speed.
What to do instead
When creating a pool, explicitly add a health monitor (e.g., http, https, tcp) under 'Health Monitors'. For custom applications, create a custom monitor with appropriate send and receive strings. Verify monitor status with 'tmsh show ltm pool members' and check the 'Monitor Status' column. Adjust interval and timeout to balance detection speed and overhead.
Using the default 'tcp' profile for a virtual server that handles HTTP traffic, or not attaching an HTTP profile, resulting in features like cookie persistence, HTTP compression, or iRules that rely on HTTP parsing not working.
Candidates create a virtual server and select a pool but leave the default TCP profile, not realizing that many application-layer features require an HTTP profile. They may also not understand that iRules with HTTP commands need an HTTP profile to function.
What to do instead
For HTTP applications, attach an HTTP profile to the virtual server (e.g., 'http'). This enables HTTP parsing, cookie persistence, and HTTP iRules. Verify with 'tmsh list ltm virtual profiles' that the http profile is listed. If using iRules with HTTP commands, ensure the HTTP profile is present; otherwise, the iRule may fail to execute.