Network Preparation: VLANs, QoS, and the Foundation Work

The MSP's Guide to VoIP: Part 7 of 20

You have assessed the client's network. You have chosen a platform. You have had the internet conversation and whatever upgrades were needed are either in place or ordered. Now comes the part where you actually prepare the network for voice traffic, and this work should be finished before the first phone arrives on site.

The difference between a voice deployment that works cleanly from day one and one that generates tickets for the next three months almost always comes down to what happens in this step. Rushing through network preparation to get phones on desks faster is one of the most common mistakes MSPs make with voice deployments, and it is one of the most expensive to fix after the fact.

The voice VLAN

If there is one thing you take from this post, let it be this: voice traffic should be on its own VLAN. This is not optional for any deployment beyond a handful of phones in a very small office.

A voice VLAN gives you four things that matter.

Traffic isolation. Voice packets and data packets travel on logically separate networks. A large file transfer between two workstations does not compete with voice traffic at the switch level. A broadcast storm on the data network does not take down the phones. The two networks coexist on the same physical switches but cannot interfere with each other.

QoS enforcement. With voice on its own VLAN, you can apply QoS policies specifically to voice traffic. The switch can prioritize everything on the voice VLAN without needing to inspect each packet to determine what it is. This is simpler to configure and more reliable than trying to identify voice traffic by DSCP markings alone.

Security. Phones on a separate VLAN cannot be reached directly from devices on the data VLAN without passing through a router or layer 3 switch, which means you can apply access control rules between the two. This reduces the attack surface and prevents compromised workstations from directly accessing phone configuration interfaces.

Troubleshooting simplicity. When a call quality problem occurs, you can immediately determine whether the issue is internal to the voice network or external. If the voice VLAN is clean (no errors, no congestion, no drops), the problem is upstream of the switch. This saves hours of diagnostic time compared to trying to untangle voice and data traffic on a flat network.

Setting up the VLAN

The general process works the same regardless of switch vendor. Create a new VLAN and assign it an ID. Convention varies, but VLAN 100 for voice is common. Give it a descriptive name. Configure each switch port that connects to a phone as a trunk or voice port that carries both the voice VLAN (tagged) and the data VLAN (untagged). The phone uses the voice VLAN for its own traffic and passes the computer's traffic through on the data VLAN.

Most IP phones discover their VLAN assignment automatically through LLDP-MED or CDP. You configure the voice VLAN on the switch port, and the phone picks it up during boot. Some environments use DHCP options to communicate the VLAN ID to the phone instead.

On the routing side, you need inter-VLAN routing so that the voice VLAN can reach the internet (for hosted VoIP) or the PBX server (if it sits on a different VLAN). This is typically handled by the main router or a layer 3 switch. Configure a gateway address for the voice VLAN subnet and ensure routing between the voice and data VLANs is in place, with appropriate firewall rules between them.

IP addressing

The voice VLAN gets its own subnet. If your data network is on 192.168.1.0/24, put voice on something like 10.10.10.0/24. Keeping the subnets distinct makes firewall rules, QoS policies, monitoring, and troubleshooting straightforward because you can identify traffic by its source subnet.

Size the subnet for growth. A /24 gives you 254 usable addresses, which is more than enough for most deployments. Even if the client has 50 phones today, the overhead of a /24 is zero and it means you will not need to re-subnet later.

QoS configuration

With the voice VLAN in place, QoS becomes straightforward. The goal is to ensure that voice packets are always prioritized over data traffic, particularly at the points where congestion is most likely to occur.

On the switches

Configure the switch to trust DSCP markings from devices on the voice VLAN. Most VoIP phones mark their packets with DSCP 46 (Expedited Forwarding) by default. The switch should place these packets into a strict priority queue so they are forwarded before any other traffic.

If the switch supports it, configure it to remark any traffic on the voice VLAN that is not already marked with DSCP 46. This provides a safety net in case a phone's DSCP configuration gets changed or a device on the voice VLAN sends unmarked traffic.

On ports that connect to the data VLAN, you can optionally set DSCP 0 (best effort) for all traffic to prevent data devices from marking their traffic as high priority and bypassing the QoS system.

On the router

This is where QoS has the most impact, because the router is the bottleneck where your gigabit internal network meets the client's internet connection. Configure the router's outbound interface (the WAN-facing interface) with a QoS policy that does the following:

Create a strict priority queue for traffic marked with DSCP 46. Reserve bandwidth for this queue based on the maximum number of concurrent calls expected, plus a margin. Each G.711 call uses approximately 85 to 100 kbps in each direction, and you can use a Bandwidth Calculator to size the reservation precisely for the client's codec and call volume. If the client expects a maximum of 20 concurrent calls, reserve at least 2 Mbps of upload bandwidth for the priority queue.

Cap the priority queue to prevent it from consuming all available bandwidth in an abnormal situation. A cap of 30 to 40 percent of the total upload bandwidth is a reasonable starting point.

Assign remaining traffic to a best-effort queue that gets whatever bandwidth is left after the priority queue is served.

For a detailed treatment of how QoS works at a conceptual level, including the different queuing strategies and their trade-offs, see the QoS post in the VoIP From the Ground Up series.

Firewall configuration

VoIP requires specific ports and protocols to be allowed through the firewall. Get any of these wrong and calls will either fail to connect or connect with no audio.

SIP signaling

