Do you need a voice VLAN?

I’ve had three conversations in the past week or so around whether a voice VLAN is required or recommended for use with Skype for Business. Let’s take a quick look at where the concept of voice VLANs came from, what they can do for you, and whether you need them for your SfB deployment.

The idea of a voice VLAN first came about when the only IP endpoint for you IP PBX was a phone on their desk. The phones generally needed a specific DHCP configuration, and if the phones were in their own VLAN this was easier to do. QoS was implemented as 802.1p at the layer 2 (switch) level, and it was much easier to simply say “this voice VLAN gets a priority of 5”. Some switches would use Cisco Discovery Protocol (CDP) or Link-Layer Discovery Protocol (LLDP) to automatically put a device that said it was a phone into the voice VLAN. Much of this early IP telephony was done with voice guys coming from a traditional TDM PBX environment. The world of IP was new to them, so anything that made their lives easier and more automatic was welcomed by not only the voice guys, but also by any IT guys who had to work with them.

Raise your hand if you ever had to explain IP subnetting to your voice guys new to IP, and try to sort out for them why the IP telephone system vendor was blabbering on about Class A subnet masks and VLAN 0. Thankfully for me, my voice guys were smarter than your average bear and quickly picked up some good habits vs the drivel in the phone vendor manuals. (Thanks Brian and Willy!)

The curious thing is that at no point did anything actually require a voice VLAN. They just made life a lot easier and more “automagic”. You could deploy a perfectly good VoIP solution without using voice VLANs.

Fast forward to today, when we talk about Unified Communications instead of IP telephony. We now have soft clients, room systems, and mobile clients. In additional to voice, we have modalities like video, web conferencing and screen sharing, all from the same client. We’ve also got BYOD and Cloud technologies to add excitement to the mix.

Having your desk phones into a voice VLAN doesn’t provide any benefit to you when you’re conferencing from a PC, or watching a PowerPoint on your iPhone in the lunchroom while you wait for the coffee to finish brewing. A good number of your users might not even have a desk phone, opting instead for a headset and soft client.

One scenario where a voice VLAN does make some sense, is when you’re doing a large-scale deployment and the number of phones you are adding outstrips the number of available IP addresses on your existing subnets. In this case, it may make sense to create a new VLAN for the phones. I say “may” as you might also have a requirement to use IP subnets for location determination for emergency calling. Overlaying a single voice VLAN to cover your site may not be suitable – you may have to deploy multiple voice VLANs to provide the location granularity required. It may make more sense to simply further partition your network into general purpose user VLANs.

Do I recommend voice VLANs? No. I think they’re a thing of the past. They add complexity to your network, increase your administration, and affect only a very small number of your UC endpoints. For those endpoints that they do affect, they do not offer any benefits that can be provided via other means, and often those other means will need to be in place for other endpoint types and other modalities.

Bad Checksum in Packet Captures

I was working with a carrier to identity some SIP trunk issues recently, and they requested a packet capture of the traffic leaving our Mediation servers. I sent the capture over, and they quickly came back with a question: Why are all of the packets marked as “Bad Checksum” in NetMon.


As it turns out, this isn’t anywhere near the disaster that the carrier thought it was. If we open the same capture in Wireshark, we can see that Checksum validation is disabled.


This is expected when you are running your packet capture on a host that is generating or receiving the traffic you’re interested in (versus setting up a span port on a switch and mirroring traffic to a dedication packet capture machine). The reason? The packet capture takes place within the network driver stack, while checksums are almost always offloaded to hardware. For outgoing traffic, the packet is captured before the checksum is calculated, and there is no valid checksum available to include in the packet capture.

Here’s handy diagram courtesy of that shows the network stack and where the Packet Capture and Checksum take place. (Red arrows and boxes)

First with Offloading:


Packet capture with Offloading

And now without Offloading:


Packet capture without Offloading


If you’re not capturing packets to detect and correct malformed packets, this shouldn’t be of concern to you. If you need checksums, you have two options. One is to select your network adaptor, choose Properties, and on the Advanced tab, find all of the “Checksum Offload” properties and set them to Disabled (don’t do this). The other use a span port on a switch to mirror traffic to a dedicated capture PC (do this instead). Setting Checksum Offload to disable means you will take a performance hit, as you are no longer using the hardware on the NIC to perform these calculations. If you absolutely cannot do a span port, disable Checksum Offload with caution and be sure to re-enable it immediately after you’re done.


Happy packet capturing!

Cool tool – MAdCaP manager for analog and common area phones

Let’s face it, creating Common Area Phones (CAPs) and Analog Phones in Lync is annoying. Managing them is even more annoying. Greig Sheridan has the answer with MAdCaP (“Manage Analog Devices & Common Area Phones”).

MAdCaP allows you to create and edit Common Area Phones and Analog Devices as the name implies. This includes the little details like setting the correct dial plan, voice policy, client policy, and PINs.

This is a great tool for an Admin who’s in charge of phones, but has zero idea what PowerShell is. I’ve also found it handy at the end of a very long day when my brain simply won’t do PowerShell commands.

Cool tool – IIS Crypto

Every once in a while, a Lync admin gets to experience the true horror of changing crypto settings. More often than not, this is through following a series of registry edits found online, either on TechNet or a helpful looking blog.

IIS Crypto is a tool that allows you to fiddle with the protocols, cyphers, hashes, key exchanges and cypher suite order, all in a nicely put together GUI. Better yet, there are templates that’ll set your server to Best Practices, PCI, FIPS140-2, and Windows Defaults. That last one comes in really handy when that helpful looking blog turns out to be not so helpful, and your notes on what keys you changed in RegEdit aren’t so clear.

Cool tool – Mirror Manager

Most Lync admins aren’t closet SQL admins, and things like “mirror” and “witness” sound more like “dragon” and “bear” than “puppies” and “beer”. When you throw in other mirroring language that’s eerily similar – principal, primary, secondary and mirror I’m look at you – it can be too much. Thankfully, James Cussen has whipped up an excellent tool that will display which database is being used, and with a few clicks, it whips up the PowerShell for you to move things around. This is a great tool to have handy for a Disaster Recovery scenario, in case the person executing the DR plan isn’t a PowerShell, Lync, and Mirror guru.

Cool tool – check the difference between two files

Comparing two files to try and find differences is something I consider to be an occupational hazard. You can dive into the weeds and run some command line tools, you can pop the files into Word, if you’re doing the comparison on a PC. If you’re trying to do a comparison on a server, you probably don’t have Word.

Diff Checker is an online diff tool that allows you to compare two text files. Any differences in the file are colour-coded so that you can easily spot them.