en-US
search-icon

SonicOS 6.2 Admin Guide

High Availability

About High Availability and Active/Active Clustering

* 
NOTE: High Availability (HA) is supported on TZ series and above firewalls. Stateful HA and Active/Active DPI are supported on TZ500 Series and above firewalls. See Active/Standby and Active/Active DPI Prerequisites. Active/Active Clustering is supported on NSA 3600 and above firewalls. See Licensing Requirements for Active/Active Clustering.

NAT64 does not support High Availability.

High Availability

This section provides conceptual information about High Availability (HA) in SonicOS and describes how to connect the firewalls for HA.

Topics:  

About High Availability

Topics:  

What Is High Availability?

High Availability (HA) is a redundancy design that allows two identical SonicWall firewalls running SonicOS to be configured to provide a reliable, continuous connection to the public Internet. One SonicWall firewall is configured as the Primary unit, and an identical SonicWall firewall is configured as the Secondary unit. If the Primary firewall fails, the Secondary firewall takes over to secure a reliable connection between the protected network and the Internet. Two firewalls configured in this way are also known as a High Availability Pair (HA Pair).

High Availability provides a way to share SonicWall licenses between two SonicWall firewalls when one is acting as a high-availability system for the other. Both firewalls must be the same SonicWall model.

To use this feature, you must register the SonicWall firewalls on MySonicWall as Associated Products. For further information, see Registering and Associating Firewalls on MySonicWall.

High Availability Terminology
 

Active

The operative condition of a hardware unit. The Active identifier is a logical role that can be assumed by either a Primary or Secondary hardware unit.

Failover

The actual process in which the Standby unit assumes the Active role following a qualified failure of the Active unit. Qualification of failure is achieved by various configurable physical and logical monitoring facilities described in Configuring High Availability.

HA

High Availability: non-state, hardware failover capability.

IDV

Interface Disambiguation via VLAN.

PoE

Power over Ethernet is a technology that lets network cables carry electrical power.

PPP

Point-to-point protocol that provides a standard method for transporting multi-protocol diagrams over point-to-point links.

PPPoE

A method for transmitting PPP over ethernet.

PPPoE HA

HA PPPoE support function without State.

Preempt

Applies to a post-failover condition in which the Primary unit has failed, and the Secondary unit has assumed the Active role. Enabling Preempt causes the Primary unit to seize the Active role from the Secondary after the Primary has been restored to a verified operational state.

Primary

The principal hardware unit itself. The Primary identifier is a manual designation and is not subject to conditional changes. Under normal operating conditions, the Primary hardware unit operates in an Active role.

Secondary (Backup)

The subordinate hardware unit itself. The Secondary identifier is a relational designation and is assumed by a unit when paired with a Primary unit. Under normal operating conditions, the Secondary unit operates in a Standby mode. Upon failure of the Primary unit, the Secondary unit assumes the Active role.

SHF

State Hardware Failover, a SonicOS feature that allows existing network flows to remain active when the primary firewall fails and the backup firewall takes over.

Standby (Idle)

The passive condition of a hardware unit. The Standby identifier is a logical role that can be assumed by either a Primary or Secondary hardware unit. The Standby unit assumes the Active role upon a determinable failure of the Active unit.

STP

Spanning Tree Protocol.

High Availability Modes

High Availability has several operation modes, which can be selected on the High Availability > Settings page:

None—Selecting None activates a standard high availability configuration and hardware failover functionality, with the option of enabling Stateful HA and Active/Active DPI.
Active/Standby—Active/Standby mode provides basic high availability with the configuration of two identical firewalls 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. To avoid this, 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. When the Active unit encounters a fault condition, stateful failover occurs as the Standby firewall takes over the Active role with no interruptions to the existing network connections.

* 
NOTE: Stateful HA is:
Included on NSA 4600 and higher NSA platforms and SuperMassive Series platforms.
Supported on the NSA 2600 and NSA 3600 platforms with a SonicOS Expanded License or a High Availability License.
Supported on the TZ500 and higher TZ platforms with a SonicOS Expanded License or a High Availability (Stateful) Upgrade License.

For licensing information, see Registering and Associating Firewalls on MySonicWall and Licensing High Availability Features.

Active/Active DPI—The Active/Active Deep Packet Inspection (DPI) mode can be used along with the Active/Standby mode. When Active/Active DPI mode is enabled, the processor intensive DPI services, such as Intrusion Prevention (IPS), Gateway Anti-Virus (GAV), and Anti-Spyware are processed on the standby firewall, while other services, such as firewall, NAT, and other types of traffic are processed on the Active firewall concurrently.
* 
NOTE: Active/Active DPI is:
Included on the SM 9000 series platforms.
Supported on the NSA 5600 and above platforms with a SonicOS Expanded License or a High Availability (Stateful) License.

For licensing information, see Registering and Associating Firewalls on MySonicWall and Licensing High Availability Features.

Active/Active Clustering—In this mode, multiple firewalls are grouped together as cluster nodes, with multiple Active units processing traffic (as multiple gateways), doing DPI and sharing the network load. Each cluster node consists of two units acting as a Stateful HA pair. Active/Active Clustering provides Stateful Failover support in addition to load-sharing. Optionally, each cluster node can also consist of a single unit, in which case Stateful Failover and Active/Active DPI are not available.
* 
NOTE: Active/Active Clustering is:
Included on the SM 9000 series platforms.
Supported on NSA 3600 and above platforms only with the purchase of a SonicOS Expanded License.

For licensing information, see Registering and Associating Firewalls on MySonicWall and Licensing High Availability Features.

Active/Active DPI Clustering—This mode allows for the configuration of up to four HA cluster nodes for failover and load sharing, where the nodes load balance the application of DPI security services to network traffic. This mode can be enabled for additional performance gain, utilizing the standby units in each cluster node.
* 
NOTE: Active/Active DPI Clustering is:
Included on the SM 9000 series platforms
Supported on NSA 3600 and above platforms only with the purchase of a SonicOS Expanded License.

For licensing information, see Registering and Associating Firewalls on MySonicWall and Licensing High Availability Features.

Crash Detection

The HA feature has a thorough self-diagnostic mechanism for both the Active and Standby firewalls. The failover to the standby unit occurs when critical services are affected, physical (or logical) link failure is detected on monitored interfaces, or when the firewall loses power.

The self-checking mechanism is managed by software diagnostics, which check the complete system integrity of the firewall. The diagnostics check internal system status, system process status, and network connectivity. There is a weighting mechanism on both sides to decide which side has better connectivity to avoid potential failover looping.

Critical internal system processes such as NAT, VPN, and DHCP (among others) are checked in real time. The failing service is isolated as early as possible, and the failover mechanism repairs it automatically.

Virtual MAC Address

The Virtual MAC address allows the High Availability pair to share the same MAC address, which dramatically reduces convergence time following a failover. Convergence time is the amount of time it takes for the devices in a network to adapt their routing tables to the changes introduced by high availability.

Without Virtual MAC enabled, the Active and Standby firewalls each have their own MAC addresses. Because the firewalls are using the same IP address, when a failover occurs, it breaks the mapping between the IP address and MAC address in the ARP cache of all clients and network resources. The Secondary firewall must issue an ARP request, announcing the new MAC address/IP address pair. Until this ARP request propagates through the network, traffic intended for the Primary firewall’s MAC address can be lost.

The Virtual MAC address greatly simplifies this process by using the same MAC address for both the Primary and Secondary firewalls. When a failover occurs, all routes to and from the Primary firewall are still valid for the Secondary firewall. All clients and remote sites continue to use the same Virtual MAC address and IP address without interruption.

By default, this Virtual MAC address is provided by the SonicWall firmware and is different from the physical MAC address of either the Primary or Secondary firewalls. This eliminates the possibility of configuration errors and ensures the uniqueness of the Virtual MAC address, which prevents possible conflicts. Optionally, you can manually configure the Virtual MAC address on the High Availability > Monitoring page.

The Virtual MAC setting is available even if Stateful High Availability is not licensed. When Virtual MAC is enabled, it is always used even if Stateful Synchronization is not enabled.

Dynamic WAN Interfaces with PPPoE HA

* 
NOTE: Dynamic WAN interfaces with PPPoE HA is not supported on the SuperMassive 9800. Only the DHCP Server dynamic WAN mode is supported.

Beginning with SonicOS 6.2.7.0, PPPoE can be enabled on interfaces in non-stateful mode, HA Active/Standby mode. PPPoE HA provides HA where a Secondary firewall assumes connection to the PPPoE server when the Active firewall fails.

* 
NOTE: One WAN interface must be configured as PPPoE; see Configuring a WAN Interface.

After the Active unit connects to the PPPoE server, the firewall synchronizes the PPPoE session ID and server name to the Secondary unit.

When the Active firewall fails, it terminates the PPPoE HA connection on the client side by timing out. The Secondary firewall connects to the PPPoE server, terminates the original connection on the server side, and starts a new PPPoE connection. All pre-existing network connections are rebuilt, the PPPoE sessions are re-established, and the PPP process is renegotiated.

Stateful Synchronization with DHCP

With SonicOS 6.2.7, DHCP can now be enabled on interfaces in both Active/Standby (non-stateful) and Stateful Synchronization modes.

Only the Active firewall can get a DHCP lease. The Active firewall synchronizes the DHCP IP address along with the DNS and gateway addresses to the Secondary firewall. The DHCP client ID is also synchronized, allowing this feature to work even without enabling Virtual MAC.

During a failover, the Active firewall releases the DHCP lease and, as it becomes the Active unit, the Secondary firewall renews the DHCP lease using the existing DHCP IP address and client ID. The IP address does not change, and network traffic, including VPN tunnel traffic, continues to pass.

If the Active firewall does not have an IP address when failover occurs, the Secondary firewall starts a new DHCP discovery.

Stateful Synchronization with DNS Proxy

DNS Proxy supports stateful synchronization of DNS cache. When the DNS cache is added, deleted, or updated dynamically, it synchronizes to the idle firewall.

About HA Monitoring

On the High Availability > Monitoring page, you can configure both physical and logical interface monitoring:

By enabling physical interface monitoring, you enable link detection for the designated HA interfaces. The link is sensed at the physical layer to determine link viability.
Logical monitoring involves configuring the SonicWall to monitor a reliable device on one or more of the connected networks.

Failure to periodically communicate with the device by the Active unit in the HA Pair triggers a failover to the Standby unit. If neither unit in the HA Pair can connect to the device, no action is taken.

The Primary and Secondary IP addresses configured on the High Availability > Monitoring page can be configured on LAN or WAN interfaces, and are used for multiple purposes:

As independent management addresses for each unit (supported on all physical interfaces)
To allow synchronization of licenses between the Standby unit and the SonicWall licensing server
As the source IP addresses for the probe pings sent out during logical monitoring

Configuring unique management IP addresses for both units in the HA Pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of these IP addresses. The Primary and Secondary firewalls’ unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN will need to use the virtual LAN IP address as their gateway.

If WAN monitoring IP addresses are configured, then X0 monitoring IP addresses are not required. If WAN monitoring IP addresses are not configured, then X0 monitoring IP addresses are required, since in such a scenario the Standby unit uses the X0 monitoring IP address to connect to the licensing server with all traffic routed via the Active unit.

The management IP address of the Secondary/Standby unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-firewall basis (not per-HA Pair). Even if the Secondary unit was already registered on MySonicWall before creating the HA association, you must use the link on the System > Licenses page to connect to the SonicWall server while accessing the Secondary firewall through its management IP address.

When using logical monitoring, the HA Pair pings the specified Logical Probe IP address target from the Primary as well as from the Secondary unit. The IP address set in the Primary IP Address or Secondary IP Address field is used as the source IP address for the ping. If both units can successfully ping the target, no failover occurs. If both cannot successfully ping the target, no failover occurs, as SonicOS assumes that the problem is with the target, and not the firewalls. If one firewall can ping the target but the other cannot, however, the HA Pair failovers to the unit that can ping the target.

The configuration tasks on the High Availability > Monitoring page are performed on the Primary unit and then are automatically synchronized to the Secondary.

About Active/Standby HA

HA allows two identical firewalls running SonicOS to be configured to provide a reliable, continuous connection to the public Internet. One firewall is configured as the Primary unit, and an identical firewall is configured as the Secondary unit. In the event of the failure of the Primary firewall, the Secondary firewall takes over to secure a reliable connection between the protected network and the Internet. Two firewalls configured in this way are also known as a High Availability Pair (HA Pair).

Active/Standby HA provides standard, high availability, and hardware failover functionality with the option of enabling stateful HA and Active/Active DPI.

HA provides a way to share licenses between two firewalls when one is acting as a high availability system for the other. To use this feature, you must register the firewalls on MySonicWall as Associated Products. Both firewalls must be the same SonicWall model.

Topics:  

Benefits of Active/Standby HA

