This white paper discusses the constraints imposed by WAN links in remote office wireless systems and highlights the two basic benchmarking tests, throughput and roaming latency, for such configurations.
Wireless LANs (WLANs) have become more popular in enterprise applications. In a situation where a corporation does not want to install a separate wireless solution for a branch office, a remotely installed access point (AP) that can handle several users and use the corporate network for other needs such as security, logging, and software upgrade, has become more popular. The branch office network is connected to the central office network over the WAN links. A typical scenario where a Frame Relay serial WAN link is used, is shown in Figure 1.Figure 1: A typical WLAN setup for a remote branch office
Performance testing involves a measurement of attributes that show how the system behaves when loaded to maximum capacity. Standard performance measures, such as throughput, roaming delays, and scaling, are at the heart of every performance test for wireless equipment. However, these parameters can be impacted severely by the topology under which the equipment is deployed. This document focuses on one such topology where bandwidth plays a more important role that affects standard performance measures.
This white paper highlights several important constraints and techniques used to resolve these, and tests wireless performance over WAN links in a controller-based architecture.
This section highlights the major constraints in a remote-office topology.
The AP uses a hello packet, also known as the heartbeat, in order to communicate with the controller. In an event where this heartbeat is lost, the AP rediscovers the controller. During this process, all the clients that exist are de-authenticated. This causes disruption of the wireless services at the branch office. Therefore, one of the goals of testing over the WAN link is not only to keep the heartbeat alive, but also take into account the effect on the overall performance of the system.
The default heartbeat interval is 30 seconds and it cannot be configured manually. When a heartbeat acknowledgement from the controller is missed, the AP resends the heartbeat up to 5 times at 1 second intervals. If an acknowledgement is not received after 5 retries, the AP declares the controller unreachable and searches for a new controller.
One of the techniques used in this testing is traffic prioritization. This keeps the heartbeat alive in order to avoid any service disruption. The AP uses two UDP ports in order to communicate with the controller. The AP uses UDP port 12223 for all management packets and 12222 for the data packets. If the communication via port 12223 can be kept up, the link between the controller and the AP functions even under severe traffic load across the WAN link. This is usually implemented on the WAN router ports that point to the WAN clouds.
ip cef ! frame-relay switching ! class-map match-all 1 match access-group 199 ! policy-map mypolicy class 1 bandwidth 64 ! interface Serial0/0 ip address 188.8.131.52 255.255.255.0 encapsulation frame-relay clock rate 512000 frame-relay interface-dlci 101 frame-relay intf-type dce service-policy output mypolicy ! access-list 199 permit udp any any eq 12223
In a general deployment, as shown in Figure1, the authentication is performed at the central office where all the authentication servers are hosted. A local authentication server kept at the remote office is not advisable from a cost and maintenance point of view. If the controller becomes inaccessible for any reason, the traffic can be bridged locally. However, because there is no local authentication server, only open and Wi-Fi Protected Access (WPA) authentication types are supported locally. For most of the customers, WPA forms the only authentication type available. This becomes a severe constraint in the design of remote-office wireless applications.
This section analyzes the effect of these constraints on system performance.
As mentioned earlier in this document, the throughput is severely impacted by the bandwidth available on the WAN link, as well as the traffic prioritization. If you assume that a fixed bandwidth on the WAN link of 512 kbps is available with a traffic prioritization channel of 64kbps, the data bandwidth available is 448 kbps. However, when you see the throughput up to 501 kbps, you might believe that the 64 kbps is pre-emptive instead of a dedicated channel.
Frame sizes add another twist to this. From this table, the effect of the WAN link and the frame sizes in a topology such as this is clear. This table also shows the comparison with the APs connected in the central office. Also, the throughput is measured when the clients in the remote branch office try to send data to a wired client in the central office.
|Frame Sizes (in bytes)||Throughput with APs connected in the central office (bits/sec.)||Throughput with APs connected in the remote office (bits/sec.)|
As you can see from this table, the throughput increases with the frame size until the frame size becomes 1280 and then drops back to 1450 bytes. This is due to the fragmentation that occurs for frame sizes more than 1418 bytes in controller-based architectures.
From the previous discussion, the effect on roaming delays is understood. This table displays the actual data. It was observed that the roaming delays were much less when the APs were connected to the switch via a hub.
|Authentication||WAN Link Present?||Avg. Roaming Delay (in msec)|
In a remote branch office setup, the bandwidth offered by the WAN link plays a crucial role in the decision of the performance of the equipment. Not only is there a need to perform traffic prioritization, but the effects on the throughput and roaming are an issue. The WAN link determines the benchmarking that needs to be performed. These tests differ significantly from the standard benchmarking tests. Also, because there is no local authentication server, WPA is the preferred security type for such applications. The WAN link capacity and the security type are important factors to be considered when you test such applications.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.