Building a resilient Radware ADC farm with dual-ISP failover
A resilient application delivery platform needs to solve two separate problems: distributing client traffic across application servers and keeping services reachable when an internet provider fails. A Radware design can combine Alteon application delivery controllers with LinkProof link load balancing to provide local server redundancy, multi-WAN resilience, health-based routing and a consistent public entry point.
The most reliable deployments treat the ADC farm and the WAN edge as one operational system. Server pools, NAT rules, route monitoring, asymmetric traffic paths and TLS handling must be designed together. This is especially relevant for Australian organisations operating across Sydney, Melbourne, Brisbane or regional sites where carrier diversity can be limited and outages may affect a whole suburb or exchange.
| Design area | Preferred approach | Main operational benefit |
|---|---|---|
| Application delivery | Two Alteon appliances or virtual ADCs | Redundant load balancing and SSL offload |
| Internet edge | Two diverse ISP circuits through LinkProof | Automatic provider failover |
| Server access | Health-checked pools with persistence where required | Traffic avoids failed or unhealthy nodes |
| Public addressing | Provider-independent space or managed DNS strategy | Better continuity during circuit changes |
| Monitoring | Synthetic tests, interface checks and application probes | Failures are detected at the service layer |
| Administration | Separate management interfaces and restricted access | Safer troubleshooting and change control |
Define the traffic and failure model
Start by documenting every traffic flow: internet clients to public virtual servers, ADCs to application nodes, administrative access, monitoring, backups and outbound connections from the workloads. Identify whether applications require source-IP persistence, WebSocket support, long-lived sessions or client certificate authentication. These requirements affect the virtual service configuration and the choice of persistence method.
A simple design usually places LinkProof at the internet-facing edge, with two ADCs behind it or with LinkProof services integrated into the chosen Radware architecture. Each Alteon presents virtual IP addresses for HTTP, HTTPS or other application protocols, while real servers remain on private VLANs. Default gateways and return routes must be planned so responses leave through the correct device and do not bypass the load balancer.
Failure testing should include a dead server, a failed ADC interface, a disconnected ISP circuit, a failed upstream gateway and an application that returns errors while its TCP port remains open. A route that is technically available but leads to a broken authentication service should be treated as a service failure, not a healthy path.
Build the ADC farm for predictable behaviour
Deploy the ADC pair with synchronised configuration, dedicated management access and redundant data paths. Use separate VLANs or interfaces for client-side traffic, server-side traffic, synchronisation and management where the platform and topology support it. Keep management addresses out of public NAT policies, and restrict administration to approved jump hosts or a management network.
Create server groups based on application function rather than simply placing every node in one pool. Health checks should validate the right layer: a TCP probe may be enough for a basic service, while an HTTPS request to a known endpoint is more useful for a web application. Configure realistic intervals, timeout values and failure thresholds so a short application restart does not cause unnecessary pool flapping.
TLS certificates, cipher policy, HTTP header handling and logging should be standardised across both ADCs. If TLS is terminated at the ADC, preserve the original client address with the platform’s supported headers and ensure backend applications trust those headers only from the ADC subnet. Certificate renewal should be automated or documented as a controlled procedure rather than left to an expiring calendar reminder.
Configure link load balancing across providers
LinkProof should monitor each ISP using more than a single interface state. A carrier Ethernet handoff can remain electrically up while the provider has lost upstream reachability, so use gateway checks and remote probes where available. Probe destinations should be stable and geographically sensible, with at least one test that reflects the organisation’s actual application path.
Traffic policies can distribute outbound sessions by weighted ratio, response time, source network or application category. For example, business-critical SaaS traffic might prefer the lower-latency provider, while bulk updates use the cheaper circuit. Avoid changing the preferred path too aggressively; hysteresis and hold-down timers prevent repeated switching during an unstable carrier event.
Inbound traffic is more complicated because public IP ownership determines where clients connect. Provider-assigned addresses may require DNS changes, route advertisements or a managed failover service. DNS failover has caching delays, while BGP-based designs require suitable address space, carrier support and operational expertise. The selected method should match the organisation’s size, routing capability and recovery objective.
Keep return paths and state consistent
Asymmetric routing is a common cause of intermittent failures in dual-ISP environments. A client request may arrive through one provider while the response leaves through another, causing stateful devices or remote networks to discard the session. LinkProof policies, ADC gateways, NAT behaviour and upstream route advertisements must all support the intended symmetry.
Source NAT is often useful for outbound connections because it makes the selected egress path explicit. For inbound services, preserve the public destination mapping and ensure return traffic follows the same logical path. Session persistence should be configured only where the application needs it; excessive persistence can concentrate users on one node and undermine the farm’s capacity.
When applications depend on external APIs, payment gateways or allow-listed addresses, document the public source addresses used by each ISP. Australian banks, government services and partner platforms may apply strict allow-listing, and an ISP failover can expose a different source address. Change records should include these dependencies before production cutover.
Add security and Australian operational controls
Place firewalls and security inspection in a deliberate position relative to LinkProof and the ADCs. Avoid creating multiple unexamined NAT layers, and ensure logs retain client address, translated address, virtual service and selected backend details. For internet-facing workloads, Radware’s DefensePro DDoS guidance provides useful context for combining application delivery with denial-of-service protection.
Australian organisations should account for the Privacy Act and the Australian Privacy Principles when retaining client addresses, authentication data and diagnostic logs. Log storage location, access permissions and retention periods should be documented, especially when telemetry is sent to an overseas SaaS platform. Financial and healthcare environments may also have contractual or sector-specific requirements that influence where traffic metadata is stored.
The design should reflect local connectivity realities. NBN business services may use different handoff and service-level arrangements from fibre Ethernet, while Telstra, Optus and other carriers can provide genuinely diverse paths only when the last-mile route is verified. A Melbourne office with two circuits entering the same building riser does not have meaningful physical diversity simply because the providers use different brands.
Test failover and operate the platform
Before production use, record baseline latency, throughput, connection counts, pool response times and normal route preference. Then test one event at a time: disable an application node, stop an ADC service, withdraw an ISP route and restore each component. Measure detection time, connection impact, DNS behaviour and the time required for traffic to settle on the preferred path.
Monitoring should alert on application health, not just appliance availability. Track virtual service state, real-server utilisation, link quality, NAT table pressure, certificate expiry, synchronisation status and configuration changes. Synthetic checks from locations such as Sydney and Perth can reveal regional reachability problems that an internal probe misses.
Document recovery procedures for the network team and service desk, including how to identify the active path, verify DNS or route state, and safely return traffic after an outage. Schedule reviews after carrier changes, office relocations and major application releases. With consistent health checks, controlled routing and tested recovery, the Radware ADC farm can maintain service through both server faults and ISP disruption.