A10 ACOS study materials
A10 ACOS study resources

A10 ACOS common mistakes

A10 ACOS · Understand the traps and how to avoid them.

Mistake 1

Completes the configuration task in configure terminal, then reboots or triggers a failover without ever running write memory, and the change is gone afterwards.

Candidates carry over habits from appliances that auto-commit changes; in ACOS the edits live in the running-config and are only pushed to startup-config on an explicit save, so a lab that ends with reload exposes the gap.

What to do instead

After each task, run write memory, then confirm with show running-config that the object (VIP, service group, monitor, template) appears, and re-check after any reload or failover in the scenario.

Mistake 2

Assigns the management address inside the data VLAN subnet, or sets the management IP without a default gateway, then cannot reach remote AAA, NTP, syslog, or licensing servers, and tries to SSH to a VIP address instead of the management interface.

ACOS keeps the management interface in its own context, separate from data-plane interfaces, so a data-plane default route does not help management traffic; candidates treat all interfaces as one routing table.

What to do instead

Configure interface management with its own address and ip default-gateway, verify reachability with a ping sourced from the management context, and always use the management address for administrative access.

Mistake 3

Adds service-group members as bare IP addresses (for example member 192.0.2.10:80) instead of referencing a named slb server object, so the configuration is rejected or the member never comes up.

On many load balancers a pool member is just an IP:port, so candidates skip the intermediate server object that ACOS requires and reuse the syntax from other platforms.

What to do instead

Create the real server first with slb server , add its port, then attach it to the group as member :, and verify with show slb service-group that the member shows an operationally up state.

Mistake 4

Assumes the virtual server distributes traffic round-robin and never verifies or sets lb-method, then misreads distribution results during a weighted or persistence test.

Round-robin is the default on many competing products, but ACOS defaults the VIP port to least-connection, so an uneven-looking distribution is actually correct behaviour, and lb-method is set on the virtual-server port, not on the service group.

What to do instead

Read the effective method on the virtual-server port with show slb virtual-server, set lb-method explicitly to the method the requirement names, and re-test with several clients when persistence or weights are involved.

Mistake 5

Creates a health monitor, attaches it at the virtual-server level or forgets to attach it at all, then cannot explain why a dead member stays up or why a monitor object is listed but unused.

Monitor binding in ACOS happens on the service group or on the server port, not on the VIP, so a monitor that exists but is unattached has no effect on member state.

What to do instead

Bind the monitor with health-check under the service group (or the specific server port), confirm the binding in show slb service-group and show health monitor, and test by stopping the backend and watching the member transition down.

Mistake 6

During maintenance, disables a server or member and immediately reports the traffic as drained, or instead removes it outright and drops live sessions that should have been preserved.

Disable stops new connections from being assigned but existing sessions keep running until they finish or time out, while removal or a hard shutdown is immediate; candidates assume disable is instantaneous and skip checking the session table.

What to do instead

Use the graceful disable path, then watch remaining sessions with the session show commands until they clear, and only then remove the object; verify the rest of the group still carries the load.

Mistake 7

Imports a server certificate without the intermediate CA chain, or pairs a certificate object with a key that does not match, and the VIP silently fails TLS handshakes or the client sees an untrusted-chain warning.

The import step accepts files without validating the full chain or the key pairing, and candidates assume the file that worked in a browser bundle is complete, so the missing intermediate only surfaces at handshake time.

What to do instead

Import the full chain, confirm the certificate and key moduli match before binding, and validate end-to-end with an openssl s_client connection to the VIP that shows verify return code 0.

Mistake 8

Creates the client-ssl template with the certificate and key, but never binds that template to the virtual-server port, or binds it and leaves weak default SSL versions and ciphers in place.

In ACOS the VIP port references a template; the template itself does no work until it is attached, so candidates stop after the template is built and see plaintext or default behaviour, or forget that the cipher and version settings live in the same template.

What to do instead

Under the VIP port, bind template client-ssl , then re-check the port configuration, restrict ssl-version and the cipher list to the required policy, and re-test the handshake against the VIP.

Mistake 9

Builds VRRP-A on one node only, or configures mismatched vrid, device-id, or priority across peers, and then expects a floating address or a clean failover.

VRRP-A requires consistent fabric-level parameters on both peers and an explicit enable on the participating interfaces, so a partially configured peer looks alive but never joins the virtual router.

What to do instead

Mirror vrid, device-id, set-id, and priority on both nodes, enable VRRP-A on the same interfaces, and confirm the peer relationship and the active/standby roles with the VRRP-A show commands before testing failover.

Mistake 10

Assumes the standby automatically receives the configuration, or copies only a subset of objects, then fails over and finds missing service groups, certificates, or monitors on the peer.

ACOS HA keeps data-plane state and configuration sync as separate concerns; a peer can be operationally healthy and still hold stale configuration if no sync has been run or if the object type is not carried across.

What to do instead

Run the configuration sync between peers, then diff the key objects (VIPs, service groups, monitors, client-ssl templates, certificates and keys) on both nodes before declaring the pair ready, and re-sync after any change.