Summit WM3000 Series Controller System Reference Guide 485
Mesh Support
An AP can extend existing mesh functionality to a controller managed network. Mesh topology is
configured partly through the wireless controller (defining the role of each mesh node) and partly at the
mesh AP (defining the connection weight of each backhaul link). APs without a wired connection form
a mesh backhaul to a repeater or a wired mesh node and then get adopted to the controller. Mesh nodes
with existing wired access get adopted to the controller like a wired AP.
Setting a mesh takes two phases: the first phase is mesh AP staging during which all mesh APs are
wired to the controller (L2 or L3) for configuration. The second phase is mesh deployment: disconnect
all the remote APs (repeater APs and client bridge APs) to establish wireless backhaul connections.
After the deployment, the mesh backhaul topology cannot be modified.
Mesh supported APs apply configuration changes 180 seconds after the last received controller
configuration message. When the configuration is applied on the Mesh AP, the radios shutdown and re-
initialize (this process takes less than 2 seconds), forcing associated MUs to be deauthenticated and the
Mesh link will go down. MUs are able to quickly associate, but the Mesh link will need to be re-
established before MUs can pass traffic. This typically takes about 90 to 180 seconds depending on the
size of the mesh topology.
When mesh is employed, the "ap-timeout" value needs to be set to a higher value (for example, 180 seconds) so
Mesh APs remain adopted to the controller during the period when the configuration is applied and mesh links are
re-established.
AP Radius Proxy Support
When an AP is adopted to a controller over a WAN Link, the controller configures the AP for a WLAN
with Radius authentication from a Radius server residing at the central site. When the AP gets a Radius
MU associated, it sends the Radius packets on the wired side with its own IP Address as the source IP
of the request and the Destination IP Address of the Radius Server. In a local network implementation,
the APs, controller and Radius Servers are all on the same LAN and the routing works fine. However,
when the AP is adopted over a WAN link, the Radius Server IP Address will be an internal address
which is non-routable I over the Internet.
To access the Radius server’s non-routable IP address over the WAN, you have the option to configure
AP Radius Proxying for the WLAN. When this flag is enabled, the AP is reconfigured to send all radius
traffic to the controller and the controller does the proxying to the real Radius server to handle
authentication. The controller automates the process of handling Radius proxy configuration and client
configurations. The controller supports only one real radius server configuration without the presence
of realm information. To support multiple radius servers, a realm has to be associated with the real
Radius server.
When radius proxying is enabled without specifying a realm, the controller can no longer process
requests on the on-board radius server. You cannot authenticate using the on-board Radius server any
RSS State Independent WLANs Extended WLANs
RSS Enabled WLAN continues beaconing WLAN continues beaconing but AP does
allow clients to associate on that WLAN
RSS Disabled WLAN stops beaconing WLAN stops beaconing
To Next Page
Loading...