Subnetting a wireless LAN for voice

Editor's Note: Because you can never have too many wizards, we have expanded the scope of the Wireless Wizards to include a full panel of experts from the top wireless vendors. They’re at your disposal to help answer wireless LAN questions, so send  your queries to

Question: We're currently implementing a WLAN that is expected to support up to 2,000 wireless voice users in a single campus. Part of the requirement is to provide seamless voice and inter/intra subnet roaming. Is there a rule of thumb about the size of the subnet to design in order to have seamless roaming on a campus network wherever there is contiguous RF signal? We don't think it's possible to have one flat voice network, as our vendor is recommending. - Mike

Dan Simone, Trapeze Networks:

Your instinct is correct. Supporting thousands of wireless users in one flat subnet - whether voice or data users - is clearly not scalable. It is also cumbersome to propagate a single subnet everywhere across a campus. Experience on wired networks proved this - it doesn’t get better with voice applications on small CPU handsets using the limited bandwidth of 802.11b. With large subnets, you end up with a significant number of broadcasts in each domain, impacting performance. For VoIP applications in particular, you have small CPU-powered devices that can be broadcast intensive, so too many users in one VLAN will quickly degrade performance and increase latency, leading to poor-quality voice calls.

The appropriate size for a subnet primarily serving voice users depends on how the wireless VoIP phones work, and what features you intend to use. If a call center application is used, it's possible to reduce your subnet sizes into something far more manageable and practical (e.g., 255 or 127 users per subnet). Critical to making this work is the ability of the wireless kit to provide a "real" inter-subnet roaming function across the campus with roam times (including authentication and authorization) at about 50ms or less.

Since all users cannot reside in the same subnet, the architecture of the WLAN system will need to support subnet roaming very effectively. The architecture should permit users of any subnet to roam anywhere in the WLAN, unless specific IT policies forbid access in certain network areas. Also, the WLAN system should enable subnet roaming without introducing new routing protocols, such as Mobile IP, and without the need for changing the wired backbone, to propagate all the voice VLANs across the backbone.

Look for a system that can preserve your existing backbone configuration, letting you add voice subnets at the size you see fit. Then make sure it can dynamically support those subnets and quality-of-service signaling wherever your users roam, regardless of what subnet the access points are attached to. This enables full mobility no matter where the traffic comes into the wired network. - Dan Simone, Trapeze Networks.

Dr. Vaduvur Bharghavan, Meru Networks:

In a data network, typically it is recommended to partition the network into smaller subnets in order to reduce the broadcast traffic. Broadcast traffic is sent to all systems on the LAN subnet. This reduces the performance of the network as it grows, and the broadcast traffic grows with the number of users. Broadcast traffic also can affect end systems, since they are required to interpret a greater number of packets received.

The most common types of broadcast packets are Address Resolution Protocol (ARP) requests and NetBIOS. ARP (RFC 826), which makes up the majority of broadcasts, is used by end systems to determine the MAC address of another system to which you are sending an IP packet. Using ARP, your system will send out a broadcast message to all systems on your subnet, asking who has the IP address you are trying to send a packet to. Each receiving system looks at the request and determines if the requested IP address is its address, and if so, sends a reply. In a large network that hasn't been broken into smaller subnets, this introduces a significant amount of traffic into the network. By breaking the network into smaller subnets, you can limit the broadcast traffic to smaller areas of the network, and utilize a gateway/router to forward packets between the different subnets.

The common recommendation for subnet size is 254 hosts (also known as a "/24" subnet); however, this is not a hard and fast rule. You can choose a larger or smaller subnet size depending on the amount of broadcast traffic you expect.

Some WLAN switch architectures eliminate this need for smaller subnet segments, as they manage the broadcast domains intelligently to limit the broadcast traffic such as ARP requests, preventing the broadcasts from being sent out to all hosts. This is particularly important for wireless systems, since the bandwidth on the air is limited. Reducing the number of unnecessary packets transmitted is very important in order to improve your network performance.

When you break the wireless network into multiple subnets, you need to ensure that your WLAN switch and access points can support near zero inter-Access Point handoffs, as well as subnet roaming throughout the network. This is particularly critical for a wireless voice deployment, where you don't want users to suffer disruptions in conversations while they walk around and the phone moves from one access point to another. The issue for large-scale deployments (2,000 voice clients) is that voice is a more demanding application than data. Missed or delayed packets, while not so bad for data traffic, can destroy a voice call.

