OpenSECURE — Security + Automation
Blog
All articles

A10

A10 load balancer configuration: virtual servers, service-groups and source NAT

Written by OpenSECURE4 min read

An A10 load-balancer configuration consists of several objects that work together to process traffic. The VIP is the visible entry point, but backend definitions, service ports, service-groups, health checks and network routes determine whether the application is actually usable.

A useful baseline design makes those relationships explicit. That also makes later troubleshooting more precise: an unreachable VIP and an unusable backend are different problems.

Understand the object chain

A simple web service can be described using the following objects:

ObjectExamplePurpose
ServerWEB01Backend with an address
Server port8080/tcpService on the backend
Service-groupSG_PORTAL_8080Distribution across backend services
Health monitorHM_PORTAL_HTTPAvailability check
Virtual serverVIP_PORTALClient entry point
Virtual port80/httpTraffic processing on the VIP

A10 documents service-groups and virtual ports separately. The virtual port references the service-group that should process its traffic. See the service-group and virtual-port references for ACOS 6.0.8.

Define the backend distribution

The following aXAPI payload illustrates a service-group referring to two existing server objects. Their service ports and the referenced monitor must already exist.

{
  "service-group": {
    "name": "SG_PORTAL_8080",
    "protocol": "tcp",
    "lb-method": "round-robin",
    "health-check": "HM_PORTAL_HTTP",
    "member-list": [
      {
        "name": "WEB01",
        "port": 8080
      },
      {
        "name": "WEB02",
        "port": 8080
      }
    ]
  }
}

Member references consist of a server name and port. A health monitor can be associated with the service-group. The member reference describes the relevant object structure.

Round-robin is a straightforward example, not a universal recommendation. Choose the method according to backend capacity, request characteristics and any persistence requirement.

Bind the virtual port

For an existing VIP_PORTAL parent, the following payload describes a POST to /axapi/v3/slb/virtual-server/VIP_PORTAL/port:

{
  "port": {
    "port-number": 80,
    "protocol": "http",
    "service-group": "SG_PORTAL_8080",
    "auto": 1
  }
}

In this API version, auto configures auto NAT for the virtual port. It is a networking choice rather than a mandatory setting for every application. Check the virtual-port schema for the exact release being used.

These fragments are not a complete deployment. The parent virtual server, interfaces, routes and any additional templates remain part of the surrounding design.

Match source NAT to the return path

Source NAT changes the source address received by the backend. The key design question is how the backend's response returns through the expected traffic path.

When retaining the client address, the return route must support that design. A response bypassing the expected load-balancing path can cause failures. With source NAT, backend traffic is presented using a translated source address instead.

This affects logging and access controls. An application relying only on the network source address may no longer recognise the original client after translation. HTTP forwarding information can help, but only when the application trusts the correct proxies and does not accept arbitrary client-supplied values as authoritative.

Document the expected source address at each stage. That makes captures and backend logs substantially easier to interpret.

Persistence can obscure the distribution

A test browser does not necessarily reach a different backend on every request. Existing connections and persistence may influence the result.

Compare the configuration with connection data, counters and backend logging. Establish why persistence is required: local session state, a particular application function or simply a historical configuration choice.

Test the complete traffic path

Acceptance testing should cover backend availability, access through the VIP, controlled loss of one backend and its recovery. Include the expected source addresses and the health condition that allows each instance to receive traffic.

The deployment is complete when object configuration and network design jointly produce the required behaviour. That provides a better foundation for troubleshooting and handover than a collection of individually correct-looking settings.