D-Link DWS-3160-24TC DWS-3160 Series Web UI Reference Guide - Page 502

DWS-3160 Series Gigabit Ethernet Unified Switch Web UI Reference Guide Appendix F Wireless Switch Specific Captive Portal Guidlines Authenticated Roaming and Clustering: 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. Cluster Controller Election 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. 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. 497