N+1 High Availability (HA)

Since release 7.4 for Wireless LAN Controllers (WLC) more and more customers are using this solution to provide wireless redundancy. The HA-SKU secondary WLC within the Cisco Unified Wireless Network (CUWN) framework allows a single WLC to be used as a backup WLC for N primary controllers. The advantages of this would be cost (HA-SKU controller with no need for additional licences) and the secondary controller could be geographically separate from any of the other primary controllers.

N+1 HA

These WLCs are independent of each other and do not share configuration or IP addresses on any of their interfaces. Each WLC needs to be managed separately by Cisco Prime, can run a different hardware and a different software version (it would however make sense to have all WLC’s on the same software version) and can be deployed in different data centres across the WAN link.

When an AP fails over to a WLC running a version other than that on the primary, the corresponding image is downloaded to the AP. This adds to the failover time. Again, it is recommended to have your WLC’s on the same software version.

When a primary WLC resumes operation, the APs fall back from the backup WLC to the primary WLC automatically if the AP fallback option is enabled. AP’s with high priority on the primary controller always connect first to the backup controller, even if they have to push out low priority APs.

On the HA-SKU secondary controller the 90-day timer will start when the AP’s join the controller and the user will see a warning message after 90 days. In other words, an HA-SKU controller can be used as a secondary controller for 90 days without a warning message. Starting release 7.6, if all the access points fall back to the primary controller within or after the 90 days period, the timer will be reset and warning messages will stop.

The HA-SKU provides the capability of the maximum number of APs supported on that hardware. For instance, a 5508 HA- SKU controller provides support for 500 APs.

Configuration

From the primary controller, navigate to Access Points > Global Configuration, then configure the backup controller on the primary to point to the secondary controller.

On the secondary controller, navigate to Controller > Redundancy > Global Configuration, then configure the secondary controller to convert it to an HA-SKU secondary controller. Ensure Redundant Unit are changed to Secondary and AP SSO is Disabled.

On all WLC’s under Wireless > All APs > High Availability your HA-SKU can be configured as secondary or tertiary as needed.

Failover Process

In the N+1 HA redundancy model, one WLC serves as the backup controller for N primary controllers. When any of the primary WLCs fail, the APs connected to that controller fall back to the backup controller. The AP has to restart its CAPWAP state machine and go through a complete discovery phase before it joins the backup controller. The available AP count on the backup controller is reduced by the number of APs that fall back from the primary WLC to the backup WLC.

For example, when the primary controller supporting 90 APs fails, these APs fall back to the backup controller that has a maximum AP support of 500. The backup WLC is left with an available AP count of 500 – 90 = 410 APs.

Nice and easy!

Reference:

http://www.cisco.com/c/en/us/td/docs/wireless/technology/hi_avail/N1_High_Availability_Deployment_Guide/N1_HA_Overview.html

N+1 High Availability (HA)

When to FlexConnect

This week I’m having talks with a client regarding wireless at his remote sites. As they are currently having autonomous access points on all these sites they are looking to change to controller based access points and are starting to ask questions like ‘Do I need a WLC on each site?’, ‘How many AP’s can I have on a remote site connecting back to a central WLC’ and ‘What happens when the WAN-link goes down?’. Hopefully the answers can be found in this post.

FlexConnect

FlexConnect is a wireless solution for branch office and remote office deployments. From a central Wireless LAN Controller (WLC), hopefully in your Data Centre with a redundant WLC not too far away, you can configure, control and manage access points in a branch or remote office. No need for a WLC in each office.

Switching Modes 

There are two switching modes supported by FlexConnect AP’s:

Local Switched: Locally-switched WLAN’s (the SSID you are connected to) will map their wireless user traffic to a VLAN via 802.1Q trunking to a local switch adjacent to the access point. A branch user, who is associated to a local switched WLAN, has their traffic forwarded by the on-site router. Traffic destined off-site (to the central site) is forwarded as standard IP packets by the branch router. All AP control/management-related traffic is sent to the centralized Wireless LAN Controller (WLC) via CAPWAP. This diagram below from Enterprise Mobility 7.3 Design Guide shows the local switched VLAN terminates at the switch and traffic can move from there to the branch servers or over the WAN as a standard IP packet and not a CAPWAP controlled tunnel. Flexconnect Central Switched: Central switched WLANs tunnel both the wireless user traffic and all control traffic via CAPWAP to the centralized WLC where the user traffic is mapped to a dynamic interface/VLAN on the WLC. This is the normal CAPWAP mode of operation. The traffic of a branch user, who is associated to a central switched WLAN, is tunnelled directly to the centralized WLC. If that user needs to communicate with computing resources within the branch (where that client is associated), their data is forwarded as standard IP packets back across the WAN link to the branch location. Depending on the WAN link bandwidth, this might not be desirable behaviour. Thus, if the branch client is connected to a SSID that needs services locally (such as print services and internet breakout) and centralized services (such as e-mail and AD) I would suggest to follow local switching. I would only follow central switching when the only service the WLAN provide is central such as secure guest services for example.

