Hardware_Failover_haMonitoring
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 HA Monitoring on page 776.
Active/Standby High Availability Monitoring
Configuring Active/Standby High Availability Monitoring
To set the independent LAN management IP addresses and configure physical and/or logical interface monitoring, perform the following steps:
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.
Click the Configure icon for an interface on the LAN, such as X0.
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 IP Address field, enter the unique LAN management IP address of the Primary unit.
6. In the Secondary IP 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 appliances will 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 appliance can ping the target but the other appliance cannot, failover will occur to the appliance 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.
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. 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 the above steps.
12. When finished with all High Availability configuration, click Accept. All settings will be synchronized to the Standby unit automatically.
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.
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.
This section contains the following subsections:
• Active/Active Clustering Overview on page 795
• Active/Active Clustering Prerequisites on page 807
• Configuring Active/Active Clustering High Availability on page 809
• Configuring Active/Active DPI Clustering High Availability on page 814
• Configuring VPN and NAT with Active/Active Clustering on page 816
• Configuring Network DHCP and Interface Settings on page 822
• Active/Active Clustering Full-Mesh on page 826
Active/Active Clustering Overview
This section provides an introduction to the Active/Active Clustering feature. 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.
This section contains the following subsections:
• “Example: Active/Active Clustering – Four-Unit Deployment” on page 797
• “Example: Active/Active Clustering – Two-Unit Deployment” on page 798
• Benefits of Active/Active Clustering on page 799
• How Does Active/Active Clustering Work? on page 799
• Feature Support Information with Active/Active Clustering on page 805
Example: Active/Active Clustering – Four-Unit Deployment
This diagram shows a four-unit cluster. Each Cluster Node contains one HA pair. The designated HA ports of all four appliances 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.
Figure 54:23 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
This diagram shows a two-unit cluster. In a two-unit cluster, HA pairs are not used. Instead, each Cluster Node contains a single appliance. The designated HA ports on the two appliances 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 appliance in the cluster. The HA port connection is also used for configuration synchronization between Cluster Nodes.
Figure 54:24 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. See the following sections for descriptions of these new concepts and changes to existing functionality:
• About Cluster Nodes on page 799
• About the Cluster on page 799
• About Virtual Groups on page 801
• About DPI with Active/Active Clustering on page 803
• About High Availability Monitoring with Active/Clustering on page 803
• About Full Mesh Deployments on page 826
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.
All devices in the Cluster must be of same product model and be running the same firmware version.
Within the cluster, all units are connected and communicating with each other. 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.
The About Failover on page 803 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 will include eight firewalls.
Figure 54:25 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. Table 20 lists the allowed actions for active firewalls of Non-Master nodes and standby firewalls in the cluster.
Table 20 Administrative Actions Allowed
|
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 will include virtual IP addresses for X0, X1, and any other interfaces which 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 will own 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.
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.
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 will have 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 will 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-appliance 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 appliance 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.
Feature Support Information with Active/Active Clustering
The following sections provides feature support information about Active/Active Clustering:
• Backward Compatibility on page 805
• SonicPoint Compatibility on page 805
• WAN Load Balancing Compatibility on page 805
• Routing Topology and Protocol Compatibility on page 806
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
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.
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 will be advertised by all other nodes.
The OSPF router-ID of each Cluster Node must be unique and will be 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 will be 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 will be 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 as follows:
– 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, will run on the RIP-enabled interfaces of each Cluster Node. From a routing perspective, all Cluster Nodes will appear as parallel routers with the virtual IP address of the Cluster Node’s interface. In general, any network advertised by one node will be advertised by all other nodes.
BGP Support
BGP is supported in clusters, and will also appear 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 will be 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.
Asymmetric Routing Issues In Cluster Configurations
Any network appliance that performs deep packet inspection or stateful firewall activity must “see” all packets associated with a packet flow. This is in contrast to traditional IP routing in which each packet in a flow may technically be forwarded along a different path as long as it arrives at it’s intended destination – the intervening routers do not have to see every packet. Today’s routers do attempt to forward packets with a consistent next-hop for each packet flow, but this applies only to packets forwarded in one direction. Routers make no attempt to direct return traffic to the originating router. This IP routing behavior presents problems for a firewall cluster because the set of Cluster Nodes all provide a path to the same networks. Routers forwarding packets to networks through the cluster may choose any of the Cluster Nodes as the next-hop. The result is asymmetric routing, in which the flow of packets in one direction go through a node different than that used for the return path. This will cause traffic to be dropped by one or both Cluster Nodes since neither is “seeing” all of the traffic from the flow.
There are two ways to avoid asymmetric routing paths:
1. Engineer all networks and routers connected to the cluster such that packet forwarding will always result in symmetric paths in respect to the virtual IP addresses used in the cluster.
2. Create a full mesh configuration of NAT rules in the cluster so every interface-pair has a NAT rule which replaces the source IP address in the packet with the virtual IP of the egress interface. These rules should be the same as the default rules created between trusted and non-trusted zoned interfaces. When the full mesh NAT rules are in place, the forward and reverse paths of flows transiting the cluster will always flow through the same Cluster Node (or the current owner of the Cluster Node’s primary virtual IP addresses).
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 on page 780.
For Active/Active Clustering, additional physical connections are required:
• Active/Active Cluster Link—Each Active/Active cluster link must be a 1GB interface
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 on page 789 section.
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 appliance, 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 appliance 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 appliances in the cluster on MySonicWALL. The two appliances in each HA pair must also be associated as HA Primary and HA Secondary on MySonicWALL. That is, associate the two appliances in the HA pair for Cluster Node 1, then associate the appliances in the HA pair for Cluster Node 2, and so on for any other Cluster Nodes.
The following table shows the licensing requirements for Active/Active Clustering and other High Availability features.
|
Configuring Active/Active Clustering
This section contains the following subsections:
• Configuring Active/Active Clustering High Availability on page 809
• “Configuring Active/Active Clustering High Availability Monitoring” on page 812
• Configuring Active/Active DPI Clustering High Availability on page 814
• Configuring VPN and NAT with Active/Active Clustering on page 816
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 appliance or an HA pair.
To configure Active/Active Clustering High Availability:
1. Login to the Primary unit of the Master Cluster Node and navigate to the High Availability > Settings page. The General tab is displayed.
2. In the Mode pull-down menu, select Active/Active Clustering.
3. Select the Enable Stateful Synchronization option.
4. 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 appliance. As the Master Node synchronizes new firmware to other appliances in the cluster, secondary units are created on those appliances.
5. Click the HA Devices & Nodes tab to configure the Active/Active cluster information.
6. In the table, enter the serial numbers of the appliances in each Cluster Node.
7. 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 appliance from a cluster, select None for the Virtual Group X Rank.
8. 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.
9. Click the HA Interfaces tab. Select the interface you want for the Active/Active Cluster Link interface. This interface will be used for transferring data between the two units during Active/Active processing. Only unassigned, available interfaces appear in the list.
10. When finished with all High Availability configuration, click Apply. All settings will be synchronized to the Standby unit, and the Standby unit will reboot.
11. Go to the High Availability > Monitoring page and follow the steps in Configuring Active/Active Clustering High Availability Monitoring on page 812.
12. Go to the High Availability > Advanced page and follow the steps in High Availability > Advanced on page 792.
13. Go to the Network > Interfaces page to verify that you have successfully configured the Active/Active interfaces that you want.
14. 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, perform the following steps:
1. Login as an administrator to the SonicOS management interface on the Master Node.
2. In the left navigation pane, navigate to High Availability > Monitoring.
3. At the top right side of the page, select the node to configure from the drop-down list.
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 appliances will 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 appliance can ping the target and the other appliance cannot, failover will occur to the appliance 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. Then select a different Cluster Node and repeat the configuration steps and then click Apply.
For additional information on verifying the configuration, see “Verifying Active/Active Clustering Configuration” on page 819.
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.
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, etc. However, there is no restriction on which ports you use.
Figure 54:26 Active/Active DPI Clustering High Availability
To configure Active/Active DPI Clustering High Availability:
1. Login to the Primary unit of the Master Cluster Node and navigate to the High Availability > Settings page. The General tab is displayed.
If you have physically connected the Active/Active DPI Interface as described in Physically Connecting Your Appliances on page 781, you are ready to configure Active/Active DPI in the SonicOS management interface.
2. In the Mode pull-down menu, select Active/Active DPI Clustering.
3. The Enable Stateful Synchronization option is automatically enabled for Active/Active DPI Clustering.
4. 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 appliance. As the Master Node synchronizes new firmware to other appliances in the cluster, secondarys will be created on those appliances.
5. Click the HA Devices tab to configure the Active/Active cluster information.
6. For the HA Secondary option at the top of the tab, select Internal if the configured secondary appliance is part of the cluster node for this appliance. Select External if the configured secondary appliance is part of a different cluster node.
7. In the table, enter the serial numbers of the appliances in each Cluster Node.
8. 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 appliance from a cluster, select None for the Virtual Group X Rank.
9. 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.
10. Click the HA Interfaces tab. Select the interface for the HA Control Interface. This option is grayed out if the appliance detects that the interface is already configured.
11. Select the interface for the Active/Active DPI Interface.This option is grayed out if the appliance detects that the interface is already configured.
12. Select the Active/Active DPI Interface. This interface will be used for transferring data between the two units during Active/Active DPI processing. Only unassigned, available interfaces appear in the list.
13. Select the Active/Active Cluster Link interface.
14. When finished with all High Availability configuration, click Apply. All settings will be synchronized to the Standby unit, and the Standby unit will reboot.
15. Go to the High Availability > Monitoring page and follow the steps in Configuring Active/Active Clustering High Availability Monitoring on page 812.
16. Go to the High Availability > Advanced page and follow the steps in High Availability > Advanced on page 792.
17. Go to the Network > Interfaces page to verify that you have successfully configured the Active/Active interfaces that you want.
18. 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 the following features in an Active/Active Clustering environment:
• Configuring VPN with Active/Active Clustering on page 816
• Configuring a NAT Policy with Active/Active Clustering on page 818
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 window, both the Network and Advanced tabs have new 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, this graphic shows one with the custom name Active-Active-Lan-Host-1.
On the Advanced tab, you can 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. This graphic shows the 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 window 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 Appliances in a Cluster on page 819
• Verifying Settings in the High Availability > Status Page on page 819
• Additional Parameters in TSR on page 820
• Responses to DPI Matches on page 820
Comparing CPU Activity on Appliances in a Cluster
When Active/Active DPI is enabled on a Stateful HA pair, you can observe a change in CPU utilization on appliances 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 appliances 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
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 the following settings:
• Node Status – Active or Standby for each node in the cluster
• Primary A/A Licensed – Yes or No for each node in the cluster
• Secondary A/A Licensed – Yes 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 Active/Active Clustering Node Status table is shown below.
In the lower section of the page, shown below, the High Availability Status table displays the HA settings and status for each node in the cluster.
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, 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 that 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.
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 Log > View page.
