A10 ACOS cheat sheet

ACOS is a 64-bit, Linux-based network operating system that runs on A10 Thunder hardware, vThunder virtual appliances, and cloud editions; the same CLI and configuration objects apply across platforms.

ACOS uses a multi-core, shared-memory architecture: control-plane processes such as CLI, GUI, health checks, and HA are separate from the data plane that forwards sessions, and forwarding scales across available CPU cores.

Flexible Traffic Acceleration (FTA) is the ACOS data-plane path that offloads flow setup and supports hardware or software acceleration; SSL, compression, and DDoS features can be offloaded depending on platform.

CLI access modes: User EXEC (>) changes to Privileged EXEC (#) with enable, then global configuration with configure terminal (config)#; end returns to Privileged EXEC.

Initial access paths are console serial, SSH to the management IP, and the HTTPS GUI; Telnet is disabled by default in current ACOS, and the default admin account password must be changed at first login.

Management access uses a dedicated management interface or VLAN; a management default gateway is configured separately from data-plane routes so GUI, SSH, NTP, syslog, and licensing traffic can use the management path.

write memory copies the running configuration to the startup configuration; show running-config and show startup-config compare active versus boot config, and reload reboots using the startup config.

Useful first-check commands include show version, show system, show interface brief, show ip route, show arp, show license, show log, and show tech-support, which collects diagnostics.

Licensing is per-platform and controls feature and throughput entitlements; show license displays installed licenses, and a license must be installed before licensed features such as SSL, GSLB, or aVCS are usable.

Object hierarchy: virtual server (VIP plus port and protocol) binds to service groups or direct members; a service group is the logical pool of server and port members.

Virtual server CLI: slb virtual-server , then port such as port 443 https; the VIP address and port form the client-facing tuple.

Service group CLI: slb service-group , then member ; all members in a group should use the same protocol and a compatible health monitor.

Load-balancing methods include round-robin, weighted-round-robin, least-connection, weighted-least-connection, service-least-connection, source-ip-hash, destination-ip-hash, source-port-hash, and fastest; the method is set on the service group or virtual server port.

Weighted methods use member weight (default 1); higher weight receives proportionally more new connections. Priority, where lower value means higher priority, creates active and standby members within a group.

Persistence uses a template such as source-IP, cookie, SSL session ID, or RDP cookie, bound to the virtual server port; persistence keeps a client's subsequent connections on the same member until timeout.

Source NAT can be automatic using the VIP or an interface address, or a configured NAT pool; without SNAT, backend servers must route return traffic to the ACOS VIP or interface.

conn-limit can cap concurrent connections at virtual-server, port, service-group, or member level; show slb virtual-server, show slb service-group, and show slb server display bindings and counters.

A virtual server port can be disabled and enabled independently; disable stops new sessions on that object while leaving other ports and services unaffected, which supports staged changes.

A health monitor is a named object with a method such as tcp, udp, icmp, http, https, dns, or radius, plus interval, timeout, retry, and up-retry; bind it to a service group or server port with health-check .

retry is the number of consecutive failed probes before a member is marked down; up-retry is the number of consecutive successful probes before it is marked up. Timeout should be less than or equal to interval for predictable probing.

HTTP and HTTPS monitors can send a request and expect a status code or content match; use a lightweight application endpoint that verifies dependencies rather than only a TCP handshake.

TCP monitor success only proves the port accepts a connection; it does not prove the application is healthy, while ICMP proves IP reachability only.

Maintenance workflow: disable the server port or service-group member to drain new sessions, verify with show slb server or show slb service-group, perform work, then enable and confirm health returns to Up.

Disabling health checking on a member stops probes but does not remove the member from load balancing; use disable to stop new traffic rather than health-check removal.

Monitor state and history: show health monitor, show slb server, and show slb service-group show Up, Down, and Disabled states; syslog and SNMP traps can alert on state transitions.

Health-check source and routing matter: probes originate from the ACOS data interface or a configured source, so return routing and ACLs on the server must permit them.

A monitor bound at service-group level applies to all members; a monitor bound to an individual server port can provide a more specific check for that member.

SSL offload uses a client-SSL template on the HTTPS virtual server port to terminate TLS at ACOS; a server-SSL template on the service group or server port re-encrypts traffic to backends when end-to-end encryption is required.

Certificate objects are separate from templates: import or reference the server certificate, private key, and intermediate chain, then bind them in the client-SSL template using cert, key, and chain-cert settings.

The server certificate must match the VIP hostname through CN or SAN; clients validate the chain, so intermediate certificates must be installed as a chain, since a missing intermediate causes trust errors even with a valid leaf.

Private keys must correspond to the certificate; ACOS cannot complete a handshake with a mismatched key and certificate pair. Key formats and passphrases must be supported by the ACOS version.

TLS protocol versions and cipher suites are controlled in the SSL template; disable SSLv3, TLS 1.0, and TLS 1.1 where policy allows, and select cipher sets compatible with required clients.

Client certificate authentication requires a CA certificate and client-certificate verification settings; without the CA certificate, ACOS cannot validate client certificates.

SSL session ID persistence can keep a client on the same backend when TLS session reuse matters; cookie or source-IP persistence is independent of TLS termination.

Certificate expiry is an operational risk: monitor certificate status with show slb ssl-certificate and the GUI, replace and rebind before expiration, then verify with show slb template client-ssl.

OCSP stapling, where licensed and supported, lets ACOS attach a revocation response to the handshake and reduces client-side OCSP lookups; otherwise clients may perform their own revocation checks.

VRRP-A is ACOS enhanced VRRP-based HA: peers exchange VRRP advertisements, one device owns the floating IP as active, and failover moves the floating IP and sessions to the standby.

VRRP-A common settings include device-id, which is unique per peer, and set-id, which must match on both peers; VRID settings include priority, preempt mode, and floating IP addresses.

Preempt mode determines whether a higher-priority peer takes over when it recovers; disabling preemption avoids unnecessary failback during maintenance.

Active-standby is the common HA design; active-active is possible with multiple VRIDs and service sets but requires careful traffic symmetry and persistence design.

Both peers must have synchronized configuration, including virtual servers, service groups, certificates, and health monitors, plus compatible software versions; unsynchronized configuration causes inconsistent failover behavior.

Run write memory on each peer after changes; verify HA state with show vrrp-a or show vrrp-a vrid and confirm the floating IP is owned by the expected device.

System administration: write memory saves config, reload reboots, show version and show system verify image and health, and show tech-support collects logs and configuration for support.

Management services include NTP for consistent timestamps, syslog hosts for event export, SNMP communities and traps for monitoring, and AAA through RADIUS or TACACS+ for centralized admin authentication.

Back up the configuration before upgrades or HA changes; keep copies of certificates and keys and the running config, and verify the startup config after reload.