Increased network reliability – In a High Availability configuration, the Secondary firewall assumes all network responsibilities when the Primary unit fails, ensuring a reliable connection between the protected network and the Internet.
Cost-effectiveness – High Availability is a cost-effective option for deployments that provide high availability by using redundant firewalls. You do not need to purchase a second set of licenses for the Secondary unit in a High Availability Pair.
Virtual MAC for reduced convergence time after failover – The Virtual MAC address setting allows the HA Pair to share the same MAC address, which dramatically reduces convergence time following a failover. Convergence time is the amount of time it takes for the devices in a network to adapt their routing tables to the changes introduced by high availability. By default, the Virtual MAC address is provided by the SonicWall firmware and is different from the physical MAC address of either the Primary or Secondary firewalls.

How Active/Standby HA Works

* 
NOTE: The TZ300 series and TZ400 series firewalls can be operated in Active/Standby HA mode without Stateful Synchronization. The SOHO W does not support High Availability with or without Stateful Synchronization.

HA requires one SonicWall firewall configured as the Primary SonicWall, and an identical SonicWall firewall configured as the Secondary SonicWall. During normal operation, the Primary SonicWall is in an Active state and the Secondary SonicWall in an Standby state. If the Primary device loses connectivity, the Secondary SonicWall transitions to Active mode and assumes the configuration and role of Primary, including the interface IP addresses of the configured interfaces.

Basic Active/Standby HA provides stateless high availability. After a failover to the Secondary firewall, all the pre-existing network connections must be re-established, including the VPN tunnels that must be re-negotiated. Stateful Synchronization can be licensed and enabled separately. For more information, see About Stateful Synchronization.

The failover applies to loss of functionality or network-layer connectivity on the Primary SonicWall. The failover to the Secondary SonicWall occurs when critical services are affected, physical (or logical) link failure is detected on monitored interfaces, or when the Primary SonicWall loses power. The Primary and Secondary SonicWall devices are currently only capable of performing Active/Standby High Availability or Active/Active DPI – complete Active/Active high availability is not supported at present.

There are two types of synchronization for all configuration settings:

Incremental – If the timestamps are in sync and a change is made on the Active unit, an incremental synchronization is pushed to the Standby unit.
Complete –If the timestamps are out of sync and the Standby unit is available, a complete synchronization is pushed to the Standby unit. When incremental synchronization fails, a complete synchronization is automatically attempted.

About Stateful Synchronization

Stateful Synchronization provides dramatically improved failover performance. When enabled, the network connections and VPN tunnel information is continuously synchronized between the two units so that the Secondary can seamlessly assume all network responsibilities if the Primary firewall fails, with no interruptions to existing network connections.

* 
NOTE: Stateful HA is included on NSA 4600 and higher NSA platforms and on all SuperMassive platforms. Stateful HA is supported on the TZ500 and higher TZ platforms and NSA 2600 and NSA 3600 platforms with an Extended or Stateful HA upgrade license.For licensing information, see Registering and Associating Firewalls on MySonicWall and Licensing High Availability Features.
Topics:  

Benefits of Stateful Synchronization

Improved reliability - By synchronizing most critical network connection information, Stateful Synchronization prevents down time and dropped connections in case of firewall failure.
Faster failover performance - By maintaining continuous synchronization between the Primary and Secondary firewalls, Stateful Synchronization enables the Secondary firewall to take over in case of a failure with virtually no down time or loss of network connections.
Minimal impact on CPU performance - Typically less than 1% usage.
Minimal impact on bandwidth - Transmission of synchronization data is throttled so as not interfere with other data.

How Does Stateful Synchronization Work?

Stateful Synchronization is not load-balancing. It is an active-standby configuration where the Primary firewall handles all traffic. When Stateful Synchronization is enabled, the Primary firewall actively communicates with the Secondary to update most network connection information. As the Primary firewall creates and updates network connection information (such as VPN tunnels, active users, connection cache entries), it immediately informs the Secondary firewall. This ensures that the Secondary firewall is always ready to transition to the Active state without dropping any connections.

The synchronization traffic is throttled to ensure that it does not interfere with regular network traffic. All configuration changes are performed on the Primary firewall and automatically propagated to the Secondary firewall. The High Availability pair uses the same LAN and WAN IP addresses—regardless of which firewall is currently Active.

When using SonicWall Global Management System (GMS) to manage the firewalls, GMS logs into the shared WAN IP address. In case of a failover, GMS administration continues seamlessly, and GMS administrators currently logged into the firewall are not logged out; however, Get and Post commands may result in a time out with no reply returned.

Synchronized and non-synchronized information lists the information that is synchronized and information that is not currently synchronized by Stateful Synchronization.

 

Synchronized and non-synchronized information

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 information

Real Audio

Content Filtering Service information

RTSP

VoIP protocols

GVC information

Dynamic ARP entries and ARP cache time outs

Dynamic Address Objects

Active wireless client information

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

Stateful Synchronization Example

In case of a failover, the following sequence of events occurs:

1
A PC user connects to the network, and the Primary firewall creates a session for the user.
2
The Primary firewall synchronizes with the Secondary firewall. The Secondary now has all of the user’s session information.
3
The administrator restarts the Primary unit.
4
The Secondary unit detects the restart of the Primary unit and switches from Standby to Active.
5
The Secondary firewall begins to send gratuitous ARP messages to the LAN and WAN switches using the same Virtual MAC address and IP address as the Primary firewall. No routing updates are necessary for downstream or upstream network devices.
6
When the PC user attempts to access a Web page, the Secondary firewall has all of the user’s session information and is able to continue the user’s session without interruption.

About Active/Active DPI HA

* 
IMPORTANT: Capture functionality is not supported in Active/Active DPI mode.

With Active/Active DPI enabled on a Stateful HA pair, the Deep Packet Inspection services are processed on the standby firewall of an HA pair concurrently with the processing of firewall, NAT, and other modules on the active firewall. The following DPI services are affected:

Intrusion Prevention Service (IPS)
Gateway Anti-Virus (GAV)
Gateway Anti-Spyware
Application Control

To use the Active/Active DPI feature, the administrator must configure an additional interface as the Active/Active DPI Interface. For example, if you choose to make X5 the Active/Active DPI Interface, you must physically connect X5 on the active unit to X5 on the standby unit in the HA pair. Certain packet flows on the active unit are selected and offloaded to the standby unit on the Active/Active DPI Interface. DPI is performed on the standby unit and then the results are returned to the active unit over the same interface. The remaining processing is performed on the active unit.

* 
NOTE: Active/Active DPI is included on SuperMassive 9200, 9400, and 9600 platforms and is supported on the NSA 5600 and NSA 6600 only with extended licenses. For licensing information, see Registering and Associating Firewalls on MySonicWall and Licensing High Availability Features.

Benefits of Active/Active DPI HA

Active/Active DPI taps into the unused CPU cycles available in the standby unit, but the traffic still arrives and leaves through the active unit. The standby unit only sees the network traffic offloaded by the active unit, and processing of all modules other than DPI services is restricted to the active unit.

Active/Standby and Active/Active DPI Prerequisites

This section lists the supported platforms, provides recommendations and requirements for physically connecting the units, and describes how to register, associate, and license the units for High Availability.

Topics:  

Supported Platforms for HA

Licenses included with the purchase of a SonicWall firewall are shown in Licensing requirements for HA, Stateful HA, and A/A DPI. Some platforms require additional licensing to use the HA features. HA Upgrade and Expanded licenses can be purchased on MySonicWall or from a SonicWall reseller.

* 
NOTE: HA licenses must be activated on each firewall, either by registering the unit on MySonicWall from the SonicOS management interface, or by applying the license keyset to each unit if Internet access is not available.
 

Licensing requirements for HA, Stateful HA, and A/A DPI

Platform 1

HA

Stateful HA – SonicOS version

A/A DPI – SonicOS version

6.2.6

6.2.7

6.2.9

6.2.6

6.2.7

6.2.9

SM 9800

Included

N/A

Included 2

N/A

Included 3

SM 9600

Included

Included

Included

SM 9400

Included

Included

Included

SM 9200

Included

Included

Included

NSA 6600

Included

Included

Expanded License

NSA 5600

Included

Included

Expanded License

NSA 4600

Included

Included

N/A

NSA 3600

Included

Expanded license or HA License

N/A

NSA 2600

Included

Expanded license or HA License

N/A

TZ600

Included

Stateful HA Upgrade or Expanded License

N/A

TZ500/TZ500 W

Included

Stateful HA Upgrade or Expanded License

N/A

TZ400/TZ400 W

Included

N/A

N/A

TZ300/TZ300 W

Included

N/A

N/A

SOHO W

N/A

N/A

N/A


1
N/A = not applicable; Included = included with appliance

2
Starting with SonicOS 6.2.7.7

3
Starting with SonicOS 6.2.7.7

You can view system licenses on the System > Licenses page. This page also provides a way to log into MySonicWall. For information about licensing, see Registering and Associating Firewalls on MySonicWall.

Physically Connecting Your Firewalls

* 
NOTE: For complete procedures for connecting your firewalls, see the Getting Started Guide for your firewall. For procedures for connecting Active/Active Cluster firewalls, see Connecting the HA Ports for Active/Active Clustering and Connecting Redundant Port Interfaces.

If you are connecting the Primary and Secondary firewalls to an Ethernet switch that uses the spanning tree protocol, be aware that it may be necessary to adjust the link activation time on the switch port to which the SonicWall interfaces connect. For example, on a Cisco Catalyst-series switch, it is necessary to activate spanning tree port fast for each port connecting to the SonicWall firewall’s interfaces.

High Availability requires additional physical connections among the affected SonicWall firewalls.For all modes, you need connections for HA Control and HA Data. Active/Active DPI requires an additional connection.

In any High Availability deployment, you must physically connect the LAN and WAN ports of all units to the appropriate switches.

It is important that the X0 interfaces from all units be connected to the same broadcast domain. Otherwise, traffic failover will not work. Also, X0 is the default redundant HA port; if the normal HA Control link fails, X0 is used to communicate heartbeats between units. Without X0 in the same broadcast domain, both units would become active if the HA Control link fails.

A WAN connection to the Internet is useful for registering your firewalls on MySonicWall and for synchronizing licensing information. Unless live communication with SonicWall's licensing server is not permitted due to network policy, the WAN (X1) interface should be connected before registration and licensing are performed.

Connecting the Active/Active DPI Interfaces for Active/Active DPI

For Active/Active DPI, you must physically connect at least one additional interface, called the Active/Active DPI Interface, between the two firewalls in each HA pair, or Cluster Node. The connected interfaces must be the same number on both firewalls, and must initially appear as unused, unassigned interfaces in the Network > Interfaces page. For example, you could connect X5 on the Primary unit to X5 on the Secondary if X5 is an unassigned interface. After enabling Active/Active DPI, the connected interface will have a Zone assignment of HA Data-Link.

Certain packet flows on the active unit are selected and offloaded to the standby unit on the Active/Active DPI Interface. DPI is performed on the standby unit and then the results are returned to the active unit over the same interface.

Optionally, for port redundancy with Active/Active DPI, you can physically connect a second Active/Active DPI Interface between the two firewalls in each HA pair. This interface takes over transferring data between the two units during Active/Active DPI processing if the first Active/Active DPI Interface has a fault.

To connect the Active/Active DPI Interfaces for Active/Active DPI:
1
Decide which interface to use for the additional connection between the firewalls in the HA pair. The same interface must be selected on each firewall.
2
In the SonicOS management interface, navigate to the Network > Interfaces page and ensure that the Zone is Unassigned for the intended Active/Active DPI Interface.
3
Using a standard Ethernet cable, connect the two interfaces directly to each other.
4
Optionally, for port redundancy with Active/Active DPI, physically connect a second Active/Active DPI Interface between the two firewalls in each HA pair.

Registering and Associating Firewalls on MySonicWall

To use High Availability, you must register both firewalls and associate them for HA on MySonicWall. When you click the link for a registered firewall in your MySonicWall page, the Service Management page displays for that firewall. At the bottom of the Service Management page, you can click the HA Secondary link under Associated Products. Then follow the instructions to select and associate the other unit for your HA Pair. For further information about registering your firewalls, see the Getting Started Guide for your firewalls.

After the firewalls are associated as an HA pair, they can share licenses. In addition to High Availability licenses, this includes the SonicOS license, the Support subscription, and the security services licenses. The only licenses that are not shareable are for consulting services, such as the SonicWall GMS Preventive Maintenance Service.

It is not required that the Primary and Secondary firewalls have the same security services enabled. The security services settings will be automatically updated as part of the initial synchronization of settings. License synchronization is used so that the Secondary firewall can maintain the same level of network protection provided before the failover.

MySonicWall provides several methods of associating the two firewalls. You can start by registering a new firewall, and then choosing an already-registered unit to associate it with. Or, you can associate two units that are both already registered. You can also start the process by selecting a registered unit and adding a new firewall with which to associate it.

* 
NOTE: Even if you first register your firewalls on MySonicWall, you must individually register both the Primary and the Secondary firewalls from the SonicOS management interface while logged into the individual management IP address of each firewall. This allows the Secondary unit to synchronize with the SonicWall license server and share licenses with the associated Primary firewall. When Internet access is restricted, you can manually apply the shared licenses to both firewall.

For information about configuring and using the individual management IP address of each firewall, see About High Availability Monitoring with Active/Clustering and Monitoring High Availability.

Licensing High Availability Features