Design Considerations 

For me the main consideration is the WAN-link and here are some of the main considerations to take into account:

  •  It is highly recommended that the minimum bandwidth restriction remains 12.8 kbps per AP.
  • The round trip latency should not be greater than 300 ms for data deployments and 100 ms for data + voice deployments.
  • The maximum transmission unit (MTU) must be at least 500 bytes.
Deployment Type WAN Bandwidth (Min) WAN RTT Latency (Max) APs per Branch (Max) Clients per Branch (Max)
Data 64 kbps 300 ms 5 25
Data + Voice 128 kbps 100 ms 5 25
Monitor 64 kbps 2 sec 5 N/A
Data 640 kbps 300 ms 50 1000
Data + Voice 1.44 Mbps 100 ms 50 1000
Monitor 640 kbps 2 sec 50 N/A

Other considerations you might want to look at is roaming capabilities and QOS but from experience with both Cisco and Spectralink wireless phone solutions I had no problems in getting them working over a FlexConnect local switching solution.

Operation Modes

There are two modes of operation for the FlexConnect AP.

  • Connected mode: The WLC is reachable. In this mode the FlexConnect AP has CAPWAP connectivity with its WLC.
  • Standalone mode: The WLC is unreachable. The FlexConnect has lost or failed to establish CAPWAP connectivity with its WLC. A WAN-link outage between a branch and its central site is a example of such a mode of operation.

FlexConnect States

A FlexConnect WLAN, depending on its configuration and network connectivity, is classified as being in one of the following defined states.

  • Authentication-Central/Switch-Central: This state represents a WLAN that uses a centralized authentication method such as 802.1X, VPN, or web. User traffic is sent to the WLC via CAPWAP (Central switching). This state is supported only when FlexConnect is in connected mode.
  • Authentication Down/Switching Down: Central switched WLANs no longer beacon or respond to probe requests when the FlexConnect AP is in standalone mode. Existing clients are disassociated.
  • Authentication-Central/Switch-Local: This state represents a WLAN that uses centralized authentication, but user traffic is switched locally. This state is supported only when the FlexConnect AP is in connected mode.
  • Authentication-Down/Switch-Local: A WLAN that requires central authentication rejects new users. Existing authenticated users continue to be switched locally until session time-out if configured. The WLAN continues to beacon and respond to probes until there are no more existing users associated to the WLAN. This state occurs as a result of the AP going into standalone mode.
  • Authentication-local/switch-local: This state represents a WLAN that uses open, static WEP, shared, or WPA2 PSK security methods. User traffic is switched locally. These are the only security methods supported locally if a FlexConnect goes into standalone mode. The WLAN continues to beacon and respond to probes. Existing users remain connected and new user associations are accepted. If the AP is in connected mode, authentication information for these security types is forwarded to the WLC.

I hope this summarization will help in your decisions regarding FlexConnect.

Reference and other FlexConnect information: http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/emob73dg/emob73/ch7_HREA.html http://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/112042-technote-product-00.html

When to FlexConnect

Cisco Wireless EoS and EoL announcement – Dec 2014

Here are the end-of-sale and end-of-life announcements regarding Cisco Wireless for the last month.

Note: Use the links to view the table info mentioned in the post.

End-of-Sale and End-of-Life Announcement for the Cisco Aironet 600 Series OfficeExtend -E and -I Regulatory Domain

Cisco announces the end-of-sale and end-of-life dates for the Cisco Aironet 600 Series OfficeExtend -E and -I Regulatory Domain. The last day to order the affected product(s) is December 19, 2014. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers’ service contract.

End-of-Sale and End-of-Life Announcement for the Cisco 3355 Mobility Services Engine

Cisco announces the end-of-sale and end-of-life dates for the Cisco 3355 Mobility Services Engine. The last day to order the affected product(s) is June 15, 2015. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers’ service contract.

