S
ONIC
WALL S
ONIC
P
OINT
A
DMINISTRATOR
’
S
G
UIDE
23
SonicPoint Overview
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.