The HA licenses included with the purchase of the SonicWall network firewall is shown in HA licenses available with SonicWall network security firewalls. Some platforms require additional licensing to use the Stateful Synchronization or Active/Active DPI features. SonicOS Expanded licenses or High Availability licenses can be purchased on MySonicWall or from a SonicWall reseller.

* 
NOTE: Stateful High Availability licenses must be activated on each firewall, either by registering the unit on MySonicWall from the SonicOS management interface, or by applying the license keyset to each unit if Internet access is not available.
 

HA licenses available with SonicWall network security firewalls

Platform

Active/Standby HA 1

Stateful HA

A/A Clustering

A/A DPI

SM 9800

Included

License

Included

Included

SM 9600

Included

Included

Included

Included

SM 9400

Included

Included

Included

Included

SM 9200

Included

Included

Included

Included

NSA 6600

Included

Included

Expanded License

Expanded License

NSA 5600

Included

Included

Expanded License

Expanded License

NSA 4600

Included

Included

Expanded License

N/A

NSA 3600

Included

Expanded License

HA License

Expanded License

N/A

NSA 2600

Included

Expanded License

HA License

N/A

N/A

TZ600

Included

Expanded License

Stateful HA Upgrade License

N/A

N/A

TZ500/TZ500 W

Included

Expanded License

Stateful HA Upgrade License

N/A

N/A

TZ400/TZ400 W

Included

N/A

N/A

N/A

TZ300/TZ300 W

Included

N/A

N/A

N/A

SOHO W

N/A

N/A

N/A

N/A


1
NA = Feature not available

You can view system licenses on the System > Licenses page. This page also provides a way to log into MySonicWall and to apply licenses to a firewall. For further information, see Managing SonicWall Licenses.

There is also a way to synchronize licenses for an HA pair whose firewalls do not have Internet access. When live communication with SonicWall's licensing server is not permitted due to network policy, you can use license keysets to manually apply security services licenses to your firewalls. When you register a firewall on MySonicWall, a license keyset is generated for the firewall. If you add a new security service license, the keyset is updated. However, until you apply the licenses to the firewall, it cannot perform the licensed services.

* 
IMPORTANT: In a High Availability deployment without Internet connectivity, you must apply the license keyset to both of the firewalls in the HA pair.

Maintenance

Topics:  

Removing an HA Association

You can remove the association between two SonicWall firewalls on MySonicWall at any time. You might need to remove an existing HA association if you replace an firewall or reconfigure your network. For example, if one of your SonicWall firewalls fails, you will need to replace it. Or, you might need to switch the HA Primary firewall with the Secondary, or HA Secondary, unit after a network reconfiguration. In either case, you must first remove the existing HA association, and then create a new association that uses a new firewall or changes the parent-child relationship of the two units (see Replacing a SonicWall Firewall).

To remove the association between two registered SonicWall firewalls:
1
Login to MySonicWall.
2
In the left navigation bar, click My Products.
3
On the My Products page, under Registered Products, scroll down to find the secondary firewall from which you want to remove associations. Click the product name or serial number.
4
On the Service Management - Associated Products page, scroll down to the Parent Product section, just above the Associated Products section.
5
Under Parent Product, to remove the association for this firewall:
a
Click Remove.
b
Wait for the page to reload.
c
Scroll down.
d
Click Remove again.

Replacing a SonicWall Firewall

If your SonicWall firewall has a hardware failure while still under warranty, SonicWall will replace it. In this case, you need to remove the HA association containing the failed firewall in MySonicWall, and add a new HA association that includes the replacement. If you contact SonicWall Technical Support to arrange the replacement (known as an RMA), Support will often take care of this for you.

After replacing the failed firewall in your equipment rack with the new unit, you can update MySonicWall and your SonicOS configuration.

Replacing a failed HA Primary unit is slightly different than replacing an HA Secondary unit. Both procedures are provided in these sections:

Replacing an HA Primary Unit
To replace an HA Primary unit:
1
In the SonicOS management interface of the remaining SonicWall firewall (the Secondary unit), on the High Availability page, uncheck Enable High Availability to disable it.
2
Check Enable High Availability.

The old Secondary unit now becomes the Primary unit. Its serial number is automatically displayed in the Primary SonicWall Serial Number field.

3
Type the serial number for the replacement unit into the Secondary SonicWall Serial Number field.
4
Click Synchronize Settings.
5
On MySonicWall, remove the old HA association. See Removing an HA Association.
6
On MySonicWall, register the replacement SonicWall firewall and create an HA association with the new Primary (original Secondary) unit as the HA Primary, and the replacement unit as the HA Secondary. See Registering and Associating Firewalls on MySonicWall.
7
Contact SonicWall Technical Support to transfer the security services licenses from the former HA Pair to the new HA Pair.

This step is required when the HA Primary unit has failed because the licenses are linked to the Primary unit in an HA Pair.

Replacing an HA Secondary Unit
To replace an HA Secondary unit:
1
On MySonicWall, remove the old HA association as described in Removing an HA Association.
2
On MySonicWall, register the replacement SonicWall firewall.
3
Create an HA association with the original HA Primary, using the replacement unit as the HA Secondary as described in Replacing an HA Primary Unit.

Active/Active Clustering

* 
NOTE: Active/Active Clustering is supported on NSA 3600 and above firewalls. See HA licenses available with SonicWall network security firewalls and Licensing requirements for A/A Clustering
Topics:  

About Active/Active Clustering

An Active/Active Cluster is formed by a grouping up to four Cluster Nodes, with multiple Active units processing traffic (as multiple gateways), doing DPI, and sharing the network load. A Cluster Node can consist of a Stateful HA pair, a Stateless HA pair with standard failover, or a single standalone unit, in which case Stateful Failover and Active/Active DPI are not available. Dynamic state synchronization is only available in a Cluster Node if it is a Stateful HA pair. The traditional SonicWall High Availability protocol or Stateful HA protocol is used for communication within the Cluster Node, between the units in the HA pair.

When a Cluster Node is a Stateful HA pair, Active/Active DPI can be enabled within the Cluster Node for higher performance.

With Active/Active Clustering, you can assign certain traffic flows to each node in the cluster, providing load sharing in addition to redundancy, and supporting a much higher throughput without a single point of failure.

With Active/Active Clustering, you can assign certain traffic flows to each node in the cluster, providing load sharing in addition to redundancy, and supporting a much higher throughput without a single point of failure.

A typical recommended setup includes four firewalls of the same SonicWall model configured as two Cluster Nodes, where each node consists of one Stateful HA pair. For larger deployments, the cluster can include eight firewalls, configured as four Cluster Nodes (or HA pairs). Within each Cluster Node, Stateful HA keeps the dynamic state synchronized for seamless failover with zero loss of data on a single point of failure. Stateful HA is not required, but is highly recommended for best performance during failover.

Load sharing is accomplished by configuring different Cluster Nodes as different gateways in your network. Typically this is handled by another device downstream (closer to the LAN devices) from the Active/Active Cluster, such as a DHCP server or a router.

A Cluster Node can also be a single firewall, allowing an Active/Active cluster setup to be built using two firewalls. In case of a fault condition on one of the firewalls in this deployment, the failover is not stateful since neither firewall in the Cluster Node has an HA Secondary.

Redundancy is achieved at several levels with Active/Active Clustering:

The cluster provides redundant Cluster Nodes, each of which can handle the traffic flows of any other Cluster Node, if a failure occurs.
The Cluster Node consists of a Stateful HA pair, in which the Secondary firewall can assume the duties of the Primary unit in case of failure.
Port redundancy, in which an unused port is assigned as a secondary to another port, provides protection at the interface level without requiring failover to another firewall or node.
Active/Active DPI can be enabled, providing increased throughput within each Cluster Node.
Topics:  

Example: Active/Active Clustering – Four-Unit Deployment

Active/Active four-unit cluster shows a four-unit cluster. Each Cluster Node contains one HA pair. The designated HA ports of all four firewalls are connected to a Layer 2 switch. These ports are used for Cluster Node management and monitoring state messages sent over SVRRP, and for configuration synchronization. The two units in each HA pair are also connected to each other using another interface (shown as the Xn interface). This is the Active/Active DPI Interface necessary for Active/Active DPI. With Active/Active DPI enabled, certain packets are offloaded to the standby unit of the HA pair for DPI processing.

Active/Active four-unit cluster

For more information about physically connecting redundant ports and redundant switches, see the Active/Active Clustering Full Mesh Deployment Technote.

Example: Active/Active Clustering – Two-Unit Deployment

Active/Active two-unit cluster shows a two-unit cluster. In a two-unit cluster, HA pairs are not used. Instead, each Cluster Node contains a single firewall. The designated HA ports on the two firewalls are connected directly to each other using a cross-over cable. The SonicWall Virtual Router Redundancy Protocol (SVRRP) uses this HA port connection to send Cluster Node management and monitoring state messages. SVRRP management messages are initiated on the Master Node, and monitoring information is communicated from every firewall in the cluster. The HA port connection is also used for configuration synchronization between Cluster Nodes.

Active/Active two-unit cluster

Benefits of Active/Active Clustering

The benefits of Active/Active Clustering include the following:

All the firewalls in the cluster are utilized to derive maximum throughput
Can run in conjunction with Active/Active DPI to perform concurrent processing of IPS, GAV, Anti-Spyware, and App Rules services, which are the most processor intensive, on the standby firewall in each HA pair while the active firewall performs other processing
Load sharing is supported by allowing the assignment of particular traffic flows to each node in the cluster
All nodes in the cluster provide redundancy for the other nodes, handling traffic as needed if other nodes go down
Interface redundancy provides secondary for traffic flow without requiring failover
Both Full Mesh and non-Full Mesh deployments are supported

How Does Active/Active Clustering Work?

There are several important concepts that are introduced for Active/Active Clustering.

Topics:  
About Cluster Nodes

An Active/Active Cluster is formed by a collection of Cluster Nodes. A Cluster Node can consist of a Stateful HA pair, a Stateless HA pair or a single standalone unit. Dynamic state synchronization is only available in a Cluster Node if it is a Stateful HA pair. The traditional SonicWall High Availability protocol or Stateful HA protocol is used for communication within the Cluster Node, between the units in the HA pair.

When a Cluster Node is a Stateful HA pair, Active/Active DPI can be enabled within the Cluster Node for higher performance.

About the Cluster

All firewalls in the Cluster must be of same product model and be running the same firmware version.

Within the cluster, all firewalls are connected and communicating with each other; see Active/Active two-node cluster. For communication between Cluster Nodes, a new protocol, called SonicWall Virtual Router Redundancy Protocol (SVRRP), is used. Cluster Node management and monitoring state messages are sent using SVRRP.

All Cluster Nodes share the same configuration, which is synchronized by the Master Node. The Master Node is also responsible for synchronizing firmware to the other nodes in the cluster. The HA port connection is used to synchronize configuration and firmware updates.

Dynamic state is not synchronized across Cluster Nodes, but only within a Cluster Node. When a Cluster Node contains an HA pair, Stateful HA can be enabled within that Cluster Node, with the advantages of dynamic state synchronization and stateful failover as needed. In the event of the failure of an entire Cluster Node, the failover will be stateless. This means that pre-existing network connections must be rebuilt. For example, Telnet and FTP sessions must be re-established and VPN tunnels must be renegotiated.

About Failover provides more information about how failover works.

The maximum number of Cluster Nodes in a cluster is currently limited to four. If each Cluster Node is an HA pair, the cluster includes eight firewalls.

Active/Active two-node cluster

Actions Allowed Within the Cluster

The types of administrative actions that are allowed differ based on the state of the firewall in the cluster. All actions are allowed for admin users with appropriate privileges on the active firewall of the Master Node, including all configuration actions. A subset of actions are allowed on the active firewall of Non-Master nodes, and even fewer actions are allowed on firewalls in the standby state. Administrative actions allowed lists the allowed actions for active firewalls of Non-Master nodes and standby firewalls in the cluster.

 

Administrative actions allowed

Administrative Action

Active Non‑Master

Standby

Read-only actions

Allowed

Allowed

Registration on MySonicWall

Allowed

Allowed

License Synchronization with SonicWall License Manager

Allowed

Allowed

Diagnostic tools in System > Diagnostics

Allowed

Allowed

Packet capture

Allowed

Allowed

HA Synchronize Settings (syncs settings to the HA peer within the node)

Not Allowed

Not allowed

HA Synchronize Firmware (syncs firmware to the HA peer within the node)

Allowed

Not allowed

Administrative logout of users

Allowed

Not allowed

Authentication tests (such as test LDAP, test RADIUS, test Authentication Agent)

Allowed

Not allowed

About Virtual Groups

Active/Active Clustering also supports the concept of Virtual Groups. Currently, a maximum of four Virtual Groups are supported.

A Virtual Group is a collection of virtual IP addresses for all the configured interfaces in the cluster configuration (unused/unassigned interfaces do not have virtual IP addresses). When Active/Active Clustering is enabled for the first time, the configured IP addresses for the interfaces on that firewall are converted to virtual IP addresses for Virtual Group 1. Thus, Virtual Group 1 includes virtual IP addresses for X0, X1, and any other interfaces that are configured and assigned to a zone.

