Deploying Radware Alteon for link load balancing with BGP advertisements
Using multiple internet providers can improve availability, capacity, and maintenance flexibility, but outbound and inbound traffic must be controlled deliberately. Radware Alteon can act as the decision point for link load balancing, selecting an ISP path according to health, policy, utilization, or application requirements.
BGP advertisements add an important inbound-routing capability. Instead of relying only on DNS changes or static routes, an Alteon deployment can advertise public address space through available providers and withdraw or reduce advertisements when a path fails. The result is faster convergence and more predictable traffic engineering.
The design still depends on clean IP addressing, correct route policy, reliable health checks, and symmetric return traffic. BGP does not replace application monitoring, and a session that reaches an ISP gateway does not prove that the application is reachable.
Define the traffic and addressing model
Start by documenting which services require inbound access and which users or systems generate outbound traffic. Public web applications, VPN portals, mail services, and APIs may need inbound path selection, while enterprise browsing, SaaS access, and software updates usually need resilient outbound NAT and policy routing.
A common design uses a public prefix owned by the organization and advertises that prefix through two or more upstream providers. If provider-assigned address space is used, each ISP may expect its own prefix to be advertised only through its connection. Provider-independent space offers greater control, but it can require regional registration, filtering coordination, and minimum-prefix-length planning.
Alteon interfaces should be separated by function where possible: management, internal server or LAN connectivity, and external ISP-facing networks. Establish a clear default-gateway strategy before enabling BGP. Routing changes are easier to troubleshoot when management access does not depend on the same internet path being tested.
Prepare the BGP peering design
Collect the local autonomous system number, provider ASNs, neighbor addresses, advertised prefixes, authentication requirements, and inbound or outbound routing policies. Confirm whether each carrier expects eBGP multihop, a directly connected peer, BGP MD5 authentication, or a specific TTL setting.
Route filtering is essential. Outbound policy should permit only the prefixes that Alteon is authorized to advertise. Inbound policy should accept a controlled set of default routes or selected internet routes, depending on the appliance’s memory, license, and operational requirements. Accepting a full routing table without validating platform capacity can create unnecessary risk.
Use BGP attributes to influence path selection rather than assuming that equal advertisements produce equal traffic. Local preference, MED, AS-path prepending, and provider communities can make one carrier primary while preserving the other as an active standby. The preferred behavior should be written down for normal operation, degraded service, and full ISP failure.
Configure link health and traffic steering
BGP neighbor state alone is not a sufficient health signal. A session can remain established while the provider has lost upstream reachability or while a remote application is unavailable. Combine BGP with Alteon link probes, gateway monitoring, DNS or HTTP checks, and service-level tests that traverse the actual path.
A useful monitoring target should be beyond the immediate ISP router. Testing only the next hop verifies local adjacency, not internet usability. Where supported, configure multiple probe destinations and bind failure actions to route withdrawal, path de-preference, or traffic-policy changes. Avoid overly aggressive timers that cause route flapping during brief packet loss.
For outbound traffic, define how Alteon selects a link based on source, destination, application, connection count, bandwidth, or link cost. For inbound traffic, the practical control is usually which public prefix is advertised and how strongly each path is preferred. Remember that existing TCP sessions may not move cleanly when a route changes; graceful application behavior and suitable connection timeout settings remain important.
Build the deployment in stages
Before production, create the VLANs, interface addresses, static routes, and security rules required for each external circuit. Permit BGP TCP port 179 only between intended peers, and restrict management access to trusted administration networks. Confirm that upstream providers have installed the correct customer routes before moving application traffic.
Bring up one BGP peer at a time and verify the received and advertised prefix counts. Check that the local ASN and next-hop behavior match the carrier’s requirements. Then test policy changes by adjusting preference or temporarily shutting down a link rather than relying only on a provider’s statement that failover is complete.
NAT deserves special attention. If Alteon translates outbound connections, record which public address pool is used on each ISP path and ensure return traffic follows the same stateful device. Inbound services may require static mappings, virtual server definitions, persistence, and firewall rules that remain valid regardless of the selected carrier.
| Design area | Primary decision | Validation method |
|---|---|---|
| Public addressing | Provider-independent or provider-assigned prefixes | Confirm registry, carrier, and filter compatibility |
| BGP sessions | ASN, neighbor IP, authentication, timers | Check established state and negotiated parameters |
| Route policy | Primary, backup, or active-active behavior | Review advertised and received routes |
| Link health | Gateway, internet, and application probes | Disconnect or degrade a circuit during testing |
| Outbound traffic | NAT pools and path-selection rules | Trace public source address and return path |
| Inbound traffic | Prefix advertisement and service mapping | Test from multiple external networks |
| Operations | Logs, alerts, and rollback process | Execute a documented failure drill |
Validate convergence and asymmetric routing
A successful failover test should cover more than ping. Establish new HTTPS, DNS, VPN, and API sessions through each carrier, then disable the preferred path and measure route withdrawal, connection establishment, and application recovery. Capture BGP logs and packet traces so the team can distinguish routing convergence from firewall or NAT behavior.
Asymmetric routing is a frequent cause of confusing failures. A connection may enter through one ISP and return through another, causing a stateful firewall, Alteon persistence method, or upstream anti-spoofing filter to discard packets. Review forward and reverse paths with traceroute, flow records, interface counters, and firewall session tables.
Also test partial failures. Leave the BGP session established while blocking probe destinations, advertise the route while disabling a virtual service, and simulate packet loss or high latency. These cases determine whether the health model detects an outage that protocol state alone would miss.
Operate the environment safely
Document the intended route policy, provider contacts, public prefixes, BGP credentials, maintenance sequence, and emergency rollback commands. Store configuration backups securely and test that they can be restored to the same software release or an approved replacement. Operational discipline matters as much as the initial routing design; a saved configuration is useful only when its dependencies are understood.
Monitoring should alert on neighbor state, advertised-prefix changes, unexpected route counts, probe failures, interface errors, link utilization, and NAT exhaustion. Keep an audit trail for policy changes and correlate Alteon events with provider notifications. For broader infrastructure resilience, the same runbook should reference backup integration steps when protecting related systems and configuration data.
Operational safeguards to apply
- Filter every advertised prefix and reject unauthorized route announcements.
- Use application-aware probes in addition to BGP neighbor monitoring.
- Keep one tested rollback procedure for route policy, NAT, and virtual service changes.
- Record baseline convergence times and compare them after software or carrier changes.
- Review asymmetric paths and session persistence during every failover exercise.
A well-designed Alteon link load-balancing deployment treats BGP as one part of a larger control system. Addressing, route policy, probes, NAT, application health, and operational monitoring must agree on what “available” means. Build the configuration in a lab or maintenance window, validate each failure mode, and promote the documented design only after real traffic follows the intended paths.