Cisco Wireless EoS and EoL announcement – Dec 2014

Translating mW, dBm, MHz and channels

Every so often I have to configure the Radio Transmit Power on an Access Point (AP) and it just happen that the wireless client transmit power is provided in milliwatt (mW) but I need to configure the APs transmit power to match that of the wireless client which need to be done in decibel-milliwatt (dBm). So let’s translate between the two.

The Radio Transmit Power setting determines the power level of the radio transmission. The default power setting is the highest transmit power allowed in your regulatory domain. Government regulations define the highest allowable power level for radio devices. This setting must conform to established standards for the country in which you use the device. The power settings may be in mW or in dBm depending on the particular radio that is being configured.

Definitions:

  • Watt (W): a unit of power equal to 1 joule per second; the power dissipated by a current of 1 ampere flowing across a resistance of 1 ohm.
  • Milliwatt (mW): a unit of power equal to one thousandth of a watt.
  • Decibel-milliwatt (dBm): an electrical power unit in decibels (dB), referenced to 1 milliwatt (mW).

Translation between mW and dBm:

 mW  dBm
1 -1
2 2
3 5
4 6
5 7
6 8
8 9
10 10
12 11
15 12
20 13
25 14
30 15
40 16
50 17
60 18
80 19
100 20
125 21
150 22
200 23
250 24

Then there is the configuration of channels for your autonomous access point and instead of providing the channel number it actually asks for the corresponding frequency in your regulatory domain.

Each 2.4-GHz channel are 22 MHz wide. The bandwidth for channels 1, 6, and 11 does not overlap, so you can set up multiple access points in the same vicinity without causing interference. Both 802.11b and 802.11g 2.4-GHz radios use the same channels and frequencies.

The 5-GHz radio operates from 5180 to 5825 MHz. Each channel covers 20 MHz, and the bandwidth for the channels overlaps slightly. For best performance, use channels that are not adjacent (44 and 46, for example) for radios that are close to each other.

Translation between channel and MHz for 802.11b/g:

Channel Identifier Center Frequency (MHz)
1 2412
2 2417
3 2422
4 2427
5 2432
6 2437
7 2442
8 2447
9 2452
10 2457
11 2462
12 2467
13 2472
14 2484

Translation between channel and MHz for 802.11a:

Channel ID Center Frequency (MHz)
5150 to 5250 MHz
34 5170
36 5180
38 5190
40 5200
42 5210
44 5220
46 5230
48 5240
5250 to 5350 MHz
52 5260
56 5280
60 5300
64 5320
5470 to 5725 MHz
100 5500
104 5520
108 5540
112 5560
116 5580
120 5600
124 5620
128 5640
132 5660
136 5680
140 5700
5725 to 5850 MHz
149 5745
153 5765
157 5785
161 5805
165 5825

Reference                                                              http://www.cisco.com/c/en/us/td/docs/wireless/access_point/12-4-25d-JA/Configuration/guide/cg_12_4_25d_JA/scg12-4-25d-JA-chap6-radio.html

 http://www.cisco.com/web/techdoc/wireless/access_points/online_help/eag/123-02.JA/1400BR/h_ap_network-if_802-11_c.html

 http://www.cisco.com/c/en/us/td/docs/wireless/access_point/channels/ios/reference/guide/atonchp2/1200_chp.html#wp1047037

Translating mW, dBm, MHz and channels

Spectralink 84-Series Wireless Telephones

Last week I was on the Spectralink WiFi Support Specialist course and thought I’ll share some of the Spectralink 84-Series wireless phone features with you:

Microsoft Lync compatibility

The Spectralink 84-Series handsets has established interoperability with the Microsoft Lync 2010 Telephony Server.

Spectralink software is now available in two variants – Lync and non-Lync (or open SIP). Starting with Spectralink software 4.3/4.4, even-numbered releases support both Lync and open SIP and odd-numbered releases support open SIP only.

Personal Alarms

Workers can be at risk during security breaches or if personal incidents require immediate attention. Spectralink 8441 and 8453 handsets offer personal monitoring and duress call functionality, including “man down” alarms, “running” alarms and duress calls to an emergency number. Coupled with a security alarm application program, real-time location information from the alarming handset can be displayed on security monitors and sent to other Spectralink 84-Series handsets for mobile response. The existing functionality of Location Services allows an alarming handset’s location to be pinpointed so that aid can be directed to the exact scene. When deployed in conjunction with a security alarm application, Spectralink Personal Alarms provide unparalleled support for isolated workers or other at-risk personnel in potentially threatening situations.