A Virtual Group can also be thought of as a logical group of traffic flows within a failover context, in that the logical group of traffic flows can failover from one node to another depending upon the fault conditions encountered. Each Virtual Group has one Cluster Node acting as the owner and one or more Cluster Nodes acting as standby. A Virtual Group is only owned by one Cluster Node at a time, and that node becomes the owner of all the virtual IP addresses associated with that Virtual Group. The owner of Virtual Group 1 is designated as the Master Node, and is responsible for synchronizing configuration and firmware to the other nodes in the cluster. If the owner node for a Virtual Group encounters a fault condition, one of the standby nodes will become the owner.

As part of the configuration for Active/Active Clustering, the serial numbers of other firewalls in the cluster are entered into the SonicOS management interface, and a ranking number for the standby order is assigned to each. When the Active/Active Clustering configuration is applied, up to three additional Virtual Groups are created, corresponding to the additional Cluster Nodes added, but virtual IP addresses are not created for these Virtual Groups. You need to configure these virtual IP addresses on the Network > Interfaces page.

There are two factors in determining Virtual Group ownership (which Cluster Node owns which Virtual Group):

Rank of the Cluster Node – The rank is configured in the SonicOS management interface to specify the priority of each node for taking over the ownership of a Virtual Group.
Virtual Group Link Weight of the Cluster Nodes – This is the number of interfaces in the Virtual Group that are up and have a configured virtual IP address.

When more than two Cluster Nodes are configured in a cluster, these factors determine the Cluster Node that is best able to take ownership of the Virtual Group. In a cluster with two Cluster Nodes, one of which has a fault, naturally the other will take ownership.

SVRRP is used to communicate Virtual Group link status and ownership status to all Cluster Nodes in the cluster.

The owner of Virtual Group 1 is designated as the Master Node. Configuration changes and firmware updates are only allowed on the Master Node, which uses SVRRP to synchronize the configuration and firmware to all the nodes in the cluster. On a particular interface, virtual IP addresses for Virtual Group 1 must be configured before other Virtual Groups can be configured.

Load Sharing and Multiple Gateway Support

The traffic for the Virtual Group is processed only by the owner node. A packet arriving on a Virtual Group will leave the firewall on the same Virtual Group. In a typical configuration, each Cluster Node owns a Virtual Group, and therefore processes traffic corresponding to one Virtual Group.

This Virtual Group functionality supports a multiple gateway model with redundancy. In a deployment with two Cluster Nodes, the X0 Virtual Group 1 IP address can be one gateway and the X0 Virtual Group 2 IP address can be another gateway. 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.

When Active/Active Clustering is enabled, the SonicOS internal DHCP server is turned off and cannot be enabled. Networks needing a DHCP server can use an external DHCP server which is aware of the multiple gateways, so that the gateway allocation can be distributed.

* 
NOTE: When Active/Active Clustering is enabled, the SonicOS internal DHCP server is turned off.
Effect on Related Configuration Pages

When Active/Active Clustering is initially enabled, the existing IP addresses for all configured interfaces are automatically converted to virtual IP addresses for Virtual Group 1. When Virtual Group 1 or any Virtual Group is created, default interface objects are created for virtual IP addresses with appropriate names, such as “Virtual Group 1” or “Virtual Group 2”. The same interface can have multiple virtual IP addresses, one for each Virtual Group that is configured. You can view these virtual IP addresses in the Network > Interfaces page.

* 
NOTE: All Cluster Nodes in the Active/Active cluster share the same configuration

A virtual MAC address is associated with each virtual IP address on an interface and is generated automatically by Sonic OS. The virtual MAC address is created in the format 00-17-c5-6a-XX-YY, where XX is the interface number such as “03” for port X3, and YY is the internal group number such as “00” for Virtual Group 1, or “01” for Virtual Group 2.

* 
NOTE: The Active/Active virtual MAC address is different from the High Availability virtual MAC address. The High Availability virtual MAC address functionality is not supported when Active/Active Clustering is enabled.

NAT policies are automatically created for the affected interface objects of each Virtual Group. These NAT policies extend existing NAT policies for particular interfaces to the corresponding virtual interfaces. You can view these NAT policies in the Network > NAT Policies page. Additional NAT policies can be configured as needed and can be made specific to a Virtual Group if desired.

After Active/Active Clustering is enabled, you must select the Virtual Group number during configuration when adding a VPN policy.

About SVRRP

For communication between Cluster Nodes in an Active/Active cluster, a new protocol called SonicWall Virtual Router Redundancy Protocol (SVRRP) is used. Cluster Node management and monitoring state messages are sent using SVRRP over the Active/Active Cluster links.

SVRRP is also used to synchronize configuration changes, firmware updates, and signature updates from the Master Node to all nodes in the cluster. In each Cluster Node, only the active unit processes the SVRRP messages.

In the case of failure of the Active/Active Cluster links, SVRRP heartbeat messages are sent on the X0 interface. However, while the Active/Active Cluster links are down, configuration is not synchronized. Firmware or signature updates, changes to policies, and other configuration changes cannot be synchronized to other Cluster Nodes until the Active/Active Cluster links are fixed.

About Failover

There are two types of failover that can occur when Active/Active Clustering is enabled:

High Availability failover – Within an HA pair, the Secondary unit takes over for the Primary. If Stateful HA is enabled for the pair, the failover occurs without interruption to network connections.
Active/Active failover – If all the units in the owner node for a Virtual Group encounter a fault condition, then the standby node for the Virtual Group takes over the Virtual Group ownership. Active/Active failover transfers ownership of a Virtual Group from one Cluster Node to another. The Cluster Node that becomes the Virtual Group owner also becomes the owner of all the virtual IP addresses associated with the Virtual Group and starts using the corresponding virtual MAC addresses.

Active/Active failover is stateless, meaning that network connections are reset and VPN tunnels must be renegotiated. Layer 2 broadcasts inform the network devices of the change in topology as the Cluster Node which is the new owner of a Virtual Group generates ARP requests with the virtual MACs for the newly owned virtual IP addresses. This greatly simplifies the failover process as only the connected switches need to update their learning tables. All other network devices continue to use the same virtual MAC addresses and do not need to update their ARP tables, because the mapping between the virtual IP addresses and virtual MAC addresses is not broken.

When both High Availability failover and Active/Active failover are possible, HA failover is given precedence over Active/Active failover for the following reasons:

HA failover can be stateful, whereas Active/Active failover is stateless.
The standby firewall in an HA pair is lightly loaded and has resources available for taking over the necessary processing, although it may already be handling DPI traffic if Active/Active DPI is enabled. The alternative Cluster Node might already be processing traffic comparable in amount to the failed unit, and could become overloaded after failover.

Active/Active failover always operates in Active/Active preempt mode. Preempt mode means that, after failover between two Cluster Nodes, the original owner node for the Virtual Group will seize the active role from the standby node after the owner node has been restored to a verified operational state. The original owner has a higher priority for a Virtual Group due to its higher ranking if all virtual IP interfaces are up and the link weight is the same between the two Cluster Nodes.

About DPI with Active/Active Clustering

Active/Active DPI can be used along with Active/Active Clustering. When Active/Active DPI is enabled, it utilizes the standby firewall in the HA pair for DPI processing.

For increased performance in an Active/Active cluster, enabling Active/Active DPI is recommended, as it utilizes the standby firewall in the HA pair for Deep Packet Inspection (DPI) processing.

About High Availability Monitoring with Active/Clustering

When Active/Active Clustering is enabled, HA monitoring configuration is supported for the HA pair in each Cluster Node. The HA monitoring features are consistent with previous versions. HA monitoring can be configured for both physical/link monitoring and logical/probe monitoring. After logging into the Master Node, monitoring configuration needs to be added on a per Node basis from the High Availability > Monitoring page.

* 
NOTE: The High Availability > Monitoring page applies only to the HA pair that you are logged into, not to the entire cluster.

Physical interface monitoring enables link detection for the monitored interfaces. The link is sensed at the physical layer to determine link viability.

When physical interface monitoring is enabled, with or without logical monitoring enabled, HA failover takes precedence over Active/Active failover. If a link fails or a port is disconnected on the active unit, the standby unit in the HA pair will become active.

* 
NOTE: For interfaces with configured virtual IP addresses, Active/Active physical monitoring is implicit and is used to calculate the Virtual Group Link Weight. Physical monitoring cannot be disabled for these interfaces. This is different from HA monitoring.

Logical monitoring involves configuring SonicOS to monitor a reliable device on one or more of the connected networks. Failure to periodically communicate with the device by the active unit in the HA pair will trigger a failover to the standby unit. If neither unit in the HA pair can connect to the device, the problem is assumed to be with the device and no failover will occur.

If both physical monitoring and logical monitoring are disabled, Active/Active failover will occur on link failure or port disconnect.

The Primary and Secondary IP addresses configured on the High Availability > Monitoring page can be configured on LAN or WAN interfaces, and are used for multiple purposes:

As independent management addresses for each unit, regardless of the Active or Standby status of the unit (supported on all physical interfaces)
To allow synchronization of licenses between the standby unit and the SonicWall licensing server
As the source IP addresses for the probe pings sent out during logical monitoring

Configuring monitoring IP addresses for both units in the HA pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of the monitoring IP addresses. The Primary and Secondary firewall’s unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN need to use a virtual LAN IP address as their gateway.

* 
NOTE: When HA Monitoring/Management IP addresses are configured only on WAN interfaces, they need to be configured on all the WAN interfaces for which a Virtual IP address has been configured.

The management IP address of the Secondary unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-firewall basis (not per-HA pair). Even if the standby unit was already registered on MySonicWall before creating the HA association, you must use the link on the System > Licenses page to connect to the SonicWall server while accessing the Secondary firewall through its management IP address. This allows synchronization of licenses (such as the Active/Active Clustering or the Stateful HA license) between the standby unit and the SonicWall licensing server.

When using logical monitoring, the HA pair will ping the specified Logical Probe IP address target from the Primary as well as from the Secondary SonicWall. The IP address set in the Primary IP Address or Secondary IP Address field is used as the source IP address for the ping. If both units can successfully ping the target, no failover occurs. If both cannot successfully ping the target, no failover occurs, as the SonicWalls will assume that the problem is with the target, and not the SonicWalls. But, if one SonicWall can ping the target but the other SonicWall cannot, the HA pair will failover to the SonicWall that can ping the target.

The configuration tasks on the High Availability > Monitoring page are performed on the Primary unit and then are automatically synchronized to the Secondary.

Features Supported with Active/Active Clustering

Topics:  
Caveats

When Active/Active Clustering is enabled, only static IP addresses can be used on the WAN.

The following features are not supported when Active/Active Clustering is enabled:

DHCP Server
L3 Transparent Mode
L2 Bridging / L2 Transparent Mode
Dynamic DNS
Wire Mode

The following features are only supported on Virtual Group 1:

SonicWall GVC
SonicOS SSL VPN
IP Helper
Backward Compatibility

The Active/Active Clustering feature is not backward compatible. When upgrading to SonicOS from a previous release that did not support Active/Active Clustering, it is highly recommended that you disable High Availability before exporting the preferences from an HA pair running a previous version of SonicOS. The preferences can then be imported without potential conflicts after upgrading.

SonicPoint Compatibility

There are two points to consider when using SonicWall SonicPoints together with Active/Active Clustering:

SonicPoints only communicate with the Master node for downloading firmware and other aspects of operation.
SonicPoints need access to an independent DCHP server. SonicPoints require a DHCP server to provide IP addresses to wireless clients, but the embedded SonicOS DHCP server is automatically disabled when Active/Active Clustering is enabled.
WAN Load Balancing Compatibility

When WAN Load Balancing (WLB) is enabled in an Active/Active Cluster, the same WLB interface configuration is used for all nodes in the cluster.

A WAN interface failure can trigger either a WLB failover, an HA pair failover, or an Active/Active failover to another Cluster Node, depending on the following:

WAN goes down logically due to WLB probe failure – WLB failover
Physical WAN goes down while Physical Monitoring is enabled – HA pair failover
Physical WAN goes down while Physical Monitoring is not enabled – Active/Active failover
Routing Topology and Protocol Compatibility

This section describes the current limitations and special requirements for Active/Active Clustering configurations with regard to routing topology and routing protocols.

Layer-2 Bridge Support

Layer-2 Bridged interfaces are not supported in a cluster configuration.

OSPF Support

OSPF is supported with Active/Active Clustering. When enabled, OSPF runs on the OSPF-enabled interfaces of each active Cluster Node. From a routing perspective, all Cluster Nodes appear as parallel routers, each with the virtual IP address of the Cluster Node's interface. In general, any network advertised by one node is advertised by all other nodes.

The OSPF router-ID of each Cluster Node must be unique and is derived from the router-ID configured on the Master node as follows:

If the user enters 0 or 0.0.0.0 for the router-ID in the OSPF configuration, each node’s router-ID is assigned the node’s X0 virtual IP address.
If the user enters any value other than 0 or 0.0.0.0 for the router-ID, each node is assigned a router-ID with consecutive values incremented by one for each node. For example, in a 4-node cluster, if the router-ID 10.0.0.1 was configured on the Master node, the router-ID’s assigned would be:
Node 1: 10.0.0.1
Node 2: 10.0.0.2
Node 3: 10.0.0.3
Node 4: 10.0.0.4
RIP Support

