Deploying Radware Alteon With BGP Peering For Dynamic Routing
Radware Alteon can use Border Gateway Protocol (BGP) to advertise virtual service addresses and withdraw them when an application delivery path becomes unavailable. This creates a dynamic routing integration between the load balancer, campus or data-centre routers, cloud networks, and upstream providers. Traffic can follow the active service location without relying on static routes that require manual changes during an outage.
The design is particularly useful for Australian organisations operating across Sydney, Melbourne, Brisbane, or Perth facilities, where WAN latency, carrier diversity, and planned maintenance can affect traffic flows. A carefully controlled Alteon BGP deployment improves failover while keeping route advertisements predictable, auditable, and aligned with security and compliance requirements.
Why Use BGP With Alteon
A static route can direct traffic towards an Alteon virtual IP address, but it cannot independently determine whether the associated application is healthy. BGP allows the appliance to advertise a service prefix only while the relevant virtual server, real server group, or site is available. When health checks fail, the route can be withdrawn or given a less-preferred path.
This is valuable for active-active and active-standby designs. Two Alteon devices or clusters can advertise the same service prefix from separate locations, with local preference, AS path length, MED, or route policy determining the preferred entry point. The same model can support hybrid environments where an on-premises application is extended into AWS or another cloud platform.
Plan The Routing Architecture
Start by defining the autonomous system numbers, peering addresses, advertised prefixes, and expected traffic direction. External BGP is generally used between Alteon and a router in a different autonomous system, while internal BGP may be appropriate when the appliance participates directly in the organisation’s routing domain. Use private ASNs where the design remains inside the enterprise.
Advertise only the virtual IP prefixes required for client access. Avoid sending a broad subnet when a specific service prefix is sufficient. Confirm whether the upstream router expects the Alteon address as the BGP next hop or whether it will rewrite the next hop before forwarding traffic. Return traffic must also have a valid path, especially when source NAT is disabled and the application servers retain the original client address.
Prepare Alteon And Network Devices
Create a short implementation record containing the Alteon management and data-plane addresses, neighbour IPs, local and remote ASNs, authentication settings, timers, and route filters. Check the Alteon software release and licensing because BGP capabilities, health-based route control, and command syntax can vary between versions and deployment modes.
On the adjacent router, configure the BGP neighbour with inbound and outbound prefix filters, maximum-prefix protection, and a route policy. Permit only the expected service networks. Where supported and appropriate, enable BFD for faster failure detection, but do not use aggressive timers without checking carrier and router behaviour. In Australian branch networks, an NBN business connection may have different stability and hand-off characteristics from a private Ethernet or dark-fibre service, so test timers against the actual circuit.
Configure The BGP Peer
In Alteon, create the BGP routing instance or enable BGP within the relevant routing context. Define the local ASN, router ID, neighbour address, remote ASN, and optional MD5 authentication. The router ID should be stable and unique, usually based on a loopback or management address rather than an interface that may move during high availability failover.
Associate the service prefixes with BGP advertisement rules. Depending on the Alteon release and design, this may involve redistributing a virtual server route, using a network statement, or applying a route map tied to application health. The important control is that a prefix is advertised only when the intended service is eligible to receive traffic. Do not advertise a VIP merely because the appliance interface is operational.
Control Path Selection And Failover
Route policy determines which Alteon site receives new connections. Local preference is normally used inside an organisation to select the preferred exit or service location. AS path prepending can make a backup site less attractive to external peers, while MED may influence selection between links under the control of the same neighbouring organisation. These attributes should be documented because their effect depends on the receiving router’s policy.
For an HA pair, decide whether both appliances establish BGP sessions or whether only the active unit advertises the service. A floating peering address can simplify failover, but it must be supported by the platform and surrounding network. If both units advertise simultaneously, verify that this is intentional and that asymmetric paths will not break persistence, SSL offload, or stateful firewall inspection.
Verify Advertisements And Forwarding
Validate the session from both sides. Check that the neighbour reaches the Established state, that the negotiated ASN and timers are correct, and that authentication failures are absent. Review received and advertised prefixes rather than relying only on a general BGP summary. The expected VIP route should appear with the correct next hop and attributes.
Test the complete path using DNS resolution, TCP connection tests, application transactions, and packet captures where necessary. Shut down a monitored real server group or simulate an Alteon service failure, then confirm that the route is withdrawn or that the backup route becomes preferred. Restore service and check that advertisements return without creating duplicate or stale paths.
Operate The Design Safely
Monitoring should cover BGP session state, route count, VIP advertisement status, health-check results, and traffic volume. Alert on an unexpected prefix, a sudden route withdrawal, repeated session resets, or a neighbour approaching its maximum-prefix limit. Export Alteon and router logs to the central monitoring platform so an application outage can be correlated with routing changes.
Security controls matter because a routing error can expose internal services or redirect production traffic. Use prefix lists, route maps, TTL or peer-source validation where available, and management-plane access restrictions. For organisations subject to the Australian Privacy Act or regulated environments such as APRA-supervised financial services, retain change records and routing logs in line with internal governance and data-handling policies.
Account For Australian Operations
A service hosted in Sydney may be preferred for users in New South Wales, while Melbourne or Perth may provide resilience for separate workloads and time zones. Avoid assuming that geographic proximity always produces the best path: carrier routing, cloud interconnects, and international backhaul can make a measured policy more reliable than a location-based assumption.
Plan maintenance around local business patterns, including Australian Eastern and Western time zones, public holidays, and overnight change windows. If a Brisbane site, a Melbourne data centre, and an AWS region are involved, document which BGP attributes should win during each failure scenario. This gives operations teams a predictable response when a carrier circuit, application pool, or entire facility becomes unavailable.