Hardware Failover And Lan Port Disconnect Transitions - SonicWALL SonicPoint Administrator's Manual

As part of the provisioning process, SonicOS will assign the discovered SonicPoint device a unique
name, and it will record its MAC address and the interface and Zone on which it was discovered. It
can also automatically assign the SonicPoint an IP address, if so configured, so that the SonicPoint
can communicate with an authentication server for WPA-EAP support. SonicOS will then use the
profile associated with the relevant Zone to configure the 2.4GHz and 5GHz radio settings.
Modifications to profiles will not affect units that have already been provisioned and are in an
operational state. Configuration changes to operational SonicPoint devices can occur in two ways:
• through manual configuration changes: Appropriate when a single, or a small set of changes
are to be affected, particularly when that individual SonicPoint requires settings that are different
from the profile assigned to its Zone.
• through un-provisioning: Deleting a SonicPoint unit effectively un-provisions the unit, or clears
its configuration and places it into a state where it will automatically engage the provisioning
process anew with its peer SonicOS device. This technique is useful when the profile for a Zone is
updated or changed, and the change is set for propagation. It can be used to update firmware on
SonicPoints, or to simply and automatically update multiple SonicPoint units in a controlled
fashion, rather than changing all peered SonicPoints at once, which can cause service disruptions.

Hardware Failover and LAN Port Disconnect Transitions

While in Managed Mode, two additional SonicPoint transitions have been defined to help provide
uninterrupted connectivity and high availability. The first such transition is specific to configurations
wherein two SonicWALL appliances are paired in a Hardware Failover Mode. The following is a brief
explanation of Hardware Failover (HF) concepts which will be useful in understanding the integration
of SonicPoints into HF scenarios:
• Primary: Describes 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.
• Backup: Describes the subordinate hardware unit itself. The Backup identifier is a relational
designation, and is assumed by a unit when paired with a Primary unit. Under normal operating
conditions, the Backup unit operates in an Idle Mode. Upon failure of the Primary unit, the Backup
unit will assume the Active role.
• Active: Describes the operative condition of a hardware unit. The Active identifier is a logical role
that can be assumed by either a Primary or Backup hardware unit.
• Idle: Describes the passive condition of a hardware unit. The Idle identifier is a logical role that can
be assumed by either a Primary or Backup hardware unit. The Idle unit assumes the Active role in
the event of determinable failure of the Active unit.
In the illustration, if the Primary unit fails and the Backup unit becomes Active, SonicWALL2 will
broadcast a special SDP message informing all SonicPoints to drop their existing peering relationship
with SonicWALL1, and to immediately re-peer with SonicWALL2. The SonicPoint configurations will
already be synchronized as a result of the HF state-synchronization, and wireless service will be
restored in parallel with the failover.
S WALL S P
ONIC ONIC OINT
A ' G
DMINISTRATOR S UIDE
SonicPoint Overview
23