RIP is supported, and like OSPF, runs on the RIP-enabled interfaces of each Cluster Node. From a routing perspective, all Cluster Nodes appear as parallel routers with the virtual IP address of the Cluster Node’s interface. In general, any network advertised by one node is advertised by all other nodes.

BGP Support

BGP is supported in clusters, and also appears as parallel BGP routers using the virtual IP address of the Cluster Node’s interface. As with OSPF and RIP, configuration changes made on the Master node are applied to all other Cluster Nodes. In the case of BGP, where configuration may only be applied through the CLI, the configuration is distributed when the running configuration is saved with the write file CLI command (see the SonicOS 6.2 CLI Reference Guide).

Asymmetric Routing In Cluster Configurations

SonicOS 6.2.4.0 introduces support for asymmetric routing for traffic flows across different layer 2 bridged pair interfaces on the firewall or when it flows across different firewalls in a high availability cluster.

Active/Active Clustering Prerequisites

* 
NOTE: In addition to the requirements described in this section, ensure that you have completed the prerequisites described in Active/Standby and Active/Active DPI Prerequisites.

For Active/Active Clustering, additional physical connections are required:

Active/Active Cluster Link—Each Active/Active cluster link must be at least a 100MB interface, but a 1GB interface is preferred.

Active/Active Clustering configuration can include configuring Virtual Group IDs and redundant ports. Procedures are provided in this section for both of these tasks within the High Availability > Settings.

Topics:  
Licensing Requirements for Active/Active Clustering

Active/Active Clustering licenses included with the purchase of a SonicWall firewall are shown in Licensing requirements for A/A Clustering. Some platforms require additional licensing to use the Active/Active Clustering features. SonicOS Expanded licenses can be purchased on MySonicWall or from a SonicWall reseller.

* 
NOTE: Active/Active Clustering licenses must be activated on each firewall, either by registering the unit on MySonicWall from the SonicOS management interface, or by applying the license keyset to each unit if Internet access is not available.
 

Licensing requirements for A/A Clustering

Platform

SonicOS version 1

6.2.6

6.2.7

6.2.9

SM 9800

N/A

Included 2

SM 9600

Included

SM 9400

Included

SM 9200

Included

NSA 6600

Expanded license

NSA 5600

Expanded license

NSA 4600

N/A

Expanded license

NSA 3600

N/A

Expanded license

NSA 2600

N/A

TZ600

N/A

TZ500/TZ500 W

N/A

TZ400/TZ400 W

N/A

TZ300/TZ300 W

N/A

SOHO W

N/A


1
N/A = not applicable; Included = included with base license

2
Starting with SonicOS 6.2.7.7

You can view system licenses on the System > Licenses page. This page also provides a way to log into MySonicWall. For information about licensing, see Registering and Associating Firewalls on MySonicWall.

When the firewalls in the Active/Active cluster have Internet access, each firewall in the cluster must be individually registered from the SonicOS management interface while you are logged into the individual management IP address of each firewall. This allows the Secondary units to synchronize with the SonicWall licensing server and share licenses with the associated Primary firewalls in each HA pair.

Connecting the HA Ports for Active/Active Clustering

For Active/Active Clustering, you must physically connect the designated HA ports of all units in the Active/Active cluster to the same Layer 2 network.

SonicWall recommends connecting all designated HA ports to the same Layer 2 switch. You can use a dedicated switch or simply use some ports on an existing switch in your internal network. All of these switch ports must be configured to allow Layer 2 traffic to flow freely amongst them.

In the case of a two-unit Active/Active cluster deployment, where the two Cluster Nodes each have only a single firewall, you can connect the HA ports directly to each other using a cross-over cable. No switch is necessary in this case.

The SonicWall Virtual Router Redundancy Protocol (SVRRP) uses this HA port connection to send Cluster Node management and monitoring state messages. SVRRP management messages are initiated on the Master Node, and monitoring information is communicated from every firewall in the cluster.

The HA port connection is also used to synchronize configuration from the Master Node to the other Cluster Nodes in the deployment. This includes firmware or signature upgrades, policies for VPN and NAT, and other configuration.

Connecting Redundant Port Interfaces

You can assign an unused physical interface as a redundant port to a configured physical interface called the “primary interface”. On each Cluster Node, each primary and redundant port pair must be physically connected to the same switch, or preferably, to redundant switches in the network.

* 
NOTE: Because all Cluster Nodes share the same configuration, each node must have the same redundant ports configured and connected to the same switch(es).

To use Active/Active Clustering, you must register all SonicWall firewalls in the cluster on MySonicWall. The two firewalls in each HA pair must also be associated as HA Primary and HA Secondary on MySonicWall. That is, associate the two firewalls in the HA pair for Cluster Node 1, then associate the firewalls in the HA pair for Cluster Node 2, and so on for any other Cluster Nodes.

Configuring Active/Active Clustering

Topics:  

Configuring Active/Active Clustering High Availability

Active/Active Clustering High Availability allows for the configuration of up to four HA cluster nodes for failover and load sharing. Each node can contain either a single firewall or an HA pair.

To configure Active/Active Clustering High Availability:
1
Login to the Primary unit of the Master Cluster Node.
2
Navigate to the High Availability > Settings page.

3
In the Mode drop-down menu, select Active/Active Clustering.
4
Select the Enable Stateful Synchronization option.
5
Select the Generate/Overwrite Secondary Firmware and Settings When Upgrading Firmware option to automatically create a secondary of the firmware and configuration settings when you upload new firmware to the firewall. As the Master Node synchronizes new firmware to other firewalls in the cluster, secondary units are created on those firewalls.
6
Click the HA Devices & Nodes tab to configure the Active/Active cluster information.

7
In the table, enter the serial numbers of the firewalls in each Cluster Node in the appropriate Primary Device Serial # and Secondary Device Serial # fields.
8
Select the rank that Cluster Node 1 holds for each Virtual Group in the Virtual Group X Rank drop-down menus to the right of the serial numbers. By default, Cluster Node 1 is the Owner of Group 1, and typically is ranked as Standby for Group 2.

To exclude an firewall from a cluster, select None for the Virtual Group X Rank.

9
In the second row, select the rank that Cluster Node 2 holds for each Virtual Group in the Virtual Group X Rank drop-down menus to the right of the serial numbers.
10
Click the HA Interfaces tab.

11
Select the interface you want from the Active/Active Cluster Link drop-down menu. This interface is used for transferring data between the two units during Active/Active processing. Only unassigned, available interfaces appear in the list.
12
When finished with all High Availability configuration, click Apply. All settings are synchronized to the Standby unit, and the Standby unit reboots.
13
Go to the High Availability > Monitoring page and follow the steps in Configuring Active/Active Clustering High Availability Monitoring.
14
Go to the High Availability > Advanced page and follow the steps in High Availability > Advanced.
15
Go to the Network > Interfaces page to verify that you have successfully configured the Active/Active interfaces that you want.
16
Go to the High Availability > Status page to verify your settings for Active/Active Clustering.

Configuring Active/Active Clustering High Availability Monitoring

The configuration tasks on the High Availability > Monitoring page are performed on the Primary unit and then are automatically synchronized to the Secondary. These settings only affect the HA pair in the Cluster Node that is selected at the top of the page.

To set the independent LAN management IP addresses and configure physical and/or logical interface monitoring:
1
Login as an administrator to the SonicOS management interface on the Master Node.
2
Navigate to High Availability > Monitoring.
3
At the top right side of the page, select the node to configure from the drop-down menu.
4
Click the Configure icon for an interface on the LAN, such as X0.
5
To enable link detection between the designated HA interfaces on the Primary and Secondary units, leave the Enable Physical Interface Monitoring checkbox selected.

6
In the Primary IP Address field, enter the unique LAN management IP address of the Primary unit.
7
In the Secondary IP Address field, enter the unique LAN management IP address of the Secondary unit.
8
Select the Allow Management on Primary/Secondary IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s Management column in the Monitoring Settings table on the High Availability > Monitoring page. Management is only allowed on an interface when this option is enabled.
9
In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity. Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Secondary firewalls regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target and not the firewalls. But, if one firewall can ping the target and the other firewall cannot, failover occurs to the firewall that can ping the target.

The Primary IP Address and Secondary IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.

10
Click OK.
11
To configure monitoring on any of the other interfaces, repeat the above steps.
12
When finished with all High Availability monitoring configuration for the selected Cluster Node, click Apply.
13
Optionally, select a different Cluster Node, repeat the configuration steps, and then click Apply.

For additional information on verifying the configuration, see Verifying Active/Active Clustering Configuration.

Configuring Active/Active DPI Clustering High Availability

Active/Active DPI Clustering High Availability allows for the configuration of up to four HA cluster nodes for failover and load sharing, where the nodes load balance the application of Deep Packet Inspection (DPI) security services to network traffic. See Active/Active DPI clustering high availability.

Active/Active DPI clustering high availability

For the Cluster Links and the Control Links, each unit in Cluster Node 1 is connected to each unit in the peer node (Cluster Node 2). For best practice, use the same set of interfaces on each unit in each node. (For example, connect X8 in one unit to X8 in the peer unit, and do the same if you are using X9 or X10.) However, there is no restriction on which ports you use.

To configure Active/Active DPI Clustering High Availability:
* 
NOTE: If you have physically connected the Active/Active DPI Interface as described in Physically Connecting Your Firewalls, you are ready to configure Active/Active DPI in the SonicOS management interface.
1
Login to the Primary unit of the Master Cluster Node.
2
Navigate to the High Availability > Settings page.
3
In the Mode drop-down menu, select Active/Active DPI Clustering.
4
The Enable Stateful Synchronization option is automatically enabled for Active/Active DPI Clustering.
5
Select the Generate/Overwrite Secondary Firmware and Settings When Upgrading Firmware checkbox to automatically create a secondary of the firmware and configuration settings when yo upload new firmware to the firewall. As the Master Node synchronizes new firmware to other firewalls in the cluster, secondarys are created on those firewalls.
6
Click the HA Devices tab to configure the Active/Active cluster information.
7
For the HA Secondary option at the top of the tab, select
Internal if the configured secondary firewall is part of the cluster node for this firewall.
External if the configured secondary firewall is part of a different cluster node.
8
In the table, enter the serial numbers of the firewalls in each Cluster Node.
9
Enter the rank that Cluster Node 1 holds for each Virtual Group in the Virtual Group X Rank fields to the right of the serial numbers. By default, Cluster Node 1 is the Owner of Group 1, and typically is ranked as Standby for Group 2. To exclude an firewall from a cluster, select None for the Virtual Group X Rank.
10
In the second row, enter the rank that Cluster Node 2 holds for each Virtual Group in the Virtual Group X Rank fields to the right of the serial numbers.
11
Click the HA Interfaces tab. Select the interface for the HA Control Interface. This option is grayed out if the firewall detects that the interface is already configured.
12
Select the interface for the Active/Active DPI Interface. This option is grayed out if the firewall detects that the interface is already configured.
13
Select the Active/Active DPI Interface. This interface is used for transferring data between the two units during Active/Active DPI processing. Only unassigned, available interfaces appear in the drop-down menu.
14
Select the Active/Active Cluster Link interface.
15
When finished with all High Availability configuration, click Apply. All settings are synchronized to the Standby unit, and the Standby unit reboots.
16
Go to the High Availability > Monitoring page and follow the steps in Configuring Active/Active Clustering High Availability Monitoring.
17
Go to the High Availability > Advanced page and follow the steps in High Availability > Advanced.
18
Go to the Network > Interfaces page to verify that you have successfully configured the Active/Active interfaces that you want.
19
Go to the High Availability > Status page to verify your settings for Active/Active Clustering.

Configuring VPN and NAT with Active/Active Clustering

Extra considerations must be taken when configuring these features in an Active/Active Clustering environment:

Configuring VPN with Active/Active Clustering

VPN policy configuration requires association with a Virtual Group when running in Active/Active Clustering mode. In the VPN Policy dialog (VPN > Settings > Add…), both the Network and Advanced tabs have configuration options for creating this association.

On the Network tab, Virtual Group address objects are available for the Choose local network from list option. These Virtual Group address objects are created by SonicOS when virtual IP addresses are added and are deleted when the virtual IP is deleted.

If creating a VPN Policy for a remote network, Virtual Group address objects may also be available. For example, a custom name Active-Active-Lan-Host-1 in the Choose destination network from list drop-down menu.

On the Advanced tab, select the Virtual Group number for the VPN Policy Group setting. The default is Virtual Group 1.

Configuring a NAT Policy with Active/Active Clustering

When running in Active/Active Clustering mode, NAT policy configuration includes Virtual Group settings. Default NAT policies are created by SonicOS when virtual IP addresses are added and are deleted when the virtual IP is deleted. You can specify a Virtual Group or select Any when creating custom NAT policies; for example, a NAT policy automatically created for Virtual Group 2 on interface X1:

This graphic shows the selections for the Virtual Group option in the Add NAT Policy dialog when creating a custom NAT policy.

Verifying Active/Active Clustering Configuration

This section describes several methods of verifying the correct configuration of Active/Active Clustering and Active/Active DPI. See the following:

Comparing CPU Activity on Firewalls in a Cluster

When Active/Active DPI is enabled on a Stateful HA pair, you can observe a change in CPU utilization on firewalls in the HA pair. CPU activity goes down on the active unit, and goes up on the standby unit.

You can view the CPU utilization on the Multi-Core Monitor. On the active firewall of the Master node, go to the System > Diagnostics page and select Multi-Core Monitor to show the activity of all firewalls in the Active/Active cluster.

When viewing the Multi-Core Monitor on an active unit in the cluster, all firewalls in the cluster are displayed. However, if you log into the individual IP address of an standby unit in the cluster, the Multi-Core Monitor page only displays the core usage for the two firewalls in that particular HA pair.

* 
NOTE: To see the core usage for all firewalls in the cluster, SonicWall recommends viewing the Multi-Core Monitor page on the active unit of the Master node.

Verifying Settings in the High Availability > Status Page

In the Active/Active Clustering Node Status table, the High Availability > Status page provides status for the entire Active/Active cluster and for each Cluster Node in the deployment.

The Active/Active Clustering node status is displayed at the top of the page, and shows values for these settings:

Node Status – Active or Standby for each node in the cluster
Primary A/A LicensedYes or No for each node in the cluster
Secondary A/A LicensedYes or No for each node in the cluster
Virtual Groups Owned – Displays the Virtual Group number owned by each node in the cluster. You can check these values to determine the owner status after a failover.

The High Availability Status table displays the HA settings and status for each node in the cluster.

Additional Parameters in TSR

You can tell that Active/Active DPI is correctly configured on your Stateful HA pair by generating a Tech Support Report on the System > Diagnostics page. The following configuration parameters should appear with their correct values in the Tech Support Report:

Enable Active/Active DPI
Active/Active DPI Interface configuration
To generate a TSR for this purpose:
1
Log into the Stateful HA pair using the shared IP address.
2
Navigate to the System > Diagnostics page.
3
Under Tech Support Report, click Download Report.

Responses to DPI Matches

Responses, or actions, are always sent out from the active unit of the Stateful HA pair running Active/Active DPI when DPI matches are found in network traffic.

* 
NOTE: This does not indicate that all the processing was performed on the active unit.

Deep Packet Inspection discovers network traffic that matches IPS signatures, virus attachments, App Rules policies, and other malware. When a match is made, SonicOS performs an action such as dropping the packet or resetting the TCP connection.

Some DPI match actions inject additional TCP packets into the existing stream. For example, when an SMTP session carries a virus attachment, SonicOS sends the SMTP client a 552 error response code, with a message saying the email attachment contains a virus. A TCP reset follows the error response code and the connection is terminated.

These additional TCP packets are generated as a result of the DPI processing on the standby firewall. The generated packets are sent to the active firewall over the Active/Active DPI Interface, and are sent out from the active firewall as if the processing occurred on the active firewall. This ensures seamless operation and it appears as if the DPI processing was done on the active firewall.

Logging

If Active/Active DPI is enabled and DPI processing on the standby firewall results in a DPI match action as described above, then the action is logged on the active unit of the Stateful HA pair, rather than on the standby unit where the match action was detected. This does not indicate that all the processing was performed on the active unit.

High Availability related log events can be viewed in the Dashboard > Log Monitor page.

IPv6 High Availability Monitoring

For complete information on the SonicOS implementation of IPv6, see IPv6.

IPv6 High Availability (HA) Monitoring is implemented as an extension of HA Monitoring in IPv4. After configuring HA Monitoring for IPv6, both the primary and backup firewalls can be managed from the IPv6 monitoring address, and IPv6 Probing is capable of detecting the network status of HA pairs.

IPv6 and IPv4 radio buttons display in the High Availability > Monitoring page, toggle between the two views for easy configuration of both IP versions:

The IPv6 HA Monitoring configuration page is inherited from IPv4, so the configuration procedures are almost identical. Just select the IPv6 radio button and refer to About High Availability for configuration details.

IPv6 HA Monitoring Considerations

Consider the following when configuring IPv6 HA Monitoring:

In the Edit HA Monitoring dialog, the Enable Physical/Link Monitoring and Override Virtual MAC checkboxes are greyed out because they are layer 2 properties. That is, the properties are used by both IPv4 and IPv6, so you configure them in the IPv4 monitoring page.
The primary/backup IPv6 address must be in the same subnet of the interface, and it can not be same as the global IP and Link-Local-IP of the primary/backup firewall.
If the primary/backup monitoring IP is set to (not ::), then they cannot be the same.
If the Allow Management on Primary/Secondary IPv6 Address checkbox is enabled, then primary/backup monitoring IPv6 addresses cannot be unspecified (that is, ::).
If the Logical/Probe IPv6 Address checkbox is enabled, then the probe IP cannot be unspecified.

Configuring Network DHCP and Interface Settings

When Active/Active Clustering is enabled, the SonicOS internal DHCP server is turned off and cannot be enabled. Networks needing a DHCP server can use an external DHCP server. The SonicOS DHCP server should be disabled in the management interface before enabling Active/Active Clustering, and all DHCP server lease scopes deleted.

On the Network > Interfaces page, you can configure additional virtual IP addresses for interfaces in a Virtual Group, and redundant ports for interfaces.

For information about performing these tasks, see:

Disabling the SonicOS DHCP Server

To disable the SonicOS DHCP server and delete all DHCP server lease scopes:
1
Login to the Primary unit of the Cluster Node and navigate to the Network > DHCP Server page.
2
Clear the Enable DHCP Server checkbox.
3
Under DHCP Server Lease Scopes, select All for the View Style to select all lease scopes in the table.

4
Click the Delete All button.
5
Click OK in the confirmation dialog box.
6
Click Accept at the top of the Network > DHCP Server page.

Configuring Virtual IP Addresses

When Active/Active Clustering is enabled for the first time, the configured IP addresses for the interfaces on that firewall are automatically converted to virtual IP addresses for Virtual Group 1. Thus, Virtual Group 1 will include virtual IP addresses for X0, X1, and any other interfaces which are configured and assigned to a zone.

Active/Active Clustering requires additional configuration of virtual IP addresses for additional Virtual Groups. You can assign multiple virtual IP addresses to each interface, one per Virtual Group. Each additional virtual IP address is associated with one of the other Virtual Groups in the cluster. Each interface can have up to a maximum of four virtual IP addresses. VLAN interfaces can also have up to four virtual IP addresses.

* 
NOTE: A packet cannot be forwarded on an interface if a virtual IP address is not configured on it for the Virtual Group handling that traffic flow.
To configure a virtual IP address on an interface:
1
Login to the Primary unit of the Cluster Node.
2
Navigate to the Network > Interfaces page.
3
In the Interface Settings table, click the Configure icon for the interface you want to configure.
4
In the Edit Interface dialog, type the virtual IP address into the IP Address (Virtual Group X) field, where X is the virtual group number.

* 
NOTE: The new virtual IP address must be in the same subnet as any existing virtual IP address for that interface.
5
Click OK. The configured virtual IP address appears in the Interface Settings table.

Configuring Redundant Ports

Redundant ports can be used along with Active/Active Clustering. You can assign an unused physical interface as a redundant port to a configured physical interface called the “primary interface”. If there is a physical link failure on the primary interface, the redundant interface can continue processing traffic without any interruption. One advantage of this feature is that in case of a physical link failure, there is no need to do a device failover.

You can configure a redundant port on the Advanced tab of the Edit Interface window. The Redundant Port field is only available when Active/Active Clustering is enabled.

* 
NOTE: Because all Cluster Nodes share the same configuration, each node must have the same redundant ports configured and connected to the same switch(es).

For information about physically connecting redundant ports and redundant switches, see the Active/Active Clustering Full Mesh Deployment Technote.

To configure a redundant port for an interface:
1
Login to the Primary unit of the Cluster Node.
2
Navigate to the Network > Interfaces page.
3
In the Interface Settings table, click the Configure icon for the primary interface for which you want to create a redundant port. For example, click the Configure icon for X2.

The Edit Interface dialog displays.

4
Click the Advanced tab.

5
From the Redundant/Aggregate Ports drop-down menu, select Port Redundancy. The options on the dialog change.

6
From the Redundant Port drop-down menu, select the redundant port. Only unused interfaces are available for selection. For example, select X4 for the redundant port.
7
Click 3.

The selected interface will be greyed-out in the Interface Settings table. A note indicates that it is a redundant Port and lists the primary interface. The interface also appears in the Redundant Port field in the Edit Interface dialog of the primary port.

* 
NOTE: The primary and redundant ports must be physically connected to the same switch, or preferably, to redundant switches in the network.
8
On each Cluster Node, replicate the redundant physical connections using the same interface numbers for primary and redundant ports. All Cluster Nodes share the same configuration as the Master node.

Active/Active Clustering Full-Mesh

Topics:  

Active/Active Clustering Full-Mesh Overview

Active/Active Clustering Full-Mesh configuration is an enhancement to the Active/Active Clustering configuration option and prevents any single point of failure in the network. All firewall and other network devices are partnered for complete redundancy. Full-Mesh ensures that there is no single point of failure in your deployment, whether it is a device (firewall/switch/router) or a link. Every device is wired twice to the connected devices. Active/Active Clustering with Full-Mesh provides the highest level of availability possible with high performance.

* 
NOTE: The routers in the firewall’s upstream network should be pre-configured for Virtual Router Redundancy Protocol (VRRP).
Topics:  
About Full Mesh Deployments

Active/Active Clustering Full Mesh configuration is an enhancement to the Active/Active Clustering configuration option and provides the highest level of availability possible with high performance. Full Mesh deployments provide a very high level of availability for the network, because all devices have one or more redundant partners, including routers, switches, and firewalls. Every device is wired twice to the connected devices, so that no single point of failure exists in the entire network. For example, every SonicWall firewall uses redundant ports to connect twice to each networking device.

* 
NOTE: Full Mesh deployments require that Port Redundancy is enabled and implemented.
Benefits of Active/Active Clustering Full Mesh
No Single Point of Failure in the Core Network: In an Active/Active Clustering Full-Mesh deployment, there is no single point of failure in the entire core network, not just for the firewalls. An alternative path for a traffic flow is always available in case there are simultaneous failures of switch, router, firewall on a path, thus providing the highest levels of availability.
Port Redundancy: Active/Active Clustering Full-Mesh utilizes port redundancy in addition to HA redundancy within each Cluster Node, and node level redundancy within the cluster. With port redundancy, a backup link will take over in a transparent manner if the primary port fails. This prevents the need for device level failover.
Redundant Ports and Redundant Switches

Redundant ports can be used along with Active/Active Clustering. If one port should have a fault, the traffic is seamlessly handled through the redundant port without causing an HA or Active/Active failover. A Redundant Port field in the Network > Interfaces > Edit Interface dialog becomes available when Active/Active Clustering is enabled.

When configuring a redundant port, the interface must be unused; that is, not assigned to any zone. The two ports must be physically connected to the same switch, or preferably, to redundant switches in the network.

* 
NOTE: Because all Cluster Nodes shares the same configuration, each node must have the same redundant ports configured and connected to the same switch(es).

While all Cluster Nodes are up and processing traffic normally, redundant ports remain standby and are ready for use if the partner port goes down for any reason. If one Cluster Node goes down, causing an Active/Active failover, the redundant port on the remaining Cluster Node is put to use immediately to handle the traffic for the Virtual Group that was owned by the failed node. This provides load sharing.

For example, say we have a deployment in which Virtual Group 1 is owned by Cluster Node 1 and Virtual Group 2 is owned by Cluster Node 2. The Cluster Nodes are configured with redundant ports, X3 and X4. No traffic is sent on X4 while all nodes are functioning properly. If Cluster Node 2 goes down, Virtual Group 2 is now also owned by Cluster Node 1. At this point, the redundant port X4 begins to be used for load sharing. Virtual Group 1 traffic is sent on X3, while Virtual Group 2 traffic is sent on X4. In a larger deployment, if Cluster Node 1 owns three or four Virtual Groups, traffic is distributed among the redundant ports – traffic for Virtual Groups 1 & 3 is sent on X3, while traffic for Virtual Groups 2 & 4 is sent on X4.

When a redundant switch is configured, SonicWall recommends using a redundant port to connect to it. While it is possible to connect a redundant switch without using a redundant port, this involves complex configuration using probes. A redundant switch can be deployed anywhere in the network depending on the need for high availability. For example, a redundant switch might be deployed on the WAN side if traffic passing through it is business-critical.

WAN-side redundancy shows a deployment that includes redundant routers, switches, and ports on the WAN side, but is not a Full Mesh deployment because the LAN side does not use redundancy.

WAN-side redundancy

Full Mesh is not required when deploying redundant ports or switches, but a Full Mesh deployment includes them. A Full Mesh deployment uses redundant ports on each of the main traffic ports (LAN, WAN, etc.), and uses redundant upstream routers in addition to redundant switches.

For more information about Full Mesh deployments, see the Active/Active Clustering Full Mesh Deployment Technote.

Configuring Active/Active Clustering Full Mesh

This section describes the procedure for setting up a 4-unit Active/Active Cluster Full-Mesh deployment (see Active/Active four-unit cluster full mesh):

