F5-301A common mistakes
F5-301A · Understand the traps and how to avoid them.
Installs the license and begins building virtual servers, pools and profiles in the GUI before provisioning Local Traffic Manager at the required level, then loses time to a re-provision and service restart because the Local Traffic menus or tmsh objects are missing.
Candidates treat resource provisioning as a licensing afterthought. On BIG-IP, menus, object types and some commands only appear at the provisioned level, and raising or lowering provisioning later forces a restart of affected services, which can interrupt a lab or exam scenario mid-build.
What to do instead
Provision LTM at Nominal first under System › Resource Provisioning, save, let services restart, then build the configuration. Only raise ASM, APM or Analytics levels after the LTM object set is validated, and re-check provisioning whenever a menu or command seems absent.
Assigns a self IP, then fails to ping or SSH to it and concludes the interface, VLAN or device is broken, even though the object is configured with the right address and mask.
Default port lockdown on a self IP permits only a limited protocol set, so ICMP, SSH or HTTPS to that address are silently dropped; candidates also mis-tag the VLAN or leave the self IP mask inconsistent with the directly connected subnet.
What to do instead
Open Network › Self IPs and review port lockdown, allowing only the specific protocol the test needs, and confirm the self IP mask matches the subnet. Verify the VLAN tag against the switch trunk and confirm traffic with a tcpdump capture on that VLAN interface.
Finds pool members in a remote subnet marked down or connections timing out, and starts rewriting monitor send strings and intervals instead of adding a gateway route, assuming the device already has a usable default gateway.
A BIG-IP has no default route out of the box; each VLAN needs its own gateway route, and health checks and client traffic leave from the self IP of the VLAN that reaches the member. Without a route, the probe never reaches the server and the member stays down.
What to do instead
Create a gateway route per VLAN, selecting the correct gateway address and VLAN, then confirm with tmsh show net route or netstat -rn. Capture with tcpdump on the egress VLAN to confirm the source self IP and that replies return before touching monitor settings.
Creates an HTTP monitor with a receive string but leaves the send string empty, or assigns a monitor whose port setting does not match the service being probed, and then marks healthy members down without testing the probe itself.
The built-in default send string is a bare GET / against the member port, so backends without a matching default page fail; transparent and alias port settings also change which port is probed, and candidates assume the monitor always follows the pool member port automatically.
What to do instead
Set explicit send and receive strings, deliberately choose the port or leave it at the wildcard, and confirm inheritance order (pool member, then pool, then node, then default). Reproduce the exact probe from the shell with curl or nc using the correct source self IP before changing timers.
Attaches an HTTP profile with header insertion, or an iRule using HTTP:: commands, to a Performance (Layer 4) virtual server, then spends time debugging the profile or rule when the feature simply never fires.
A Performance L4 virtual server bypasses the full-proxy and HTTP parsing path, so Layer 7 profiles and iRules have nothing to act on. Candidates pick the L4 type for speed without realising it changes the processing pipeline.
What to do instead
Rebuild the virtual server as Standard type with the appropriate protocol profile whenever Layer 7 processing is required, and reserve Performance L4 for pure TCP fast-path forwarding. Check the virtual server type before investigating profile or iRule behaviour.
Builds a catch-all virtual server on destination 0.0.0.0:443 or an address with port Any, bound to all VLANs, and then loses management GUI or SSH access or sees management traffic handled by the wrong virtual server.
A wildcard listener also matches traffic destined to the self IP used for management, and a virtual server bound to all VLANs competes with management access. Candidates add the wildcard to simplify matching without considering what else it captures.
What to do instead
Use specific destination addresses and ports, or restrict the virtual server to the relevant VLANs and adjust VLAN traffic settings. Keep management access on the management port or a dedicated VLAN that the wildcard virtual server does not cover.
Enables SNAT automap on a virtual server and expects servers to reply to the virtual server address, or builds a destination NAT for inbound traffic but never enables ARP, so the translated address is unreachable from clients.
Source translation rewrites the client source to a self IP on the egress VLAN, so replies come back to that address; destination NAT needs a virtual server matching the original destination plus ARP enabled for the translated address. Candidates conflate the two translation directions.
What to do instead
Confirm the SNAT address is routable from the servers and sits on the correct VLAN, and for NAT verify the matching virtual server and ARP setting. Confirm the translation pair with tmsh show sys connection and capture on both the client-side and server-side VLANs.
Uploads only the server (leaf) certificate, or loads a certificate and key without confirming they correspond, then attaches a Client SSL profile and blames the profile when clients report an untrusted or invalid certificate chain.
BIG-IP expects the certificate object to contain the leaf plus intermediate chain, and a key that does not match the certificate only surfaces when the profile is loaded or a connection is attempted. Candidates assume a browser-accepted certificate file is complete.
What to do instead
Install the leaf certificate together with its intermediate chain in the certificate object, verify the key matches, and attach the Client SSL profile to the virtual server. Test from a client with openssl s_client -showcerts to confirm the full chain presented, and check /var/log/ltm for profile load errors.
Configures two devices and floating self IPs but never creates a sync-failover device group with a traffic group, leaving both units active or the standby unit unable to answer for the floating address.
Floating self IPs only move when they belong to a traffic group inside a device group, and configuration synchronisation is a separate operation from failover. Candidates treat floating addresses alone as a complete HA configuration.
What to do instead
Create the trust domain, a sync-failover device group containing both units, and a traffic group holding the floating self IPs with the desired failover method. Then run config sync and confirm state with tmsh show cm sync-status and tmsh show cm failover-status.
Investigates a down pool member by reading only /var/log/ltm and re-editing monitor settings, without checking monitor-specific logs or capturing on the VLAN that actually carries the probe.
Monitor results are recorded separately from general LTM logging, and the probe can leave from a different VLAN and self IP than the one being inspected. Candidates assume a down status means the monitor parameters are wrong rather than the network path being blocked.
What to do instead
Check /var/log/monitors and tmsh show ltm pool members for monitor instance detail, then capture on the egress VLAN using the self IP as source. Confirm routing and any firewall in the path before changing intervals, timeouts or send strings.