In 802.11, it is well known that the clients decide when and where to associate and hand off, and that they do so independent of each other. In a large-scale pervasive deployment, such as yours, this causes the “ping-pong” effect, where clients spend much of their time flopping from access point to access point, rather than transmitting or receiving data. Voice cannot afford the loss (too many handoffs, or handoffs taking more than a few milliseconds), or the call becomes unacceptably poor. This is because the voice stream is a digital sampling, with each sample being taken typically every 30ms. If a packet is lost, the signal can’t completely recover, and the result is poor voice quality. In a worst-case scenario, this loss may cause a dropped call. In a pervasive deployment, there will be hundreds of access points, which means during the course of a single voice conversation your VoIP handset could switch between access points many times. If the inter-Access Point handoff is more than a few milliseconds, your help desk will be inundated with calls complaining about the quality of the phone. In reality, the problem is almost never the phone, but the WLAN infrastructure.

Pat Calhoun, Airespace:

Deploying a wireless network does not have to impact your existing IP subnet design; the two are completely independent. However, you may decide to put wireless users on different subnets than your wire line users. The choice is yours.

A common approach is to create an overlay for your wireless infrastructure. This overlay can have different subnets, or be one large subnet, but basic IP network design principles apply; most people wouldn’t place more than 2,000 802.3 users on a single subnet, so why do this on a WLAN? To put it another way, subnet size should not be a mobility issue, regardless of whether your primary wireless application is voice or data.

The key to mobility is being able to track the movements of a client device from access point to access point, and then forward packets accordingly without forcing a user to get a new IP address. Within a single subnet, this can be accomplished using client MAC addresses. However, this approach is not scalable beyond a single subnet, and limits the administrator’s ability to effectively manage the network.

For roaming across subnets, a wireless product must be capable of tracking a client device’s movements at Layer 3 using IP addresses. What’s more, the infrastructure has to perform some basic IP connectivity functions (e.g. ARP) on behalf of the client so that the existing IP infrastructure is not aware of client mobility. One approach to this problem is to implement proxy Mobile IP, but this is complex to configure, requiring changes to the LAN routing infrastructure. Mobile IP has problems with network discovery and timing, causing breaks that can last several seconds and result in loss of session persistence, which would ultimately harm your voice over WLAN application.

Another more elegant approach to mobility leverages a different signaling mechanism, often referred to as "edge tunneling." In this method, the wireless switches are responsible for tracking roaming clients. Through the use of LWAPP tunneling coupled with edge tunneling, the physical location of the client IP address is hidden from network routing. Regardless of where the mobile client device connects to the network, the wireless switches treat the client like it never moved, enabling seamless mobility. Connections can be maintained across several subnets by groups of wireless switches automatically establishing mobility tunnels between one another. There are no changes needed on the underlying network infrastructure.

Israel Drori, Legra Systems:

There's no rule of thumb for subnet size, so don't worry about that. If you have 2,000 users, plan your overall capacity with one switch supporting 60 radios, which will provide enough connectivity for all of your users. It is possible to have one flat voice network for 2,000 users, but it's not advisable. You can plan and implement a WLAN to support 2,000 wireless voice users in a campus without limiting yourself to a flat voice network. Don't treat your WLAN voice users differently than you would any other network users. Subnet them according to the same divisions that apply elsewhere on your network - marketing, engineering, sales etc. - and set roaming policies that grant access to users as they move from one area to another. Consider a system that lets you connect different radios over Layer 3 to multiple switches on the back end.

Keerti Melkote, Aruba Networks:

The historical rule of thumb for the size of the subnet has been a /24 – i.e. 254 hosts on a single subnet. This is how most enterprise IP networks are architected, and you should not violate this rule for doing wireless voice or wireless data for that matter. In the past, wireless network designs called for flattening the subnet space to accommodate for the lack of inter-subnet roaming. However, this limitation has largely been addressed by many vendors in the industry.

The architectural choices you make in implementing your WLAN are perhaps the most significant here. The primary decision is based on a fat access point architecture vs. a WLAN switch architecture. If you already have a fat access point-based WLAN, the best thing to do would be to aggregate these access points onto different /24 VLANs that terminate on a WLAN switch or appliance that can handle inter-subnet roaming for fat access points. There are many proprietary approaches to the inter-subnet mobility problem. So buyer beware. Systems based on Mobile IP are at least standards-based, even if they have proprietary extensions, so there is at least some chance of future interoperability between vendors.

However, if this is a Greenfield deployment and you have not deployed any access points at all, WLAN switch architectures are better suited for large WLAN deployments such as yours. WLAN switches centralize the security, packet processing and RF management functions and provide visibility into all layers of the protocol stack. Therefore, ensuring that voice traffic gets the priority it needs over the air and in the network is something only a WLAN switch architecture can uniquely do.

Learn more about this topic

Researchers see trouble ahead for WLAN performance

IDG News Service, 07/31/03

How users share 802.11 channels

Network World Wireless in the Enterprise Newsletter, 10/01/03

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10