The deployments described are examples. Your actual deployment might differ based on the following factors:

Topology/design of your network and the types of network devices you use (such as switches, routers, load balancers)
Level of availability desired
Resource constraints

Active/Active four-unit cluster full mesh

Cabling for Active/Active Full Mesh

This procedure describes the cabling for the deployment illustrated in Active/Active four-unit cluster full mesh.

To physically connect your network devices for a full-mesh deployment:
1
Connect all the HA links of all the firewalls into a port-based VLAN on Switch E.
2
In this setup, X2 is the redundant port of X0. Connect the cables as follows for the X0, X2 ports:
a
Connect CN2-Primary Firewall’s X0 to Switch A and X2 to Switch B.
b
Connect CN2-Backup Firewall’s X0 to Switch A and X2 to Switch B.
c
Connect CN2-Primary Firewall’s X0 to Switch B and X2 to Switch A.
d
Connect CN2-Backup Firewall’s X0 to Switch B and X2 to Switch A.
3
On Switch A and Switch B:
a
Configure all the Switch ports connected to the X0,X2 interfaces to be in the same port-based VLAN.
b
Enable Spanning Tree, but also enable Port Fast (or equivalent command) on the ports connected to the firewalls.
4
X3 is the redundant port of X1. Connect the cables as follows for the X1, X3 ports:
a
Connect CN2-Primary Firewall’s X1 to Switch C and X3 to Switch D.
b
Connect CN2-Backup Firewall’s X1 to Switch C and X3 to Switch D.
c
Connect CN2-Primary Firewall’s X1 to Switch D and X3 to Switch C.
d
Connect CN2-Backup Firewall’s X1 to Switch D and X3 to Switch C.
5
On Switch C and Switch D:
a
Configure all the Switch ports connected to the X1,X3 interfaces to be in the same port-based VLAN.
b
Enable Spanning Tree, but also enable Port Fast (or equivalent command) on the ports connected to the firewalls.
6
Cable Switch A and Switch B together.
7
Cable Switch C and Switch D together.
8
If the Router A and Router B have redundant port support, then connect the Routers to Switches in the same way as we connected the Firewall ports to Switches. That is, connect the primary port on Router A to Switch C and the backup port on Router A to Switch D. Connect the ports in the same way for Router B.
9
If the Routers do not have redundant port support, but have switching support, then you create two ports in the same VLAN on Router A and assign an IP address to the VLAN instead of the port. Then connect one port to Switch C and the other port to Switch D. Do a similar configuration for Router B. (This is the setup shown in Active/Active four-unit cluster full mesh.)
10
Active/Active DPI is used along with Active/Active Clustering. Ports X6 and X7 are the two HA data ports for redundancy and load-sharing of offloaded traffic from Active to Standby firewalls. Perform the following cabling (X6,X7 ports and cabling have not been shown in Active/Active four-unit cluster full mesh for brevity):
a
Connect X6 of CN1-Primary to X6 of CN1-Backup with a Cross-over cable.
b
Connect X7 of CN1-Primary to X7 of CN1-Backup with a Cross-over cable.
c
Connect X6 of CN2-Primary to X6 of CN2-Backup with a Cross-over cable.
d
Connect X7 of CN2-Primary to X7 of CN2-Backup with a Cross-over cable.

Configuring Active/Active Cluster Firewalls

Topics:  
Configuration Procedure
To configure the Active/Active Cluster firewalls:
1
Shut down all firewalls except the CN1-Primary unit.
2
On the High Availability > Settings page:
a
Choose Active/Active Clustering from the Mode drop-down menu.
b
Select the Enable Stateful Synchronization checkbox.
c
Click the HA Devices & Nodes tab.
d
Enter the serial numbers of the Cluster Node Primary and Secondary devices in the appropriate Primary Device Serial # and Secondary Device Serial # fields.
e
For CN1, select Owner from the Virtual Group 1 Rank drop-down menu and Standby for Virtual Group 2 Rank drop-down menu.
f
For CN2, select Owner from the Virtual Group 1 Rank drop-down menu and Standby for Virtual Group 2 Rank drop-down menu.
g
Enable Active/Active DPI with X6 and X7 as the two HA data ports.
h
Click Apply.
3
On the Network > Interfaces page:
a
Add the Virtual Group (VG) IP addresses for both the X0 and X1 interfaces.
b
Add the redundant port configuration (X2 as redundant port of X0, X3 as redundant port of X1).
4
On the High Availability > Monitoring page, add the monitoring/management IP addresses either on X0 or X1 for each unit in the cluster.
5
Turn on all the other firewalls. A complete synchronization of the configuration is made from the CN1-Primary to all other firewalls.
6
Login to each firewall unit using the dedicated monitoring/management address and do the following:
a
Register the firewall on MySonicWall.
b
Synchronize the licenses with MySonicWall.
Testing for No Point of Failure

After the above deployment is connected and configured, CN1 owns Virtual Group1 (VG1), and CN2 owns Virtual Group 2 (VG2).

Configure the VG1 IP address on X0 as the gateway for a certain set of traffic flows and the VG2 IP address on X0 as the gateway for other sets of traffic flows. The network administrator can use different methods to accomplish this. One way is to use a smart DHCP server which distributes the gateway allocation to the PCs on the directly connected client network. Another method is by using policy based routes on a downstream router.

When the traffic setup is done, both Cluster Nodes will actively process network traffic. Now we can test for no single point of failure on all devices and links with the following steps:

1
Device Failures: Traffic should continue to flow through both Cluster Nodes in each of the following device failures:
a
Power down Switch A while Switch B is up and ready.
b
Power down Switch B while Switch A is up and ready.
c
Restart the Active unit in CN1 from the SonicOS management interface while the Standby unit in CN1 is up and ready (this scenario is similar to a software failure on the CN1-Active unit). Note that there will be a Stateful HA failover in this case.
d
Shut down the CN1-Active unit while the CN1-Standby unit is up and ready (this scenario is similar to a hardware failure on the CN1-Active unit).
* 
NOTE: There will be a Stateful HA failover in this case.
e
Repeat Step c and Step d for CN2.
f
Shut down Router A while Router B is up and ready.
g
Shut down Router B while Router A is up and ready.
2
Link Failures: Traffic should continue to flow in each of the following link failures:
a
On each of the Active firewalls in the Cluster Node, disconnect the X0 cable while X2 is connected.
b
On each of the Active firewalls in the Cluster Node, disconnect the X1 cable while X3 is connected.
c
Disconnect the primary link from upstream switches to the router which is the Active virtual router.
d
Disconnect X6, the Active-Active DPI HA data interface.

Configuring Active/Active Cluster Full-Mesh 2-Unit Deployment

In previous sections we discussed the Active/Active Cluster Full-Mesh with four firewall units. Optionally, you can deploy Active/Active Cluster Full-Mesh with two firewall units where each CN consists of only one firewall (no HA backup). However, such a setup has these limitations:

Failover is not stateful and existing connections need to be re-built.
If the traffic on each unit is greater than 50% of the capacity of the single unit at the time of failover, then after the failover, the traffic in excess of 50% is dropped.

The procedure for the 2-unit Full-Mesh is similar to the procedure for the 4-unit Full-Mesh, with these exceptions:

The steps involving the Backup unit in each node do not apply.
The steps for configuring Stateful Sync and Active-Active DPI do not apply.
There is no Switch required for connecting the HA ports (as there are only two, they can be directly connected with a cross-over cable).

Displaying High Availability Status

High Availability > Status

Topics:  

Active/Standby High Availability Status

The High Availability Status table on the High Availability > Status page displays the current status of the HA Pair. If the Primary SonicWall is Active, the first line in the table indicates that the Primary SonicWall is currently Active.

It is also possible to check the status of the Secondary SonicWall by logging into the unique LAN IP address of the Secondary SonicWall. If the Primary SonicWall is operating normally, the status indicates that the Secondary SonicWall is currently Standby. If the Secondary has taken over for the Primary, the High Availability Status table indicates that the Secondary is currently Active.

In the event of a failure in the Primary SonicWall, you can access the management interface of the Secondary SonicWall at the Primary SonicWall virtual LAN IP address or at the Secondary SonicWall LAN IP address. When the Primary SonicWall restarts after a failure, it is accessible using the unique IP address created on the High Availability > Monitoring page. If preempt mode is enabled, the Primary SonicWall becomes the Active firewall and the Secondary firewall returns to Standby status.

Topics:  

High Availability Status

Status – Indicates the HA state of the Primary firewall. The possible values are:
Primary Active – Indicates that the Primary HA appliance is in the ACTIVE state.
Primary Standby – Indicates that this appliance is in the standby state.
Primary Disabled – Indicates that High Availability has not been enabled in the management interface of this appliance.
Primary not in a steady state – Indicates that HA is enabled and the appliance is neither in the ACTIVE nor the standby state.
Primary State - Indicates the current state of the Primary appliance as a member of an HA Pair. The Primary State field is displayed on both the Primary and the Secondary appliances. The possible values are:
ACTIVE – Indicates that the Primary unit is handling all the network traffic except management/monitoring/licensing traffic destined to the standby unit.
standby – Indicates that the Primary unit is passive and is ready to take over on a failover.
ELECTION – Indicates that the Primary and Secondary units are negotiating which should be the ACTIVE unit.
SYNC – Indicates that the Primary unit is synchronizing settings or firmware to the Secondary.
ERROR – Indicates that the Primary unit has reached an error condition.
REBOOT – Indicates that the Primary unit is rebooting.
NONE – When viewed on the Primary unit, NONE indicates that HA is not enabled on the Primary. When viewed on the Secondary unit, NONE indicates that the Secondary unit is not receiving heartbeats from the Primary unit.
Secondary State - Indicates the current state of the Secondary appliance as a member of an HA Pair. The Secondary State field is displayed on both the Primary and the Secondary appliances. The possible values are:
ACTIVE – Indicates that the Secondary unit is handling all the network traffic except management/monitoring/licensing traffic destined to the standby unit.
standby – Indicates that the Secondary unit is passive and is ready to take over on a failover.
ELECTION – Indicates that the Secondary and Primary units are negotiating which should be the ACTIVE unit.
SYNC – Indicates that the Secondary unit is synchronizing settings or firmware to the Primary.
ERROR – Indicates that the Secondary unit has reached an error condition.
REBOOT – Indicates that the Secondary unit is rebooting.
NONE – When viewed on the Secondary unit, NONE indicates that HA is not enabled on the Secondary. When viewed on the Primary unit, NONE indicates that the Primary unit is not receiving heartbeats from the Secondary unit.
Active Up Time - Indicates how long the current Active firewall has been Active, since it last became Active. This line only displays when High Availability is enabled. If failure of the Primary SonicWall occurs, the Secondary SonicWall assumes the Primary SonicWall LAN and WAN IP addresses. There are three main methods, described in the following sections, to check the status of the High Availability Pair:
High Availability > Status page
Email Alerts
View Log
Node Status - Indicates if Active/Active Clustering is enabled or is not enabled.
Found Peer - Indicates if the Primary unit has discovered the Secondary unit. Possible values are Yes and No.
Settings Synchronized - Indicates if HA settings are synchronized between the Primary and Secondary units. Possible values are Yes and No.
Stateful HA Synchronized - Indicates if stateful synchronization settings are synchronized between the Primary and Secondary units. Possible values are Yes and No.

High Availability Configuration

HA Mode - One method to determine which SonicWall is Active is to check the HA Settings Status indicator on the High Availability > Settings page. If the Primary SonicWall is Active, the first line in the page indicates that the Primary SonicWall is currently Active. It is also possible to check the status of the Secondary SonicWall by logging into the LAN IP address of the Secondary SonicWall. If the Primary SonicWall is operating normally, the status indicates that the Secondary SonicWall is currently Standby. If the Secondary has taken over for the Primary, the status indicates that the Secondary is currently Active. In the event of a failure in the Primary SonicWall, you can access the management interface of the Secondary SonicWall at the Primary SonicWall LAN IP address or at the Secondary SonicWall LAN IP address. When the Primary SonicWall restarts after a failure, it is accessible using the third IP address created during configuration. If preempt mode is enabled, the Primary SonicWall becomes the Active firewall and the Secondary firewall returns to Standby status.
HA Control Link – Indicates the port, speed, and duplex settings of the HA link, such as HA 1000 Mbps full-duplex, when two firewalls are connected over their specified HA interfaces. When High Availability is not enabled, the field displays Disabled.
HA Data Link – Indicates the port, speed, and duplex settings of the HA link, such as HA 1000 Mbps full-duplex, when two firewalls are connected over their specified HA interfaces. When High Availability is not enabled, the field displays Disabled.
High Availability Licenses
Primary Stateful HA Licensed - Indicates if the Primary appliance has a stateful HA license. Possible values are Yes or No.
Secondary Stateful HA Licensed - Indicates if the Secondary appliance has a stateful HA license. Possible values are Yes or No. Note that the Stateful HA license is shared with the Primary, but that you must access mysonicwall.com while logged into the LAN management IP address of the Secondary unit in order to synchronize with the SonicWall licensing server.
Primary Active/Active Licensed - Indicates if the Primary appliance has a Active/Active license. Possible values are Yes or No.

