Generic Wireless LAN evaluation test plan

Wireless LAN evaluation test planTable of ContentsWireless LAN evaluation test plan 1 Overview 3 1. Ease of use 41.1Guest access with captive portal and employee access with802.1x/WPA - one IP address, no external authentication server 41.2Guest account provisioning 51.3 Automatic channel and power assignment 61.4 Dynamic RF intelligence 72. Security - Intrusion Detection/Prevention capabilities 82.1 Rogue AP (WEP) detection/classification/containment 82.2 Ad-hoc networks detection and containment 102.3 Blacklist WiFi client based on firewall violations 113. Performance and Scalability 123.1 Intra-VLAN roaming 123.2 Inter-VLAN roaming 133.3 Secure Inter-switch mobility 143.4 Self-Healing – AP failure due to AP shut down 163.5 Self-Healing – AP failure due to Radio failure 173.6 Controller Redundancy 183.7 QoS prioritization of user-specified traffic on single SSID 193.8 Load balancing based on user thresholds 204. Troubleshooting and Management 224.1 Station statistics 224.2 Per-user debugging capabilities 234.3 Remote packet capture 244.4 Session mirroring 254.5 RF heat maps 264.6 Location tracking 27OverviewThis document outlines the test plan to evaluate an enterprise WLAN solution. The results of the tests conducted as a part of such an evaluation provides the evaluator with the data required to compare different WLAN solutions and make an educated choice on the right solution for the needs.The different parameters that should be considered by an evaluator before choosing the solution are:✓Ease of use✓Security✓Performance and Scalability✓Manageability and TroubleshootingThis test plan has been divided into different sections for the different areas that need to be tested and compared when evaluation a wireless LAN solution. Each section has a set of test cases. Each of the test cases has been presented in the following format:Test caseEquipmentrequiredTopologyDescription andtesting stepsExpected results1. Ease of useThis section includes scenarios that verify the ease of use for basic features needed in an enterprise WLAN.1.1Guest access with captive portal and employee access with802.1x/WPA - one IP address, no external authentication serverTest case Verify support for employee access using 802.1x/WPA and guest access using captive portal with only one IP address and no external authentication serverEquipment required 1 WLAN controller1 AP1 Laptop – Windows XP SP2 1 L2/L3 switch (optional)TopologyDescription and testingsteps 1.Assign the controller an IP address and default gateway (statically or via DHCP)2.Create VLANs for employees and guests, and for APs3.Configure the employee and guests to be NAT’d using the controller’s IPaddress4.Configure the DHCP server for employees, guests, and APs5.Configure an employee SSID to support WPA6.Configure an employee account on the controller7.Configure a guest SSID to be open-system and use captive portal8.Configure a guest account on the controller9.Configure access policies for guest (HTTP, HTTPS to Internet only) andemployee (any access)10.Associate a laptop configured to use open-system to the guest SSID and logonusing the guest ID and password11.Verify that the laptop gets an IP address from the configured DHCP server andverify connectivity12.Associate a laptop configured to use WPA to the employee SSID and logon usingthe employee SSID and passwordExpected results. Employees and guests should be able to connect to their respective SSIDs and access control should allow employees full access while limiting guests to Internet only for http and https. If external/Internet connectivity is not available then a server can be setup and access controls adjusted to allow/block access to that server for employees vs. guests.1.2Guest account provisioningTest case Verify support for guest accounts to be dynamically created using a special administrative login that allows a user, such as a front desk receptionist, to createguest accounts on a WebUI page.Equipment required 1 WLAN controller1 AP1 Laptop – Windows XP SP2 1 L2/L3 switch (optional)TopologyDescription and testingsteps 1.Assign the controller an IP address and default gateway (statically or via DHCP)2.Create VLANs for employees and guests, and for APs3.Configure the employee and guests to be NAT’d using the controller’s IPaddress4.Configure the DHCP server for employees, guests, and APs5.Configure an employee SSID to support WPA6.Configure an employee account on the controller7.Configure a guest SSID to be open-system and use captive portal8.Create a special administrative account that is only allowed to create guestaccounts9.Configure a guest account on the controller using the administrative login10.Associate a laptop configured to use open-system to the guest SSID and logonusing the new guest ID and password11.Verify that the laptop gets an IP address from the configured DHCP server andverify connectivity12.Associate a laptop configured to use WPA to the employee SSID and logon usingthe employee SSID and passwordExpected results. Employees and guests should be able to connect to their respective SSIDs and access control should allow employees full access while limiting guests to Internet only for http and https. If external/Internet connectivity is not available then a server can be setup and access controls adjusted to allow/block access to that server for employees vs. guests.1.3 Automatic channel and power assignmentTest case Performs automatic initial channel and power assignment for all access points in the network.Equipment required 4+ APs1 WLAN switch1 L2/L3 switch (optional)TopologyDescription and testing steps 1.Enable the automatic resource management feature for theWLAN solution, if required.2.Verify that the access points initially come up with the defaultchannel.3.Verify that the APs are allocated channels and power tominimize interference and optimize coverage. The adjacent APs should be on different channels and APs on the samechannel should be on lower power levels to minimizeinterference as opposed to APs that are unique on a singlechannel.Expected results. The WLAN solution assigns channels and power to the access points in a manner to minimize interference and optimize coverage. Also it takesinto account interfere nce from other sources (other than the Vendor’saccess points).1.4 Dynamic RF intelligenceTest case Verify that the WLAN solution can dynamically adapt to changing RF environments.Equipment required 3 APs1 WLAN switch2+ 3rd Party APs3 wireless clients/laptops1 File/FTP server1 L2/L3 switch/hub for 3rd party APs and File server 1 L2/L3 switch (optional)TopologyDescription and testingsteps 1.Connect the APs and let the automatic resource management algorithmconverge to a channel plan. If three APs are used in a clean environment on a 802.11b/g band, it should generally default to a channel plan with the APs on channels 1,6 and 11 respectively.e 2 (or more) 3rd party APs and a few wireless clients (associated tothe 3rd party APs) to generate interference on one of the channels being used by the “infrastructure” APs (channel 11 in the topology shown).The wireless client can download a file from a file server at the same time to generate the interference.3.If enough interference is detected by the AP on channel 11, it willchange channels and cause a change in channel/power assignment for other APs as well. Note change in channel and power assignment for all APs.Expected results. The WLAN solution can detect 802.11 interference and adapt the RF network to minimize impact due to the interference.2. Security - Intrusion Detection/Prevention capabilitiesThis section outlines the test cases needed to test the capabilities provided by the wireless LAN solution to protect the network from various kinds of threats and vulnerabilities on the wireless network. These capabilities are critical to ensuring the security and high availability of the network.2.1 Rogue AP (WEP) detection/classification/containmentTest case Test the capability of the wireless LAN solution to detect an un-trustedAP and classify it as being interfering (un=trusted AP not connected tothe network) or rogue (un-trusted AP connected to the network andtherefore being a security threat). The interfering/rogue AP must berunning WEP or WPA-PSK (not open-system).Equipment required 1 WLAN controller1 AP1 Third Party AP1 wireless client1 L2/L3 switch (optional)TopologyDescription and testing steps 1.Configure the WLAN switch and AP to be operational.2.Start the 3rd party AP and configure it to accept clients usingWEP or WPA-PSK, but do NOT connect it to the network.3.Verify that the WLAN solution detects the AP as an interferingAP.4.Connect the 3rd party AP to the switch and configure it toaccept client using WEP or WPA-PSK (as an example toillustrate that the WLAN solution can detect rogue APs that useencryption as well). Also configure the 3rd party AP NOT tobroadcast the SSID.5.Associate the client to the rogue AP and ping a destinationusing this connection.6.Verify on the WLAN switch console that the AP is detected andclassified as Rogue.7.Enable Rogue AP containment.8.Verify that the WLAN solution is able to shut down the APdetected as Rogue (no wireless client should be able toassociate and send traffic through this rogue access point). Expected results. The WLAN solution should be able to detect un-trusted access pointsand be able to detect whether this access point is connected to thenetwork or not. This determines whether the access point is a securitythreat or just the cause of interference.2.2 Ad-hoc networks detection and containmentTest case Test the capability of the wireless LAN solution to detect an ad-hocnetwork and classify it as being insecure if it detects the ad-hocnetwork as being connected to the network.Equipment required 1 WLAN switch1 AP2 laptops (supporting ad-hoc networks) with wireless NICs 1 L2/L3 switch (optional)TopologyDescription and testing steps 1.Configure the WLAN switch and AP to be operational.2.Configure two wireless clients to set up an ad-hoc network. Inthe first case do not connect either of these clients to thenetwork.3.Verify that the WLAN solution detects the Ad-hoc network as aninterfering Ad-hoc network4.Connect one of the wireless clients to the network using awired connection5.Verify that the WLAN solution detects and classifies the Ad-hocnetwork as being insecure by determining it is connected to the network.6.Enable Ad-hoc network protection and verify that the WLANsolution can shut down the Ad-hoc network when it is detected as being insecure.Expected results. The WLAN solution should be able to perform the following IDS/IPSactivities:1.Detect the presence of Ad-hoc networks2.Classify the Ad-hoc network as being interfering or insecure bydetermining if any of the clients is connected to the wirednetwork.3.Contain the Ad-hoc network by shutting it down.Note: some ad-hoc clients (Intel Centrino being most common) do notrespond properly to de-authentication packets and will also changechannels to avoid being contained.2.3 Blacklist WiFi client based on firewall violationsTest case Test the capability of the wireless LAN solution to detect an violationof firewall policies and automatically blacklist a client and prevent thatclient from associating to the wireless network.Equipment required 1 WLAN switch1 AP1 wireless client1 file server1 L2/L3 switch (optional)TopologyDescription and testing steps 1.Configure the WLAN switch and AP to be operational with guestaccess on an open-system SSID with permission to use HTTP and HTTPS with FTP denied and blacklisting if FTP is used.2.Associate the client to the guest SSID and authenticate to thecaptive portal3.Connect the file server to the network using a wired connection4.Verify that the wireless client can access the file server usingHTTP and/or HTTPS5.Attempt to access the file server using FTP6.Verify that the client cannot FTP files from the file server andthat the client is blacklisted from the WLANExpected results. The WLAN solution should be able to block FTP access and also blacklist the client from the WLAN. This is different from just blocking FTP at afirewall somewhere in the network after the WLAN controller as it isactually preventing the violating client from even access the WLAN.3. Performance and ScalabilityThis section covers the test cases that verify support for Mobility, Redundancy, QoS, and Load Balancing. NOTE: the roaming tests are extremely dependent on the client cards used and hence it is recommended that a variety of client cards be used for the mobility test cases. 3.1 Intra-VLAN roamingTest case Test to verify that a client can roam between access points managed by the same WLAN switch and present on the same wireless user VLAN. Italso aims to measure the time required for a client to roam betweenthe access points.Equipment required 2 APs1 WLAN switch1 wireless client1 L2/L3 switch between the WLAN switch and the APs (optional)TopologyDescription and testing steps 1.Configure a WLAN network with the test SSID and WPA2 and avalid user for authentication. (This can also be done with WPA, WPA-PSK or WEP as some clients may not have WPA2 driversbut also confirm that the WLAN system is WPA2 certified.)2.Connect the two access points on the same management VLAN –you can connect the AP directly to the WLAN switch or to aL2/L3 switch between the WLAN switch and the AP.3.Associate the client to the WLAN network. Note the AP that theclient connects to. Start a continuous ping from the wirelessclient.4.Shut down the AP that the client is connected to (NOTE: this isnot the a natural roaming scenario and therefore if possible,position the APs such that one of the APs is physically close to the wireless client while the other is farther away. Roamingcan then be tested by physically moving the wireless clientfrom one AP towards the second AP. Alternatively roaming can be induced by slowly placing aluminum foil over the APantennas to block the signal.)5.Measure the number of pings lost during the roam.Expected results. With a well designed client driver roaming should incur minimal packet loss. 802.1x authentication will incur some latency/loss on roaming.Note: roaming ping loss will be greater if performing the test byshutting down the access point.3.2 Inter-VLAN roamingTest case Test to verify that a client can roam between access points connected to the same WLAN switch and present on two different subnets/VLANs.It also aims to measure the time required for a client to roam betweenthe access points.Equipment required 2 APs1 WLAN switch1 wireless client1 L2/L3 switch between the WLAN switch and the APs (optional)TopologyDescription and testing steps 1.Configure a WLAN network with the test SSID and WPA2 and avalid user for authentication. (This can also be done with WPA, WPA-PSK or WEP as some clients may not have WPA2 driversbut also confirm that the WLAN system is WPA2 certified.)2.Configure the two access points to use different user VLANs forthe test SSID (e.g. AP1 assigns users to VLAN 10 while AP2assigns users to VLAN20). Connect the two access points onthe same management VLAN – you can connect the AP directly to the WLAN switch or to a L2/L3 switch between the WLANswitch and the AP.3.Associate the client to the WLAN network. Note the AP that theclient connects to. Start a continuous ping from the wirelessclient.4.Shut down the AP that the client is connected to (NOTE: this isnot the a natural roaming scenario and therefore if possible,position the APs such that one of the APs is physically close to the wireless client while the other is farther away. Roamingcan then be tested by physically moving the wireless clientfrom one AP towards the second AP. Alternatively roaming can be induced by slowly placing aluminum foil over the APantennas to block the signal.)5.Measure the number of pings lost during the roam.Expected results. With a well designed client driver roaming should incur minimal packet loss and the client should not obtain a new IP address. 802.1xauthentication will incur some latency/loss on roaming. Note: roamingping loss will be greater if performing the test by shutting down theaccess point.3.3 Secure Inter-switch mobilityTest case Test to verify that a client can roam between access points connected to two different WLAN switches It also aims to measure the timerequired for a client to roam between the access points.Equipment required 2 APs2 WLAN switches1 wireless client1 L2/L3 switch between the WLAN switch and the APs (optional)TopologyDescription and testing steps 1.Configure two WLAN controllers. One of the WLAN controllersas the master controller and the other is configured as a local controller.2.Configure a WLAN network with the test SSID and WPA2 and avalid user for authentication. (This can also be done with WPA, WPA-PSK or WEP as some clients may not have WPA2 driversbut also confirm that the WLAN system is WPA2 certified.)3.Configure one of the APs to connect to the master controllerand the other AP to connect to the local controller.4.Verify the validity of all configuration by associating a clientwith each of the APs and verifying connectivity5.Associate the client to the WLAN network. Note the AP that theclient connects to. Start a continuous ping from the wirelessclient.6.Shut down the AP that the client is connected to (NOTE: this isnot the a natural roaming scenario and therefore if possible,position the APs such that one of the APs is physically close to the wireless client while the other is farther away. Roamingcan then be tested by physically moving the wireless clientfrom one AP towards the second AP. Alternatively roaming can be induced by slowly placing aluminum foil over the APantennas to block the signal.)7.Verify that the client regains connectivity and retains the sameIP address and all application sessions are maintained intact. 8.Measure the number of pings lost during the roam. Measurethe time for lost connectivity during the roam if possible. Expected results. The WLAN solution maintains the sessions when the client roams across switches and subnets. The client still maintains the same user role andprivileges after roaming. With a well designed client driver roamingshould incur minimal packet loss and the client should not obtain a newIP address. 802.1x authentication will incur some latency/loss onroaming. Note: roaming ping loss will be greater if performing the testby shutting down the access point.3.4 Self-Healing – AP failure due to AP shut downTest case Verify how Vendor APs dynamically adjust their channel and power settings to compensate for a failed neighbor AP.Equipment required 1 WLAN controller4 APs1 Wireless Client1 L2/L3 Switch (optional)TopologyDescription and testingsteps 1. Configure the 4 APs and WLAN controller so that they are operational.2. Configure the APs to be on a 3 channel plan for 802.11bg (1,6, and 11)3. Have the APs dynamically choose their channel and power settings.4. Note down each Vendor AP’s channel and power setting after a couple of minutes.5. Have a wireless client associate to one of the APs and send a continuous ICMP ping6. Check what AP the wireless client is connected to and pull the power from that AP.7. After a few minutes have passed, check the channel and power settings of each AP.Expected results. First of all, the 4 APs should dynamically choose the best 802.11bg channels and power settings for their environment. After the one AP is powered down you should see some of its neighbor APs adjust to higher power settings (or even change 802.11 bg channel settings) to compensate for the failed AP without dropping more than a few packets from the wireless client’s session.3.5 Self-Healing – AP failure due to Radio failureTest case Verify how Vendor APs dynamically adjust their channel and power settings to compensate for an AP that has an Antenna or Radio failure.Equipment required 1 WLAN controller4 APsEnough aluminum foil to wrap one AP three times 1 L2/L3 Switch (optional)TopologyDescription and testingsteps 1. Configure the 4 APs and WLAN controller so that they are operational.2. Configure the APs to be on a 3 channel plan for 802.11bg (1,6, and 11)3. Have the APs dynamically choose their channel and power settings.4. Note down each AP’s channe l and power setting after a couple of minutes.5. Now cover one of the APs with aluminum foil (make sure it is well wrapped at least 3 times and if it the AP has any external antennas then remove them so that hardly any RF can be seen from that AP)6. After several minutes have passed after that AP was covered in aluminum foil, check the channel and power settings of each Vendor AP.Expected results. First of all, the 4 APs should dynamically choose the best 802.11bg channels and power settings for their environment. After the one AP is well covered in aluminum foil you should see some of its neighbor APs adjust to higher power settings (or even change 802.11 bg channel settings) to compensate for the AP that has its RF hampered or antennas removed.3.6 Controller RedundancyTest case Verify that the WLAN solution can offer a redundancy solution that helps the clients regain connectivity in an acceptable time in the event of a controllerfailure or loss of connectivity.Equipment required 1 AP2 WLAN controllers1 L2/L3 switch between Vendor’s WLAN switch and AP 1 Wireless client1 Workstation/ServerTopologyDescription and testingsteps 1.Configure a redundant topology between the two wireless LAN controllers.2.Verify that the access point is connected to one of the controllers.3.Associate the client to the access point. Run a continuous ping from theclient to a server to monitor loss of connectivity.4.Shut down the active switch or disconnect it from the network.5.Measure the time it takes for the client to regain connectivity through thebackup switch.Expected results. Ping loss should be minimal (2-3 pings in most cases) and the client should not get a new IP address with the failover.3.7 QoS prioritization of user-specified traffic on single SSIDTest case Verify that the WLAN solution can provide the ability to prioritize voice traffic over data traffic.Equipment required 1 AP1 WLAN Switch1 wireless client (configured as Iperf Client)2 VoWLAN handsets (that support SIP protocol)1 wired phone that supports SIP protocol (or wireless handset)1 L2/L3 switch between WLAN switch and APs (optional)2 Wired Desktop (1 configured as Iperf Server and 1 configured as SIP Server)TopologyDescription and testing steps 1.Configure SIP server to allow 3 SIP phones to communicate witheach other.2.Have all wireless devices associate to the same AP using the sameSSID.3.Have 1 VoWLAN handset configured with a QoS profile.4.Have the other handset and wireless device (iperf client)configured with no QoS profile.5.Configure and run iperf server with the following setting:iperf -s -u -t 300 -i 16.Configure and run iperf client with the following setting:iperf -c <IP address of iperf server> -t 300 -i 1 -u -b 256k7.Make a phone call from the wired SIP phone to the VoWLANhandset that has no QoS profile. (take note of the voice quality) 8.Make a phone call from the wired SIP phone to the VoWLANhandset that has a QoS profile. (take note of the voice quality)Expected results. The WLAN solution should demonstrate that the VoWLAN handset with no QoS profile has bad voice quality (choppy and not clear) to the wired SIPphone during high data traffic congestion while the VoWLAN handset witha QoS profile has great voice quality to the wired SIP phone even with thesame high data traffic congestion.3.8 Load balancing based on user thresholdsTest case Verify that the WLAN solution can perform load balancing on the basis of thresholds set for number of users per access point.Equipment required 1 WLAN controller2 APs3 wireless clientsL2/L3 switch between WLAN switch and APs (optional)TopologyDescription and testing steps 1.Position the APs such that one AP is close to the wireless clientswhile the other AP is “farther” away from the clients2.Enable load balancing on the controller.3.Set the user threshold to a number greater than 3.4.Connect the wireless clients one at a time. All three clients shouldconnect to the AP that is closer.5.Disconnect all clients from the AP.6.Change the user threshold to 2.7.Connect the wireless clients one at a time.8.Verify that the third client connects to the second AP.Expected results. Normal wireless NIC driver behavior is to associate to the AP with the strongest signal. Load balancing should cause any clients attempting toassociate after the threshold is reached on an AP to associate toanother available AP. Note: configurations that use “local proberesponse” will require this feature to be turned off for load balancingto operate, but voice call admission control will continue to work evenwith local probe response enabled.Load balancing based on bandwidth thresholdsTest case Verify that the WLAN solution can perform load balancing on the basis of thresholds set for bandwidth consumption on each access point.Equipment required WLAN controller2 APs3 wireless clientsL2/L3 switch between WLAN switch and APs(optional)TopologyDescription and testing steps 1. Position the APs such that one AP is close to the wireless clientswhile the other AP is “farther” a way from the clients2. Enable load balancing on the controller.3. Set the load balancing bandwidth threshold to about 5 Mbps4. Connect the wireless clients one at a time and start a large ftpdownload or video stream. All three clients should connect to the AP that is closer.5. Disconnect all clients from the AP.6. Change the load balancing bandwidth threshold to 2 Mbps7. Connect the wireless clients one at a time and start a large ftpdownload or video stream with each passing about 1 Mbps of traffic 8. Verify that the third client connects to the second AP.Expected results. Normal wireless NIC driver behavior is to associate to the AP with the strongest signal. Load balancing should cause any clients attempting toassociate after the threshold is reached on an AP to associate toanother available AP. Note: configurations that use “local proberesponse” will require this feature to be turned off for load balancingto operate, but voice call admission control will continue to work evenwith local probe response enabled.。