Problem solve Get help with specific problems with your technologies, process and projects.

How to handle softphones when keeping voice and data on separate VLANs

Unified communications expert Matt Brunk answers a reader's follow-up question about handling softphones when you've decided to split voice and data traffic on two separate VLANs.

I just read the article, "Alternative to keeping data and VoIP traffic on separate VLANs," and had a follow-up...

question. If it's been decided to split voice and data into two separate VLANs, then how do you handle softphones? You don't want to add the PCs to the voice VLAN, since that could influence the quality of the voice VLAN, and it's also not a good idea to keep those PCs on the data VLAN.

Background question, from the original article:

If it takes an extra NIC and switch port to separate the softphone VoIP traffic from data traffic from the same workstation, it will be a hard sell in an enterprise environment. Any secure, yet economically justifiable alternatives?

Listen, I went through the dual NIC and extra switch port thing back in 2002 with the 3Com NBX 100 because we wanted to come up with better quality voice. We added a second NIC to the PC, and patched the PC to LAN Port 1 and the second NIC for the softphone to LAN Port 2 on the data switch. Port 1 was set as VLAN1 (Data) and Port 2 was set as VLAN2 (Voice).

We had "routing" between VLANs, too, using an integrated access device to route traffic between VLANs. It worked well. But as you will discover, using two cables (physical) and two switch ports in a LAN switch created greater hardware requirements, which also increased power and cooling requirements. The hook in this ideology is the PC or workstation you select. The PC/workstation remains where most problems lie, anyway, so while the dual NIC is fanciful, in the end, it's just more stuff to support.

Not long ago, I made mention of building a better mousetrap, referring to the PC -- that actually means the operating system (OS), though, because that's where issues with improving softphone performance lie most of the time. The softphone was not the greatest tool back in 2002, and if you didn't recognize this, then you might have been sorely disappointed. Softphones weren't rock-solid replacements for desktop phones; they were tools. And while they were especially useful for remote workers/telecommuters, you wouldn't want to give one to your boss (or me) because you may have found that it was the last time you gave us anything.

Now, fast forward to the present day. A lot has changed since then -- the gear is better, the software is better, etc. -- but still, please remember, softphones are what they are.

During a recent campus implementation, the issue of security and convenience of moves, adds and changes came up, so I reached to out my friend John Bartlett of NetForecast Inc. John is the subject matter expert here, and his answer rocks!

Responding to my questions on Aug. 25, John wrote:

The VLANs 'contain' the PC traffic (keep it separate) and [do] the same with the voice at the logical level. This means that if the PCs get a virus and start babbling, or if someone accidentally creates a loop on the PC VLAN, that those packets won't flood the phones. But if the phones are literally on the same port as the PC, they will still see the traffic, they will just be able to discard it at a lower level.

VLAN isolation does not help with the QoS problem, because even though traffic is in different VLANs, it is still using the same physical queues in the switches. The VLANs give it logical isolation, but not isolation from a competition and timing point of view. So the bursts of traffic from normal or infected PCs can still impact a voice call.

If the VLAN for voice is given priority as well, then it gets the appropriate timing isolation. Thus I am always promoting QoS in the LAN (albeit often ignored).

In short, you can have softphones residing on the LAN (VLAN) and get logical isolation, but you've got to have QoS instated properly so that if/when the PCs go south because of some virus or malware, the voice packets still get priority over the data (LAN) traffic and don't get stuck in queue. But this is not the only reason -- PC or data LAN traffic can get stuck in queue, whereas you want voice traffic to be as close to real-time as you can get all the time. LAN data traffic can resend, but real-time voice can't, so QoS and the prioritization of traffic matters all the time, not just during virus/malware outbreaks.

And, to be clear, this does not cure the PC or the OS of the PC. The inherent issues of the PC do not go away when using softphones.

Dig Deeper on IP Telephony Systems