Implementation with Location Services

All Spectralink 84-Series handsets support integration with the Ekahau RTLS system. The handsets send periodic location information to an Ekahau server allowing the server to pinpoint the handsets’ location.

To maximize battery life, an administrator may set this update interval conservatively. In the event the handset enters an alarm state, the handset can be configured to send updates more frequently which would allow the Ekahau RTLS system to provide updated positions of the alarming handset more frequently. Additionally, if the Ekahau system is integrated into a management application these positions can be sent to responders.

Additional 3rd-party RTLS systems, e.g. Aeroscout, may also be able to provide location of
Spectralink 84-Series handsets.

Push-to-Talk and Group Paging

The Push-to-Talk (PTT) and Group Paging features are supported on all Spectralink 84-Series handset models.

The Group Paging feature enables pages —one-way audio announcements — to users
subscribed to a page group. Paging mode was originally intended primarily for desktop phones but has some use for Wi-Fi handsets that may or may not also be using PTT. In Page mode, announcements play only through the handset’s speakerphone.

The Push-to-Talk (PTT) feature is a collaborative tool that enables users to exchange radio
broadcasts to other users subscribed to a PTT channel. In PTT mode, the handset behaves like a walkie-talkie; users can broadcast audio to a PTT channel and recipients subscribed to that channel can respond to your message. PTT broadcasts can be transmitted using the handset, headset, or speakerphone. They can be rejected, placed on hold and ended at any time. PTT broadcasts can be received on the speakerphone, handset, and headset.

Barcode Reader

The Spectralink 84-Series enhances the customer value proposition through an optional integrated barcode scanner. The Spectralink 8452 and 8453 handsets with built-in 1D/2D barcode readers are extremely powerful information portals to important resources and business critical databases. Together with the phone there is also the Spectralink Quick Barcode Connecter (QBC) software.

The Spectralink QBC is a software application that enables you to capture and decode barcode patterns using one or more Spectralink 8452/8453 handsets and transfer the data to the application running on one or more host computers. You can think of it as a wireless barcode scanner connected to one or more host computers. When a handset captures barcode data, the data automatically transfers to the endpoint computer.

Reference:

http://www.spectralink.com/

Spectralink 84-Series Wireless Telephones

Cisco Wireless EoL, EoS and Security Advisories – Nov 2014

Here are some of the end-of-sale, end-of-life and vulnerabilities announcements regarding Cisco Wireless for the last month. Riveting reading material!

Note: Use the links to view the table info mentioned in the post.

End-of-Sale and End-of-Life Announcement for the Cisco Wireless Control System

Cisco announces the end-of-sale and end-of-life dates for the Cisco Wireless Control System. The last day to order the affected product(s) is May 6, 2015. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers’ service contract.

End-of-Sale and End-of-Life Announcement for the Cisco Prime Network Control System Series Appliances

Cisco announces the end-of-sale and end-of-life dates for the Cisco Prime Network Control System Series Appliances. The last day to order the affected product(s) is May 6, 2015. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers’ service contract.

End-of-Sale and End-of-Life Announcement for the Cisco Prime Infrastructure 1.x

Cisco announces the end-of-sale and end-of-life dates for the Cisco Prime Infrastructure 1.x. The last day to order the affected product(s) is May 6, 2015. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers’ service contract.

End-of-Sale and End-of-Life Announcement for the Cisco Prime Network Control System 1.x

Cisco announces the end-of-sale and end-of-life dates for the Cisco Prime Network Control System 1.x. The last day to order the affected product(s) is May 6, 2015. Customers with active service contracts will continue to receive support from the Cisco Technical Assistance Center (TAC) as shown in Table 1 of the EoL bulletin. Table 1 describes the end-of-life milestones, definitions, and dates for the affected product(s). Table 2 lists the product part numbers affected by this announcement. For customers with active and paid service and support contracts, support will be available under the terms and conditions of customers’ service contract.

Cisco Unified IP Phone Local Kernel System Call Input Validation Vulnerability

