Deploying Radware AppDirector for link load balancing with failover

Used as an application delivery controller, Radware AppDirector provides link load balancing (LLB) across two internet or WAN paths, keeping applications reachable when the preferred carrier fails. This differs from server load balancing: AppDirector steers traffic between uplinks while maintaining the correct return path, giving hybrid workloads a more resilient edge.

The deployment below favours active/standby because it gives operators a clear primary path and deterministic backup. It covers health checks, route handling, failure tests and day-two operations. Field names vary between releases, so validate the syntax against your installed version.

Define the failover behaviour

Begin with traffic classes, not interface names. Decide which applications use the primary carrier, which may use either link, and which must never fall back to a metered connection. A staff portal should not share a backup path with production payments or Microsoft 365 traffic. Record those exclusions first.

Define failure precisely. A carrier may accept ICMP while DNS, TLS or upstream transit is impaired, so switching needs more than ping. Set probe intervals, failure and recovery thresholds, and a hold-down period. Include a dead-man timer or equivalent so an unreachable probe target cannot pin traffic to a failed link.

Prepare links and appliance resources

Give each WAN path its own interface, monitoring and route context. Where BGP is used, confirm prefixes, local preference, MED behaviour and a usable default route before configuring AppDirector. Static routing can suit a small branch, but it must not create a black hole when the primary transit session drops.

Size the appliance or virtual instance for TLS inspection, concurrent sessions, logging and failover overhead, not average bandwidth alone. Pin management to an out-of-band network or policed VPN, and back up the configuration and licence details. For an HA pair, verify synchronisation and peer-health behaviour.

Australian managed-service providers often combine enterprise Ethernet with a secondary carrier, while a Perth site can see higher latency and satellite fallback. Use an independently reachable backup rather than one that loops through the same exchange. This matters for AWS workloads in Sydney (ap-southeast-2) and Melbourne (ap-southeast-4), where traffic should remain close to users.

Design health checks and traffic policy

Create layered probes: carrier reachability, DNS resolution, TCP connectivity and a transaction exercising the real application path. Source probes locally where possible, because an Internet-dependent probe can fail for the wrong reason. Set thresholds to avoid flapping, and log state changes in Australian Eastern Standard or Summer Time as well as UTC.

Give the primary and secondary links explicit priorities, then decide whether backup traffic is reserved or allowed to share capacity. Active/standby is easier to audit; active/active can use both paths when transit permits. In Aussie parlance, the backup is the backup path, not an equal share by default.

Configure AppDirector and dependencies

Apply changes in stages: interfaces, monitoring objects, health checks, LLB policy, routing or NAT, then validation. Use meaningful names such as Sydney-Transit-A instead of eth0. Confirm source and return traffic use the selected egress; otherwise replies may leak through the wrong carrier.

Align the platform beneath AppDirector with its supported hypervisor, guest sizing and failover model. For virtual deployments, check operating-system support and integration services against the Microsoft platform guidance, and confirm the AppDirector licence before installation. If management, logging or DNS run on Windows, ensure their restarts cannot remove the recovery policy.

Test failure and recovery paths

Test from Australian vantage points on different carriers, including a home connection separate from the primary uplink. Record latency, DNS resolution, TLS setup and transaction time, then repeat during an impairment. A green ping is not successful failover if users receive a stale certificate, authentication error or captive-portal page.

Inject a realistic failure: disable the WAN interface, withdraw the carrier session or fail the health target under controlled conditions. Watch LLB state, route changes, NAT counters and application logs together. The SOFCASE home-lab notes can help rehearse the sequence without touching production, provided the lab uses independent carrier paths.

After restoration, confirm failback occurs only after the recovery threshold, with hold-down preventing oscillation. Keep the failed path disabled until route and DNS checks are clean. Repeat the test after firmware, policy and topology changes, because failover can regress when a dependency moves.

Day-two checks and fault signatures

Make AppDirector visible in the same operational views as the edge: link state, probe latency, failovers, policy changes and resource use. Alert the Australian operations team through its established channel, and retain carrier references in tickets. Trends reveal a link that is close to failing.

Routine operational checks

• Review probe history and failed transitions.
• Compare egress and return-path counters.
• Test an application transaction after each change.
• Confirm configuration and log backups.

Common fault signatures

• Interface up but probes fail: check upstream DNS and TLS.
• Traffic uses the wrong carrier: inspect policy and return routes.
• Rapid link oscillation: adjust thresholds and hold-down.
• Controller healthy but service fails: test NAT, certificates and backends.

Start fault isolation at the layer that changed. If the carrier event is confirmed, deal with it before altering AppDirector; if the probe target is broken, correct that first. Capture timestamps, interface counters and state transitions so the ISP and application team use the same evidence.

After each failover, record detection, traffic-switch and recovery times. Separate an expected route change from an application outage caused by sessions, DNS caches or authentication. Australian service managers often coordinate an application owner, network provider and internal operations team within one incident window.

Choose the deployment pattern

No single pattern suits every branch. Choose based on link quality, carrier diversity, state requirements and the cost of carrying production traffic over a fallback. Document the selected behaviour and rehearse it under realistic load.

Pattern	Best fit	Main benefit	Main caution
Active/standby	Branch offices and strict failover	Simple, predictable primary path	Backup capacity may be limited
Weighted active/active	Sites with two proven transit links	Uses spare capacity and shares load	Routing, NAT and health policy are more complex
DNS-assisted fallback	Low-risk services with multiple resolvers	Reduces controller dependency	Client caches can delay or bypass failover

For most Australian offices with one strong enterprise link and a genuine secondary carrier, active/standby with synthesised health checks is the dependable baseline. Use active/active only when both paths have independent transit, stable routes and peak-load capacity. DNS steering can complement the design, but it should not replace controller-led LLB where immediate switching matters.