SonicOS 7.1 High Availability Administration Guide
- SonicOS 7.1
- About SonicOS
- High Availability
- Replacing an HA Primary Unit
- High Availability Config
- Configuration of HA Active/Standby
- Configuring Active/Standby High Availability Settings
- Configuring HA with Dynamic WAN Interfaces
- Configuring Network DHCP and Interface Settings
- Disabling the SonicOS DHCP Server
- Configuring Virtual IP Addresses
- Configuring Redundant Ports
- Fine Tuning High Availability
- Advanced Settings
- Configuring Advanced High Availability Settings
- Monitoring High Availability
- Configuring Active/Standby High Availability Monitoring
- Configuring Active/Standby High Availability Settings
- IPv6 High Availability Monitoring
- About This Document
- Azure Use Cases
- SonicWall Support
Understanding SonicWall High Availability Operation Modes
High Availability has several operation modes, which can be selected on
MANAGE | System Setup > High Availability > Base Setup
Choosing the right High Availability Operation mode depends on understanding the network in question, it’s purpose and operational needs. In planning, the administrator should understand:
- the operational requirements for uptime,
- the repercussions of failure, and
- the calculated risk to operations
Each operation mode satisfies a different scenario and without knowing the goals of High Availability, administrators risk building an unsatisfactory solution. Understanding the operational mode and how they map to requirements is fundamental. This Active/Standby mode may be further defined as to whether they are stateless, stateful, or offload Deep Packet Inspection to a secondary device.
Active/Standby SonicWall Operational modes are:
None
Selecting None activates a standard high availability configuration and hardware failover functionality, with the option of enabling Stateful HA.
Active/Standby
Is either stateless or stateful.
Active/Standby Stateless
Active/Standby mode provides basic high availability with the configuration of two identical Security Appliances as a High Availability Pair. The Active unit handles all traffic, while the Standby unit shares its configuration settings and can take over at any time to provide continuous network connectivity if the Active unit stops working. By default, Active/Standby mode is stateless, meaning that network connections and VPN tunnels must be re-established after a failover.
Active/Standby Stateful
Stateful Synchronization can be licensed and enabled with Active/Standby mode. In this Stateful HA mode, the dynamic state is continuously synchronized between the Active and Standby units.
Network connections and VPN tunnel information are continuously synchronized between the two units so that the Secondary can seamlessly assume all network responsibilities if the Primary firewall fails.
When the Active unit encounters a fault condition, stateful failover occurs as the Standby Security Appliance takes over the Active role with no interruptions to the existing network connections.
Not all information is synchronized in a stateful configuration.
Information that is Synchronized | Information that is not Synchronized |
VPN information | Dynamic WAN clients (L2TP, PPPoE, and PPTP) |
Basic connection cache | Deep Packet Inspection (GAV, IPS, and Anti Spyware) |
FTP | IPHelper bindings (Such as NetBIOS and DHCP) |
Oracle SQL*NET | SYNFlood protection and information |
Real Audio | Content Filtering Service information |
RTSP | VoIP protocols |
GVC infromation | Dynamic ARP entries and ARP cache time outs |
Dynamic Address Objects | Active wireless client iformation |
DHCP server information | Wireless client packet statistics |
Multicast and IGMP | Rogue AP list |
Active users | |
ARP | |
SonicPoint status | |
Wireless guest status | |
License information | |
Weighted Load Balancing information | |
RIP and OSPF information |
Platform | Active/Standby HA1 | Stateful HA |
TZ270/TZ270 W | Included | Included |
TZ370/TZ370 W | Included | Included |
TZ470/TZ470 W | Included |
Included |
TZ570/TZ570 W/TZ570 P | Included |
Included |
TZ670 | Included |
Included |
TZ740 WLTE | Included | Included |
NSA 2700 | Included |
Included |
NSA 3700 | Included |
Included |
NSA 4700 | Included | Included |
NSA 6700 | Included | Included |
NSSP 13700 | Included | Included |
NSSP 15700 | Included | Included |
NSv 270 | Included | Included |
NSv 470 | Included | Included |
NSv 870 | Included | Included |
|
Licensing is not standard across all models. Enterprise class models often include HA licensing.
Multiple Gateways
In an Enterprise environment, or other large environment with several networks and several gateways, cluster nodes may share the workload by terminating the gateways on separate cluster nodes (see diagram below). For example, the gateway for networks 1-10 are terminated on Cluster A, while networks 11-20 are terminated on Cluster B. Typically this is handled by another device downstream (closer to the LAN devices) from the Cluster, such as a DHCP server or a router.
It is up to the network administrator to determine how the traffic is allocated to each gateway. For example, you could use a smart DHCP server which distributes the gateway allocation to the PCs on the directly connected client network, or you could use policy based routes on a downstream router.
Naturally, some thought should go into the division as the desire is not to have all the heavy workloads on a single cluster node while the second sits mostly idle.
Was This Article Helpful?
Help us to improve our support portal