Cisco Unified IP Phones 7900 Series versions 9.3(1)SR1 and prior contain an arbitrary code execution vulnerability that could allow a local attacker to execute code or modify arbitrary memory with elevated privileges. This vulnerability is due to a failure to properly validate input passed to kernel system calls from applications running in userspace. An attacker could exploit this issue by gaining local access to the device using physical access or authenticated access using SSH and executing an attacker-controlled binary that is designed to exploit the issue. Such an attack would originate from an unprivileged context. Ang Cui initially reported the issue to the Cisco Product Security Incident Response Team (PSIRT). On November 6, 2012, the Cisco PSIRT disclosed this issue in Cisco bug ID CSCuc83860 (registered customers only) Release Note Enclosure. Subsequently, Mr. Cui has spoken at several public conferences and has performed public demonstrations of a device being compromised and used as a listening device. Mitigations are available to help reduce the attack surface of affected devices. See the &quo;Details&quo; section of this security advisory and the accompanying Cisco Applied Mitigation Bulletin (AMB) for additional information. Update (November 3rd, 2014): Updated software that resolves the vulnerability described in this document has been released.  This release is generally available and can be downloaded from the product-specific support areas on Cisco.com. The release version is 9.4(2). This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130109-uipphone

Cisco Prime Infrastructure Command Execution Vulnerability

A vulnerability in Cisco Prime Infrastructure could allow an authenticated, remote attacker to execute arbitrary commands with root-level privileges. The vulnerability is due to improper validation of URL requests. An attacker could exploit this vulnerability by requesting an unauthorized command via a specific URL. Successful exploitation could allow an authenticated attacker to execute system commands with root-level privileges. Cisco has released free software updates that address this vulnerability. A software patch that addresses this vulnerability in all affected versions is also available. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140226-pi

Cisco Wireless Control System Conversion Utility Adds Default Password

Customers with the CiscoWorks Wireless LAN Solution Engine (WLSE) may use a conversion utility to convert over to a Cisco Wireless Control System (WCS). This conversion utility creates and uses administrative accounts with default credentials. As there is no requirement to change those credentials during the conversion process, an attacker may be able to leverage these accounts with default credentials to take full administrative control of the WCS after the conversion has completed.
Customers who have converted their CiscoWorks WLSE to a Cisco WCS are advised to set strong passwords for all accounts on their Cisco WCS.

Cisco Wireless Control System Tomcat mod_jk.so Vulnerability

Apache Tomcat is the servlet container for JavaServlet and JavaServer Pages Web within the Cisco Wireless Control System (WCS). A vulnerability exists in the mod_jk.so URI handler within Apache Tomcat which, if exploited, may result in a remote code execution attack. This advisory is posted at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20080130-wcs

Multiple Vulnerabilities in Cisco Wireless LAN Controllers

Multiple vulnerabilities exist in the Cisco Wireless LAN Controller (WLC) platforms. This security advisory outlines the details of the following vulnerabilities: Malformed HTTP or HTTPS authentication response denial of service vulnerability SSH connections denial of service vulnerability Crafted HTTP or HTTPS request denial of service vulnerability Crafted HTTP or HTTPS request unauthorized configuration modification vulnerability Cisco has released free software updates that address these vulnerabilities. This advisory is posted at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20090727-wlc

SQL Injection Vulnerability in Cisco Wireless Control System

Cisco Wireless Control System (WCS) contains a SQL injection vulnerability that could allow an authenticated attacker full access to the vulnerable device, including modification of system configuration; create, modify and delete users; or modify the configuration of wireless devices managed by WCS. Cisco has released free software updates that address this vulnerability. There are no workarounds for this vulnerability.

Cisco Wireless EoL, EoS and Security Advisories – Nov 2014

Cisco vs Aruba – throughput

A while back one of our customers asked us to do an vendor assessment of their wireless infrastructure. I went and did some research on what type of testing will be suitable for our client and found these three “independent” reports where the Cisco 3700 Series Access Point was compared against the Aruba AP-225. In this post I will only show the results from their throughput testing. What a variety of results!

The first assessment was done by Miercom in November 2013 and these were the results as described by them:

Miercom

‘The Cisco Aironet 3702i delivered greater throughput than the Aruba AP-225 in all 12 scenarios in multi-client performance testing. The difference in throughput ranged from a low of 16.6% to one client to a high of 83.2% to the maximum population, 60 clients supporting 2 or 3 spatial streams, shown here.’

As shown in the Miercom figure above the Cisco 3702i provided more than 83.2% greater throughput per client than Aruba AP-225 with 60 devices supporting 2 or 3 spatial streams.

The second assessment was done by Novarum in June 2014 and these were the results as described by them:

Novarum

