Updated: 7/28/15
WiFi changes resulting from deployment of Cisco APs
I. Features of new Cisco WiFi system
a. Support for 11ac wave 1. 802.11ac works only in the 5 GHz band.
b. 3×4:3 capability (3 receive chains, 4 transmit chains, 3 spatial streams). Translation: higher throughput capability than AP622, AP650 and AP7131.
c. Cisco Radio Resource Management and CleanAir for RF monitoring and dynamic
d. Better rogue AP detection and containment.
e. Better monitoring and reporting through Prime
f. Centralized controller for Controller is hosted at DO, instead of at campus.
II. AP Deployment Considerations
a. Mounting, PoE, and general RF design
i. The AP2700 with internal antenna array is designed to be ceiling mounted, with the AP LED facing down. Wall mounting APs results in half the power of the AP being wasted and will result in poor
ii. Ideally, site surveys should be performed prior to new AP2700
iii. “Hallway” designs, where 3 or more APs are line of sight to one another down a hallway, should be avoided wherever This design results in co-channel interference, which will degrade the performance of the wireless network.
iv. Legacy 11b data rates are disabled on the Cisco controller. 802.11b clients will not be able to connect. The minimum 802.11g data rate is 12 Mbps. Please note that in some areas the rates disabled on the Cisco controller are enabled on the Motorola controllers. This could result in a shrink of coverage areas for 802.11g clients if AP2700s are placed in the same locations as existing AP300s. However, 802.11n and 802.11ac clients get better range than 802.11g clients for the same transmit power levels.
b. Connections to LAN switches
i. The AP2700 can draw power in excess of 4 Watts, the limit of 802.3af PoE. If 802.3at PoE+ is available, that is preferred. If not, the AP2700 will disable one of the transmit chains in each band. Overall, this won’t be much of a performance decrease. Even with one transmit chain disabled, the AP2700 will still perform better than an AP622 or AP650. On the OS6250 switch, the first 6 ports are 802.3at PoE+, 31 Watt ports. The combo ports are also high power (in addition to being gigabit ports).
ii. Ideally, the AP2700s should be connected to PoE+ gigabit Each OS6250 switch has two ports that are capable of PoE+ gigabit Ethernet: ports 25 and 26. By default, PoE is disabled on ports 25 and 26. It must be enabled manually, and doing so disables PoE on ports 23 and 24 of the same switch chassis.
iii. The older style Motorola/Symbol power injectors cannot be used to connect an AP2700 to a gigabit port on a non-PoE These PoE injectors only support 100 Mbps connections.
iv. In order for the AP2700 to negotiate power with the switch correctly, the switch must support LLDP and be running a version of firmware that supports the power-via-mdi TLV for Class 4 PoE At the moment, only the OS6250/6450 switches supports this TLV, and only for firmware versions 6.6.3.552R01, 6.6.4.285R01, or above. APs connected to OS6850 switches will think they are using a power injector (instead of PoE) and will run at 802.3af PoE levels (15.4 Watts). Ultimately, this means that AP2700s connected to OS6850 switches will have a transmit chain disabled.
v. Switch ports where AP2700s connect will need special port configurations (802.1Q trunks) to support the WLANs that will be mapped to AP network connections should not be moved without notifying District IT.
vi. As part of initial deployment, Cisco APs will be placed into management containers that will apply building-specific Moving Cisco APs between buildings on campus must be coordinated with District IT.
vii. To summarize: the priority for the AP’s LAN connection should be gigabit Ethernet first, then PoE+.
III. WLAN specific changes
a. LRCCD
i. The LRCCD SSID will become a public network-only WLAN for students, faculty, and staff. Privileged WiFi (“admin”) will require a new SSID (see below for more )
ii. User traffic for LRCCD will be tunneled to the controller at DO and placed onto a privately addressed network. NAT is performed at the
iii. Application Visibility and Control (AVC) is enabled for the LRCCD WLAN. This grants the ability to see what types of traffic users are generating, and the ability to filter certain types of traffic at ingress into the wireless At the moment, well-known p2p application traffic is being blocked by the AVC profile on the LRCCD WiFi network.
iv. WLAN security settings (WPA2-Enterprise), RADIUS authentication and certificate will remain the
b. Guest networks
i. The guest networks at campuses will have the campus/site abbreviation removed from the beginning of the The SSID will change names to just “guest”.
ii. Guest user accounts will still need to be created for guest users, using the current
iii. Guest users will be put into a captive portal for authentication against the wireless The look and feel of the authentication page will change.
iv. Beacon frames will be re-enabled for guest It won’t be necessary to hide the SSID for performance protection.
v. Guest WiFi traffic is tunneled to the controller at DO and placed onto a privately addressed network. NAT is performed at the border.
vi. Multiple devices can authenticate to the guest network using the same username/password.
vii. There is support for “sleeping clients,” meaning re-authentication would not be required for users whose devices went into a sleep mode. This feature is still being tested.
c. Employee – new WLAN
i. As a result of the new WLAN controller and AP architecture, privileged employee access will require the use of a new, distinct WLAN/SSID separate from LRCCD.
ii. Security settings, RADIUS certificate, and RADIUS authentication policies for the new employee WLAN will be the same as existing LRCCD
iii. Traffic for users on the employee WLAN will be terminated locally to the switch the AP is connected to, instead of being tunneled to the The VLAN that user traffic is put onto is configurable, and can be defined per-AP or per- building.
d. Instruction WLANs
i. SSID, Security settings, RADIUS certificate, and RADIUS authentication policies for this network will remain the
ii. Traffic for users/devices on the Instruction WLANs will be terminated locally to the switch the AP is connected to, instead of being tunneled to the The VLAN that user/device traffic is put onto is configurable, and can be defined per-AP or per-building.
iii. To support AirPlay, it will be possible to place AppleTVs onto the same VLAN as client traffic on the Instruction This will facilitate discovery of the AppleTVs and ensure AirPlay traffic gets to the display device in a timely fashion.