Information Systems:Advanced wireless administration (WLAN)

From uniWIKI
Jump to navigation Jump to search 
A collection of advanced topics and notes excised from other articles and grouped here. Because this is the stuff no one will ever read.

Advanced topics and notes

Cisco-like CLI

The WiNG CLI is a near-spitting image of Cisco IOS (what runs on their enterprise-grade equipment). Everything from the different modes (privileged, global config) to the commands themselves ('show running-config') leads to a Cisco-like experience. It was a pleasant surprise, but also, a bit of a blatant rip off!

GUI: Enterprise UI vs. Swift UI

The WiNG platform, like most enterprise networking platforms, is meant for CLI configuration. The biggest proof of this is that out of the box, WiNG APs come enabled with the crippled web interface, Swift UI. The settings configurable in Swift UI are not too much unlike a typical home router. Consult this document to change the web GUI to Enterprise UI.

Of course, this only has to be done once on the controller, if using an AP as a virtual controller.

Traditional controller vs distributed architecture

It is quite important to note that the term 'controller' in this scenario does not refer to a traditional wireless controller, where there is centralized traffic forwarding i.e. all wireless traffic passes through the controller, and the APs can't function without one. Rather, what we have is known as a distributed architecture, where the APs are independent and can function without a controller, yet their settings are configured and their stats are monitored by the adopting controller. This means any AP can even be turned off/disconnected without affecting the other APs (and their existing wireless connections). This wireless architecture is highly efficient as it centralizes management but avoids a hardware appliance, which as a single point of failure would make for a less fault-tolerant setup.

Due to the fairly potent internals of a typical AP in the market today, this feature is being offered more and more by vendors, and is completely feasible for smaller deployments (e.g. the management of 5 other APs by this controller is actually well under the recommended maximum of 64 devices).

Sytem profile and profile overrides

It is highly important to understand this following section if you are involved in the technical administration of the APs.

WiNG APs adopted by a controller are managed through a system profile. This profile is specific to a model of AP and is stored and managed by the controller. It contains base/default settings and applies them to adopted APs. Therefore, the method of configuring settings specific to a device (access point) is thus to configure device overrides that override the system profile. For example, the system profile sets the following:

  • Have the device acquire an IP address by DHCP.
  • Only VLAN 1 enabled by default, port type is Access.
  • Turn off the 2.4GHz radio, turn on the 5GHz radio with auto channel and auto power.
  • No SSIDs are mapped to either radio

Configuring the device overrides, the settings for a particular AP would then be as follows:

  • AP is set with a static IP.
  • Ge0 (ethernet port) of AP is set as a VLAN trunk, with VLAN 1 being native, and VLAN 2 being tagged on the port.
  • 2.4GHz radio is activated if necessary, 5GHz radio is set to a custom channel and power.
  • Select SSIDs are mapped accordingly, as BSSIDs on either or both radios.
  • Device name is configured.

The system profile in use - given we have only 1 type of access point - is called default-ap7532.

Of course, only a fraction of the settings need to be overridden, so the settings a device will consist of the those applied from the system profile, plus those configured as overrides.

Channels and antenna power

On the 2.4GHz band, only the non-overlapping channels 1, 6 and 11 are used. 4 access points (see table above) are enabled for 2.4GHz, with the farthest 2 sharing the same channel. There is also not that much noise from surrounding WiFi networks so there is little channel overlap. The intent is to keep wireless traffic on this spectrum to primarily serving RF gun usage to prevent interference. For devices able to use 5GHz, performance is drastically improved on that band anyway (802.11ac), so it is more desirable to steer clients to that radio.

On the 5GHz band, there are more non-overlapping channels than there are access points, so channels were selected randomly. It is worthy to note that all channels are available for selection, but some are supposed to be for DFS use (e.g. channel 165). These are expansion channels, so choosing one as the primary channel will cause most clients to not be able to connect to that radio.

Antenna output power was tuned using a semi-scientific process of detecting signal strength of the access points from different locations. If left at full power, 1 access point can blanket virtually 80% of the entire building with signal (leading to poor-quality signal at farther distances). Thus, it is ideal to restrict power to influence client-roaming to connect to the nearest AP for the best signal quality.

Guest and staff wireless authentication

Guest and staff wireless use captive portal for wireless authentication. Recall that in uwd_staff, the authentication scheme is MAC authentication with captive portal authentication as the fallback. For uwd_guest, captive portal is the sole authentication mechanism.

  • In MAC authentication, the MAC address (hardware address) of the device is matched against a list to determine if the device is permitted to join the network.
  • In captive portal authentication, a username and password is matched against a database to authenticate devices.
  • In both these cases, RADIUS provides the mechanism as well as the 'database' that stores all credentials (MAC addresses as well as usernames/passwords).
Retrieved from "https://owl.unipharm.com/mediawiki/index.php?title=Information_Systems:Advanced_wireless_administration_(WLAN)&oldid=10240"