Troubleshooting Radware Alteon HA pair split-brain scenarios
A Radware Alteon high-availability pair enters a split-brain condition when both appliances believe they are the active unit. Each device may continue forwarding traffic, advertising virtual services, or accepting configuration changes, while the peer appears unavailable. The result can be intermittent connections, asymmetric flows, duplicate ARP responses, and confusing health-check behaviour.
The fault is rarely caused by the HA state machine alone. A broken heartbeat VLAN, failed switch port, mismatched interface configuration, or an isolated management path can make a healthy peer look dead. This guide provides a practical troubleshooting method for production environments, including geographically separated Australian data centres where latency and carrier hand-offs can complicate diagnosis.
Recognise the symptoms
Users may report that a service works from Sydney but fails from Melbourne, or that connections alternate between success and timeout. Network teams may see MAC-address movement, duplicate gratuitous ARP messages, or the same virtual server address associated with different Alteon interfaces. These signs suggest competing ownership rather than an ordinary active-standby failover.
Start by recording the operational state on both appliances before rebooting either one. Capture the reported HA role, peer reachability, interface status, virtual server state, recent failover events, and system time. A pair that shows “active” on both units requires controlled action; repeatedly forcing failover can make the evidence harder to interpret.
Stabilise the environment first
Treat the incident as a possible duplicate-IP event. Identify which appliance is currently receiving legitimate client traffic and which one has the correct backend reachability. If necessary, isolate one unit at the switch or firewall layer, but preserve console or out-of-band access so it can be investigated safely. Avoid disconnecting the HA link blindly if doing so removes the only evidence of the original failure.
Coordinate with the network operations team before changing VLANs, shutting interfaces, or clearing ARP. In Australian enterprises, a change window may involve teams in Brisbane, Perth, and Melbourne across AEST and AWST, so write down the exact action, time, and operator. A short “arvo” maintenance task can become a major outage when two sites continue advertising the same service address.
Verify the HA heartbeat path
Check every component carrying HA communication: physical ports, LAG members, switch ports, trunk configuration, permitted VLANs, ACLs, and intermediate firewalls. The heartbeat path should be dedicated or tightly controlled, with identical speed, duplex, MTU, and tagging expectations on both appliances. A switch may show the port as up while filtering the specific control traffic needed by the pair.
Review switch counters for CRC errors, drops, port flaps, and MAC learning changes. Check whether spanning-tree convergence, storm control, or a recent trunk change interrupted the path. If the appliances are in separate facilities, confirm that the inter-site design actually supports the HA protocol and timing requirements; ordinary IP reachability does not guarantee reliable state synchronisation.
Compare configuration and identity
A split-brain event becomes more likely when the appliances have diverged configuration. Compare software release, licence state, HA settings, VLAN membership, interface roles, virtual server definitions, gateway settings, and health-check configuration. Confirm that each unit has a unique management identity and that the peer address points to the intended appliance.
The IT Diversified authors focus on operational configuration and troubleshooting, a useful perspective when reviewing changes made by several infrastructure teams. Keep a copy of both running configurations and event logs before synchronising anything. A configuration push from the wrong side can overwrite valid objects or turn a temporary network fault into a persistent outage.
Check network ownership and traffic flow
Use the upstream switch, router, firewall, and load-balancer evidence together. Inspect ARP and neighbour entries for the virtual IP, MAC-address tables for the relevant VLANs, and flow records showing which Alteon is handling connections. Packet captures can reveal whether both devices send gratuitous ARP or whether only one is actually forwarding client traffic.
Also test the backend path from each appliance. A unit may become active after losing peer communication even though its server VLAN or default gateway is unavailable. Review server health checks, persistence records, NAT behaviour, and return routing. In hybrid environments, an AWS transit path, an MPLS circuit, or a carrier Ethernet service can fail in only one direction, leaving management access available while production traffic is broken.
Recover the pair safely
Choose one appliance as the authoritative active unit using traffic evidence and the approved service state, not simply the role displayed on screen. Isolate the other appliance from client-facing VLANs if duplicate ownership is still possible. Once the network path is stable, place the secondary into a known standby state according to the Alteon release documentation, then restore peer communication and monitor state transitions.
Do not synchronise configurations until you have identified which copy is correct. Compare object changes, timestamps, certificates, health checks, and virtual server status. After rejoining the pair, test client access from multiple networks, confirm a controlled failover, and verify that ARP and MAC learning settle on the expected active unit. Record the final state and the trigger, such as a failed trunk, blocked heartbeat VLAN, or power event.
Build evidence for prevention
Enable suitable event logging and send HA, interface, and failover messages to a central syslog or monitoring platform. Alert on both peers reporting active, repeated role changes, heartbeat loss, configuration mismatch, and unexpected virtual IP movement. Keep packet captures and switch logs during an incident; they often distinguish a control-plane failure from a genuine appliance fault.
Document the physical and logical HA design, including cabling, switch ports, VLAN IDs, peer addresses, failover dependencies, and recovery ownership. Test the design during a controlled window rather than waiting for a live outage. The following matrix helps separate similar symptoms that require different actions.
| Observed condition | Likely cause | Evidence to collect | Safe first action |
|---|---|---|---|
| Both appliances report active | Heartbeat isolation or split control path | HA logs, peer reachability, switch counters | Isolate one client-facing unit while preserving console access |
| One unit active, clients intermittently fail | Duplicate ARP, MAC flapping, or asymmetric routing | ARP entries, MAC table, flow records | Confirm which unit owns and forwards the virtual IP |
| Peer is unreachable but traffic is stable | HA VLAN, ACL, or interface fault | Interface status, trunk and ACL configuration | Restore the heartbeat path without forcing repeated failovers |
| Failover occurs repeatedly | Unstable link, health check, or gateway | Event timestamps, link flaps, server checks | Correct the failing dependency before testing failover |
| Configuration differs between peers | Failed synchronisation or manual change | Running-config comparison and audit logs | Select the authoritative copy before synchronising |
| Both units forward traffic after recovery | Role state was restored without clearing duplicate ownership | Packet capture, ARP and MAC movement | Keep one unit isolated until state and network ownership converge |
A reliable recovery leaves one active owner, one verified standby, consistent configuration, and a monitored heartbeat path. That outcome is more important than simply making both status screens display a healthy message.