Active/Active High Availability Status

The High Availability > Status page provides status for the entire Active/Active cluster and for each Cluster Node in the deployment. The status for the Active/Active cluster is displayed in the upper table, and status for the each Cluster Node is displayed in the lower table.

For additional information on High Availability status and verifying the configuration, see Verifying Active/Active Clustering Configuration.

 

Configuring High Availability

* 
IMPORTANT: High Availability cannot be used along with PortShield except with the SonicWall X‑Series Solution. Before configuring HA, remove any existing PortShield configuration from the Network > PortShield Groups page. For using HA with PortShield, see SonicOS Support of X‑Series Switches and the SonicWall X‑Series Solution Deployment Guide.

High Availability > Settings

You configure High Availability (HA) on he High Availability > Settings page:

* 
NOTE: For more information on High Availability, see About High Availability and Active/Standby and Active/Active DPI Prerequisites. If your Active/Active Clustering environment will use VPN or NAT, see Configuring VPN and NAT with Active/Active Clustering after you have finished the Active/Active configuration.

Configuring Active/Standby High Availability Settings

The configuration tasks on the High Availability > Settings page are performed on the Primary firewall and then are automatically synchronized to the Secondary firewall.

To configure Active/Standby:
1
Navigate to High Availability > Settings.

2
In the Mode drop-down menu, select Active/Standby.
3
Select Enable Stateful Synchronization. This option is not selected by default.

When Stateful High Availability is not enabled, session state is not synchronized between the Primary and Secondary firewalls. If a failover occurs, any session that had been active at the time of failover needs to be renegotiated.

A confirmation message displays.

4
Click OK.
5
To back up the settings when you upgrade the firmware version, select Generate/Overwrite Backup Firmware and Settings When Upgrading Firmware. This option is not selected by default.
6
To configure the High Availability Pair so that the Primary firewall takes back the Primary role when it restarts after a failure, select Enable Preempt Mode. This option is not selected by default.

Preempt mode is recommended to be disabled when enabling Stateful High Availability, because preempt mode can be over-aggressive about failing over to the Secondary firewall.

7
Select the Enable Virtual MAC checkbox to allow the Primary and Secondary firewalls to share a single MAC address. This greatly simplifies the process of updating network ARP tables and caches when a failover occurs. This option is not selected by default.
* 
NOTE: If PPPoE Unnumbered is configured, you must select Enable Virtual MAC.

Only the switch to which the two firewalls are connected needs to be notified. All outside devices continue to route to the single shared MAC address.

8
Click the HA Devices tab to configure the Secondary firewall serial number. The Serial Number for the Primary Device is displayed, and the field is dimmed and cannot be edited.

9
Enter the Serial Number of the Secondary Device.
10
Click the HA Interfaces tab.

11
Select the interface for the HA Control Interface. This option is dimmed and the interface displayed if the firewall detects that the interface is already configured.
12
Select the interface for the Active/Active DPI Interface. This option is dimmed and the interface displayed out if the firewall detects that the interface is already configured.
13
When finished with all High Availability configuration, click Apply. All settings are synchronized to the Secondary firewall, and the Secondary firewall reboots.

Configuring HA with Dynamic WAN Interfaces

The configuration tasks on the High Availability > Settings page are performed on the Primary firewall and then are automatically synchronized to the Secondary.

To configure HA with a dynamic WAN interface:
1
Navigate to Network > Interfaces.
2
Configure a WAN interface as PPPoE, as described in Configuring a WAN Interface.
3
Navigate to High Availability > Settings.

4
Ensure the Enable Stateful Synchronization checkbox is not selected. This option is not selected by default.
5
Ensure the Enable Preempt Mode checkbox is not selected. This option is not selected by default.
6
Select the Enable Virtual MAC checkbox. This option is not selected by default.
7
Configure the HA Devices and HA Interfaces tabs as described in Configuring Active/Standby High Availability Settings.
8
Click Apply.
9
Navigate to High Availability > Monitoring.

10
Click the Configure icon for the PPPoE interface. The Edit HA Monitoring dialog displays.

11
Select the Enable Physical/Link Monitoring checkbox. This option is not selected by default.
12
Ensure the Primary IPv4 Address and Secondary IPv4 Address fields are set to 0.0.0.0.
13
Ensure none of the other checkboxes are selected.
14
Click OK.

Configuring Active/Active DPI High Availability Settings

The configuration tasks on the High Availability > Settings page are performed on the Primary firewall and then are automatically synchronized to the Secondary.

To configure Active/Active DPI:
1
Navigate to High Availability > Settings.

2
In the Mode drop-down menu, select Active/Active DPI.
3
The Enable Stateful Synchronization option is automatically enabled for Active/Active DPI, and the option is dimmed.
4
To back up the settings when you upgrade the firmware version, select Generate/Overwrite Backup Firmware and Settings When Upgrading Firmware. This option is not selected by default.
5
Under normal conditions, the Enable Preempt Mode option should be disabled for Active/Active DPI. This option is not selected by default.
* 
NOTE: This option instructs the Primary firewall to take back the Primary role when it restarts after a failure; thus, this option only applies to Active/Standby configurations.
6
Select the Enable Virtual MAC checkbox to allow both firewalls in the HA pair to share a single MAC address. This greatly simplifies the process of updating network ARP tables and caches when a failover occurs. Only the switch to which the two firewalls are connected needs to be notified. All outside devices continue to route to the single shared MAC address. This option is not selected by default.
7
Click the HA Devices tab. The Serial Number for the Primary Device is displayed, and the field is dimmed and cannot be edited.

8
Enter the Serial Number of the Secondary Device.
9
Click the HA Interfaces tab.

10
Select the interface for the HA Control Interface. This option is dimmed and the interface displayed if the firewall detects that the interface is already configured.
11
Select the interface number for the HA Data Interface. This option is dimmed and the interface displayed if the firewall detects that the interface is already configured.
12
Select the interface number for the Active/Active DPI Interface. This option is dimmed and the interface displayed if the firewall detects that the interface is already configured.

This interface is used for transferring data between the two firewalls during Active/Active DPI processing. Only unassigned, available interfaces appear in the drop-down menu. The connected interfaces must be the same number on both appliances, and must initially appear as unused, unassigned interfaces in the Network > Interfaces page. For example, you could connect X5 on the Primary unit to X5 on the Secondary if X5 is an unassigned interface. After enabling Active/Active DPI, the connected interface will have a Zone assignment of HA Data-Link.

13
When finished with all High Availability configuration, click Apply. All settings are synchronized to the Standby firewall, and the Standby firewall reboots.

 

Fine Tuning High Availability

High Availability > Advanced

The High Availability > Advanced page provides the ability to fine-tune the High Availability configuration as well as synchronize setting and firmware among the High Availability firewalls. The High Availability > Advanced page is identical for both Active/Standby and Active/Active configurations.

The Heartbeat Interval and Failover Trigger Level (missed heartbeats) settings apply to both the SVRRP heartbeats (Active/Active Clustering heartbeat) and HA heartbeats. Other settings on High Availability > Advanced page apply only to the HA pairs within the Cluster Nodes.

* 
NOTE: For more information on High Availability, see About High Availability and Active/Standby and Active/Active DPI Prerequisites.

Configuring Advanced High Availability

To configure advanced settings:
1
Login as an administrator to the SonicOS management interface on the Master Node, that is, on the Virtual Group1 IP address (on X0 or another interface with HTTP management enabled).
2
Navigate to High Availability > Advanced.

3
Optionally adjust the Heartbeat Interval to control how often the firewalls in the Active/Active cluster communicate. This setting applies to all units in the Active/Active cluster. The default is 1,000 milliseconds (1 second), the minimum value is 1,000 milliseconds, and the maximum is 300000.
* 
NOTE: SonicWall recommends that you set the Heartbeat Interval to at least 1000.

You can use higher values if your deployment handles a lot of network traffic. Lower values may cause unnecessary failovers, especially when the firewall is under a heavy load.

This timer is linked to the Failover Trigger Level (missed heartbeats) timer.

4
Set the Failover Trigger Level to the number of heartbeats that can be missed before failing over. This setting applies to all units in the Active/Active cluster. The default is 5, the minimum is 4, and the maximum is 99.

This timer is linked to the Heartbeat Interval timer. If the Failover Trigger Level is set to 5 and the Heartbeat Interval is set to 10000 milliseconds (10 seconds), it takes 50 seconds without a heartbeat before a failover is triggered.

5
Set the Probe Interval to the interval, in seconds, between probes sent to specified IP addresses to monitor that the network critical path is still reachable. This interval is used in logical monitoring for the local HA pair. The default is 20 seconds, and the allowed range is 5 to 255 seconds.
* 
TIP: SonicWall recommends that you set the interval for at least 5 seconds.

You can set the Probe IP Address(es) on the High Availability > Monitoring page. See High Availability > Monitoring.

6
Set the Probe Count to the number of consecutive probes before SonicOS concludes that the network critical path is unavailable or the probe target is unreachable. This count is used in logical monitoring for the local HA pair. The default is 3, and the allowed range is 3 to 10.
7
Set the Election Delay Time to the number of seconds the Primary firewall waits to consider an interface up and stable. The default is 3 seconds, the minimum is 3 seconds, and the maximum is 255 seconds.
* 
TIP: This timer is useful with switch ports that have a spanning-tree delay set.
8
Set the Dynamic Route Hold-Down Time to the number of seconds the newly-active firewall keeps the dynamic routes it had previously learned in its route table. The default value is 45 seconds, the minimum is 0 seconds, and the maximum is 1200 seconds (20 minutes). .
* 
NOTE: The Dynamic Route Hold-Down Time setting is displayed only when the Advanced Routing option is selected on the Network > Routing page.
* 
TIP: In large or complex networks, a larger value may improve network stability during a failover

This setting is used when a failover occurs on a High Availability pair that is using either RIP or OSPF dynamic routing. During this time, the newly-active appliance relearns the dynamic routes in the network. When the Dynamic Route Hold-Down Time duration expires, SonicOS deletes the old routes and implements the new routes it has learned from RIP or OSPF.

9
If you want Failover to occur only when ALL aggregate links are down, select the Active/Standby Failover only when ALL aggregate links are down checkbox.
10
To have the appliances synchronize all certificates and keys within the HA pair. select the Include Certificates/Keys checkbox. This option is selected by default.
11
(Optional) To synchronize the SonicOS preference settings between your primary and secondary HA firewalls, click the Synchronize Settings button.
12
(Optional) To synchronize the firmware version between your primary and secondary HA firewalls, click the Synchronize Firmware button.
13
(Optional) To test the HA failover functionality is working properly by attempting an Active/Standby HA failover to the secondary firewall, click the Force Active/Standby Failover button.
14
When finished with all High Availability configuration, click Accept. All settings are synchronized to the Secondary unit or to other units in the cluster.

 

Monitoring High Availability

High Availability > Monitoring

On the High Availability > Monitoring page, you can configure independent management IP addresses for each unit in the HA Pair, using either LAN or WAN interfaces. You can also configure physical/link monitoring and logical/probe monitoring. For more information about the HA Monitoring settings, see About High Availability and Active/Active Clustering.

Active/Standby High Availability Monitoring

To set the independent LAN management IP addresses and configure physical and/or logical interface monitoring:
1
Login as an administrator to the SonicOS user interface on the Primary SonicWall.
2
In the left navigation pane, navigate to High Availability > Monitoring.

3
Click the Configure icon for an interface on the LAN, such as X0.

4
To enable link detection between the designated HA interfaces on the Primary and Secondary units, leave the Enable Physical Interface Monitoring checkbox selected.
5
In the Primary IPv4 Address field, enter the unique LAN management IP address of the Primary unit.
6
In the Secondary IPv4 Address field, enter the unique LAN management IP address of the Secondary unit.
7
Select the Allow Management on Primary/Secondary IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s Management column in the Monitoring Settings table on the High Availability > Monitoring page. Management is only allowed on an interface when this option is enabled.
8
In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity. Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.)

The Primary and Secondary firewall s regularly ping this probe IP address. If both successfully ping the target, no failover occurs. If neither successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the firewalls. But, if one firewall can ping the target but the other cannot, failover occurs to the firewall that can ping the target.

The Primary IPv4 Address and Secondary IPv4 Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.

9
Optionally, to manually specify the virtual MAC address for the interface, select Override Virtual MAC and enter the MAC address in the field. The format for the MAC address is six pairs of hexadecimal numbers separated by colons, such as A1:B2:C3:d4:e5:f6.
* 
IMPORTANT: Care must be taken when choosing the Virtual MAC address to prevent configuration errors.

When the Enable Virtual MAC checkbox is selected on the High Availability> Advanced page, the SonicOS firmware automatically generates a Virtual MAC address for all interfaces. Allowing the SonicOS firmware to generate the Virtual MAC address eliminates the possibility of configuration errors and ensures the uniqueness of the Virtual MAC address, which prevents possible conflicts.

10
Click OK.
11
To configure monitoring on any of the other interfaces, repeat Step 3 through Step 10 for each interface.
12
When finished with all High Availability configuration, click Accept. All settings are synchronized to the Secondary unit automatically.