DWS-3160 Series Gigabit Ethernet Unified Switch Web UI Reference Guide
497
Appendix F Wireless Switch Specific
Authenticated Roaming and Clustering:
Captive Portal Guidlines
In addition to the generic implementation, Captive Portal also provides two key features for the wireless networks
called
authenticated roaming
and
clustering
.
1. Authenticated roaming allows the client to roam from access point to access point in a seamless fashion
while remaining authenticated.
2. Clustering provides roaming between access points attached to different switches and monitoring Captive
Portal status for all switches from the Cluster Controller.
The Switches in the cluster must share the same Captive Portal settings, such as Captive Portal Configuration
instances, associated interfaces, local user database and RADIUS server settings. The databases should be
synchronized in a cluster to support client authenticated roaming.
Each Switch in the peer group makes an independent decision about who is the Cluster Controller. If a Switch does
not have any peer Switches, then it appoints itself the Cluster Controller.
Cluster Controller Election
When two Switches detect each other through the discovery process, they compare the value of the Cluster priority
field. The Switch with higher priority becomes the Cluster Controller. If the priority is the same, then the Switch with
lower IP address becomes the Cluster Controller. The Cluster priority is conveyed in the initial identification
message
The Cluster priority has a range from 0 to 255. Setting the priority to 0, disables the Cluster Controller function on
the Switch. Customers may want to disable the low-end Switches from becoming the Cluster Controller if they
deploy a large network where only a high end switch or network appliance is powerful enough to act as the Cluster
Controller.
The administrator may change the Switch Cluster priority value after the Switch has already joined the peer group.
The Cluster priority is also conveyed in the keep-alive message enabling the peer Switches to learn the new
Cluster priority of the Switch.
A Switch performs the election process after it boots, after it loses connection to the current Cluster Controller, and
every time it receives an initial identification message or a keep-alive message from another Switch. The Switch
keeps a list of Cluster priorities and IP addresses for each peer Switch and elects the Cluster Controller based on
the criteria described above.
If a Cluster Controller Switch decides that it is no longer a controller because it receives a message from another
Switch with higher Cluster priority or lower IP address, then it purges some of the databases.
The decision to transition out of the Cluster Controller state is immediate. If the Switch elects itself as the Cluster
Controller immediately. If the Switch elects another Switch as the Cluster Controller, then the decision to declare
that Switch as the Cluster Controller is delayed for the duration of the keep-alive timer interval. If another Cluster
Controller is detected during this interval, then the delay timer is restarted. The administrator looking at the Switch
status during the delay period would see that the Switch is not the Cluster Controller and the Cluster Controller
address is 0.0.0.0. In this release the keep-alive timer interval is fixed at 120 seconds.
Each peer Switch independently establishes connections with other peer Switches. In a transient case, it is
possible that one of the Switches, that just established a connection with another Switch, does not see all the
Switches that the other Switch is seeing, so that the two Switches may select different Cluster Controllers. Although
the WIDS security functions do not work correctly when peer Switches disagree about which Switch is the Cluster
Controller, this condition does not affect data forwarding through the network and normal operation is restored as
soon as all the Switches in the peer group discover each other.