‘The Aruba AP-225 delivered an average of 302 Mbps in bi-directional throughput across 60 clients – twice the aggregate throughput of Cisco’s 3702i which was 137 Mbps. The results were consistent for each test run, and inline with the test results shown for the sixty client throughput test with downstream only traffic shown.’

The third assessment was done by Tolly and commissioned by Meru Networks in June 2014 and these were the results as described by them:

Tolly

‘The Meru Networks AP832i solution outperformed the competing solutions in all scenarios but one. The Meru Networks solution outperformed the Aruba Networks offering by approximately 2x in the tests involving VoIP and video streaming.

With the exception of the bidirectional data test, the Meru Networks AP832i solution performance was anywhere from 1.21x to 1.32x that of the Cisco Systems Aironet 3702i solution.’

Looking at these results there are two important aspects to take out of it. One – who commissioned the assessment. Two – don’t take the results seriously.

Reference

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CCkQFjAC&url=http%3A%2F%2Fwww.dit.co.jp%2Fproducts%2Fmeru_networks%2Fpdf%2Ftolly214124meruwlanperformancevsarubaandcisco.pdf&ei=V1hpVNTPHIq0uASO_YLYCQ&usg=AFQjCNEDuwQJ3xmb-DrAOBtlU3W6wdLPMw&sig2=bBMOoOF7dI9o82JAqZtpRA&bvm=bv.79142246,d.c2E

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB8QFjAA&url=http%3A%2F%2Fwww.arubanetworks.com%2Fpdf%2Ftechnology%2FTR_Novarum.pdf&ei=c15pVNmuBIq1uATrs4C4Ag&usg=AFQjCNFpEEdts_yGzRFa0lVgW6f-1aCALA&sig2=vOvTSIQMjIuXvkwI8EFOlw&bvm=bv.79142246,d.c2E

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB8QFjAA&url=http%3A%2F%2Fwww.cisco.com%2Fweb%2Flearning%2Fle21%2Fonlineevts%2Fwireless%2Fmiercom-report-cisco-ap-3702i.pdf&ei=il9pVOXwFYyiuQTrzIHoAg&usg=AFQjCNH7pGsEeF9sgbiNQtbOjnPxSN21qA&sig2=ogeiaKPxNQs9PIQP2zw88w&bvm=bv.79142246,d.c2E

 

Cisco vs Aruba – throughput

NDP packets on Cisco 3700 abnormally low

This post is a follow up from last weeks one-way audio issue. Although we did resolve the one-way audio by disabling A-MSDU we also found a bug on the Wireless LAN Controller that caused Neighbour Discovery Protocol (NDP) packets to be abnormally low and thus causing the TX power of the Access Point (AP) to be excessively high (power level set to 1) and channel assignment not working at all. I’ve noticed this bug twice in the last month at different customers.

This bug only affected the 5GHz radios as seen in the diagrams below and not 2.4GHz. Diagram 1 shows power levels for 5GHz on the right and Diagram 2 shows power levels for 2.4GHz on the right for the same AP’s.

5GHz - Power level 1

2.4GHz - Power level 8

I monitored ten AP’s in a particular area. Seven of these AP’s would stay on power level 1 and would not change while the other three AP’s in this area would change its power level on the 10 minute mark (as per default) and change between power levels 2-5 on a continuous basis. On the second occasion I saw this the client had about 25 AP’s on site and all of them was stuck on channel 36 and power level 1.

This could be the root cause of one-way audio. It is important to understand that wireless communication occurs in a bi-directional manner. Uplink communication from the client to the AP is not always the same as downlink communication from the AP to the client. While an AP will send beacons downlink to the VoWLAN handset, most surveying tools will only display information as it pertains to downlink transmissions; therefore some problems are not easily detected using pre- or post-site survey tools. While a post site survey is vital after deploying the WLAN, a survey tool may not take into consideration the uplink signal being transmitted by the  wireless IP phone in comparison to the downlink signal.

Most access points will often have a higher transmit power + the antenna gain than the VoWLAN handset. When this occurs, the IP phone will still hear the downlink frames sourced from the AP, but the AP will not hear the uplink frames from the wireless IP phone and this leads to possible one-way audio.

The workaround prescribed by Cisco would be to manually assign channel/power settings which could turn into a timeous process or as the update of this bug shows from 6 November 2014 you can upgrade to the releases mentioned below.

The equipment used in this case are:

  • Cisco 5508 Wireless LAN Controller
  • Cisco 3700 series Access Point