SIP signaling typically uses UDP port 5060 or TCP/TLS port 5061. The exact ports depend on the VoIP provider or PBX configuration. Allow outbound traffic from the voice VLAN to the provider's SIP servers on the appropriate ports. For hosted platforms, the provider will document the specific IP addresses and ports to allow.

RTP media

RTP audio uses a range of UDP ports. The range varies by configuration but is commonly something like 10000 to 20000, or 16384 to 32768. This is a wide range because each call uses a dynamically assigned port within the range. Allow outbound and inbound UDP traffic on this range between the voice VLAN and the provider's media servers.

For on-premises PBX deployments, the RTP port range is configured on the PBX and should be as narrow as practical while still accommodating the maximum number of concurrent calls (each call uses two ports per endpoint, one for RTP audio and one for RTCP control).

SIP ALG

Turn it off. SIP ALG (Application Layer Gateway) is a feature on many routers that attempts to modify SIP messages as they pass through NAT. The intention is to fix the NAT traversal issues that SIP inherently has. In practice, most SIP ALG implementations are buggy and cause more problems than they solve: corrupted headers, failed registrations, one-way audio, and random call drops.

Every major VoIP provider and PBX vendor recommends disabling SIP ALG. The mechanisms that modern VoIP systems use to handle NAT (STUN, registration keep-alives, and SIP outbound proxy) work correctly without SIP ALG and break when SIP ALG interferes with the messages.

Finding the SIP ALG setting varies by router manufacturer. It might be called SIP ALG, SIP Passthrough, SIP Transformations, or SIP Helper. Some routers bury it in an advanced NAT configuration section. Some require a CLI command to disable it. Check the manufacturer's documentation for the specific router model. For the full technical explanation of why NAT and SIP interact poorly, see the NAT traversal post.

NAT considerations

Ensure the router's NAT timeout for UDP connections is at least 60 seconds, and preferably longer. SIP registrations use UDP, and if the NAT entry for a phone's registration expires before the phone sends its next keep-alive, the phone becomes unreachable for inbound calls. Most phones send keep-alive packets every 30 seconds by default, but if the NAT timeout is shorter than the keep-alive interval, the phone will intermittently lose connectivity.

DHCP for the voice VLAN

The voice VLAN needs its own DHCP scope with settings tailored for phones. At minimum, configure:

IP address range and subnet mask. Standard DHCP pool configuration for the voice VLAN subnet.

Default gateway. The router or layer 3 switch interface for the voice VLAN.

DNS servers. Reliable DNS is important for VoIP because phones and PBX systems often use hostnames to reach SIP servers. If DNS resolution is slow or unreliable, phones will experience registration delays and call setup failures.

Option 66 (TFTP server). This tells the phone where to download its configuration file. For auto-provisioning, this is the address of the provisioning server, which might be hosted by the VoIP provider, running on the PBX, or on a separate provisioning appliance on the network.

Option 67 (boot file name). Some phones use this to determine which configuration file to request from the provisioning server.

NTP server (option 42). Phones need accurate time for call logs, voicemail timestamps, and display. Pointing them to a reliable NTP server ensures consistent timekeeping across all devices.

The specific DHCP options required depend on the phone manufacturer and the provisioning method. Polycom, Yealink, Grandstream, and Cisco phones each have their own provisioning expectations. Consult the phone manufacturer's deployment guide for the exact options needed.

Testing the prepared network

Before any phones arrive, verify that the network preparation is correct.

VLAN verification. Connect a laptop to a voice port and verify it receives an IP address from the voice VLAN DHCP scope. Verify it can reach the internet through the voice VLAN gateway. Verify it can reach the VoIP provider's SIP servers.

QoS verification. Generate traffic from the voice VLAN and verify that it is being prioritized at the router's outbound interface. Some routers show queue statistics that let you confirm traffic is hitting the priority queue.

Firewall verification. From a device on the voice VLAN, test connectivity to the VoIP provider's SIP servers on the appropriate ports. A simple telnet or nc test to the SIP port confirms the firewall is allowing traffic through.

DHCP verification. Verify that a device on the voice VLAN receives all the correct DHCP options, including the provisioning server address. If possible, boot a single phone on the voice VLAN to verify it retrieves its configuration.

Ping and jitter test. From the voice VLAN, run an extended ping test to the VoIP provider's server to baseline latency, jitter, and loss, or run a VoIP quality test to get MOS, jitter, and packet loss measurements in a single pass. Run it for at least 15 minutes during business hours. The results should match or improve upon the numbers from your network assessment, since QoS is now in place.

Documentation

Document everything you configure. For every client, maintain a network document that includes:

• VLAN IDs and names (voice VLAN, data VLAN, any others)
• IP subnets for each VLAN with gateway addresses
• DHCP scope ranges and options
• QoS policy details (DSCP markings, queue configurations, bandwidth reservations)
• Firewall rules related to VoIP (ports, protocols, source/destination)
• SIP ALG status (off, and a note about why)
• NAT timeout settings
• Switch port assignments (which ports are configured for voice)

This document saves hours when troubleshooting problems later, when onboarding a new technician to the account, or when the client moves to a new office and you need to replicate the configuration. The time spent documenting now is time saved many times over later.

The network is now ready. In the next post, we move from infrastructure to devices and cover how to get phones configured and deployed without manually touching each one.

Next up: Phone Provisioning at Scale, covering auto-provisioning, templates, firmware management, and the logistics of deploying phones by the dozen.