The software affected by this bug (CSCuq86750) are:

  • 7.6(120.0)
  • 8.0(100.0)
  • 8.0(102.9)

The known fixed releases are:

  • 7.6(130.10)
  • 7.6(130.204)

Reference      http://www.cisco.com/c/en/us/td/docs/wireless/technology/vowlan/troubleshooting/vowlan_troubleshoot/2_Gen_Troubleshooting_Guidelines.html#wp1054631  https://tools.cisco.com/bugsearch/bug/CSCuq86750

 

NDP packets on Cisco 3700 abnormally low

VoWLAN one-way audio (A-MSDU & A-MPDU)

Not too long ago I got involved in an issue a client had with its wireless voice infrastructure – one-way audio.

The installation involved the following equipment:

  • Cisco 5508 Wireless LAN Controller
  • Cisco 3700 Series Access Points
  • Spectralink 84-series Wireless Telephones

The one-way voice issue for this client was not the usual where the far end can’t here the person on the wireless phone because of AP transmit power levels. For areas where there is deficient coverage and you then increase the AP transmit power to levels that the client devices cannot support would only increase coverage on the downlink.

power-voice-mw

This one-way audio was in the other direction, the wireless client could not hear the person speaking on the far end. The more I investigated the issue and doing research on it three possible solutions kept on coming up:

  • Disable 802.11n on the radios
  • Don’t use WPA2-PSK – rather use mac-filtering
  • Disable A-MSDU or A-MPDU on the 802.11a radio

The first two options I found ridiculous and later found they both relate to option three, so I needed to look into option three.

What is A-MSDU and A-MPDU?                                                                                                      Every frame transmitted by an 802.11 device has a significant amount of overhead, including radio level headers, Media Access Control (MAC) frame fields, interframe spacing and acknowledgment of transmitted frames. At the highest data rates, this overhead can consume more bandwidth than the payload data frame. To address this issue, the 802.11n standard defines two types of frame aggregation: MAC Service Data Unit (MSDU) aggregation and MAC Protocol Data Unit (MPDU) aggregation. Both types group several data frames into one large frame. Because management information needs to be specified only once per frame, the ratio of payload data to the total volume of data is higher, allowing higher throughput.

In 802.11n standard, Frame Aggregation was the most important MAC enhancement proposed which maximize throughput and efficiency. There are two methods available to perform frame aggregation:

  • Aggregate MAC Service Data Unit (A-MSDU)
  • Aggregate MAC Protocol Data Unit (A-MPDU)

The main distinction between MSDU & MPDU is the former corresponds to upper part of MAC sub-layer.

A-MSDU: The concept of A-MSDU is to allow multiple MSDUs (MAC Service Data Units) to be sent to the same receiver concatenated in a single MPDU. This supporting function for A-MSDU within 802.11n is mandatory at the receiver. Due to Destination Address (DA) and sender Address (SA) in the sub-frame header must match to same receiver address (RA) and the transmitter address (TA) in the MAC header, A-MSDU cannot be used for broadcast & multicast.

A-MPDU: The concept of A-MPDU aggregation is to join Multiple MPDU sub frames with a single leading PHY header. A key difference from A-MSDU aggregation is that A-MPDU functions after the MAC header encapsulation process. This method offer higher MAC throughput compare to A-MSDU.

So what was happening?                                                                                                                Since the client was on a Cisco infrastructure and using Spectralink wireless phones we were hitting an issue where A-MSDU is enabled and thus allowing multiple MSDUs to be sent to the same receiver and A-MSDU is not mandatory at the receiver end which then causes the phone to start dropping traffic from the AP after it was received. This means audio from the far end would be missing. A wireless trace in promiscuous mode would appear perfectly normal (voice packets and ACKs all accounted for). This problem only shows up with WPA/WPA2, and only when 802.11n aggregated frames are received.

Disabling 802.11n altogether can be a quick way to verify the problem is gone, but you don’t need to disable 802.11n, you just need to disable A-MSDU frame aggregation.

Follow this configuration on the WLC to resolve the issue (In this example we are disabling it on 802.11a):

config 802.11a disable network                                                                                               config 802.11a 11nsupport a-msdu tx priority all disable                                                      config 802.11a enable network                                                                                                  save config

If a Cisco 1142 AP is in use, disable MPDU aggregation:

config 802.11a disable network                                                                                                  config 802.11a 11nsupport a-mpdu tx priority all disable                                                     config 802.11a enable network                                                                                                   save config

Since then no more one-way audio.

Reference                                                                                                                                       Cisco Site Survey Guidelines for WLAN Deployment                                                                      VIEW Certified Configuration Guide                                                    http://mrncciew.com/2013/04/11/a-mpdu-a-msdu/                http://community.polycom.com/t5/SpectraLink/8440-Stops-responding/td-p/18208/page/2

 

VoWLAN one-way audio (A-MSDU & A-MPDU)

7 Lessons Learned when doing Wireless Site Surveys

1 Have a checklist ready

You need to be able to answer the following before starting any survey:

  • Is the survey for voice, data, location etc.?
  • Frequency bands to be used: 2.4GHz or 5GHz?
  • Will it be an active or passive survey?
  • What type of client devices would be used?
  • What type of facility is it (warehousing, office environment, outdoor or a combination)?
  • Is it multi or single floor layout?
  • Remember to get those scaled floor plans.
  • Remember to ask about high density or client count in specific areas.
  • Do they need redundancy of their Access Points? If one AP goes down will they still have the required coverage.
  • What is the required Receiver Signal Strength Indicator (RSSI)?
  • What is the required Signal-to-Noise (SNR)?
  • What would the transmit (Tx) power be of the client devices?

 

2 Plan your survey

Make sure you do an initial walkthrough that would help you identify access to all areas, define which areas need to be surveyed (restrooms and emergency staircases might be out-of-scope), anticipate areas that might be more difficult than others to survey (a busy high ceiling reception area compared to an open office area) and so on.

This would also be a good time to identify the high-availability and high-density areas discussed before. You would also have to note any power needs and consider cabling and mounting positions for your Access Point during the survey.

After all this, it is now time to prepare your Airmagnet Survey or Ekahau survey according to the checklist and walkthrough that was done.

 

3 Calibrate your map

Make sure you use the calibration tool in your site survey software, you should be able to draw a line between two points and as long as you then provide the correct distance between those two points it should rescale the map according to that distance. The longer the distance between the two points the more accurate you will be when calibrating your map.

Data gathered from a map not calibrated or calibrated incorrectly will provide inaccurate results and you won’t be able to correct the calibration. You will have to start over.

If it doesn’t look right it probably isn’t scaled correctly. Look at stretched or skewed maps or when one AP shows coverage over a large area might be an indication of an invalid map not properly scaled.

 

4 Signal Propagation

When you start a new survey there should be an opportunity to set the signal propagation. This allows the site survey application to predict signal propagation between data points. If this value is too high, the results render inaccurately and might show acceptable signal levels in areas where there is insufficient coverage.

Your survey application might have a measurement set for office environments, hospitals, warehouses or outdoors but when I’m doing an indoor area like a hospital, meeting rooms and office space I usually set my signal propagation to 3 meters, warehouse to 5 meters and outdoors could be slightly higher.

When your signal strength after a survey shows coverage far from the path you walked it might be an indicator that you made a mistake when setting your signal propagation.

 

5 Channel Scanning

It is recommended that you scan only the channels that are in use by the wireless infrastructure. You might receive inaccurate readings if you walk too fast between data points and do not give the adapter enough time to complete the entire scan list. So be careful not to scan too many channels as it does take time to complete the entire scan list while surveying. Also, if you are looking for Rogue AP’s you will need to scan all channels before you can be 100% sure you picked up all devices.

 

6 Walking Paths

When you receive a survey make sure to check the walking paths of the surveys completed. Check that the person that did the survey didn’t walk through areas that was impossible to walk through, like a wall. That is an indication that your results might be wrong.

Also make sure your single AP survey is complete meaning the person that did the survey went beyond the coverage cell edge that was decided on before the survey started.

 

7 Post-validation survey checklist

Here are some of the major targets to look out for when a survey is complete:

  • Do we have sufficient coverage? If it was decided to get a minimum signal strength of -67 dBm then ensure that is what was achieved.
  • Is the channel overlap adequate? If you were looking at a 20% overlap between coverage cells then check that it was achieved.
  • Signal-to-noise ratio. As per coverage and channel overlap ensure you achieved measures set when planning your survey
  • There might be a few other measures to check such as data rates, noise floor, bleed through, rogue devices and interferers.

 

Reference

Cisco Site Survey Guidelines for WLAN Deployment

 

7 Lessons Learned when doing Wireless Site Surveys