Skip navigation
Cisco Learning Home > Connections > Discussions


This Question is Not Answered 1 Correct Answer available (4 pts) 2 Helpful Answers available (2 pts)
16556 Views 8 Replies Latest reply: Jul 17, 2012 8:58 PM by kevin RSS

Currently Being Moderated

IP Phones connected to PC's and using a Voice VLAN...?

Jan 21, 2010 1:37 PM

jcoyan 1 posts since
Jul 29, 2008
This has been bugging the **** out of me as of late and I was hoping someone here could possibly shed some light on it for me...

As is common with IP phones now, they generally have a switchport on the back for you to plug your PC into. From all the research I've done, it seems to be recommended that you place your phones into their own separate VLAN.

This is accomplished by creating a type of trunk link between the switch and phone, allowing the link to pass traffic for both the PC and phone.'s what I'm struggling with. How does placing the phones in their own VLAN "protect" anything when broadcasts sent from any PC will still hit the phone first, then the PC? I get the outgoing traffic will be tagged in the Voice VLAN, but that doesn't really seem to help protect the traffic.

Let's also assume that your voice traffic already has QoS applied on each switch automatically, without the use of VLAN's.

I suppose I'm having trouble realizing where the real benefit of VLAN's comes into play in this particular scenario. If the PC's and phones were not connected together and each device had it's own dedicated switchport, then I could understand, as the phones would never see any traffic but their own and vice versa.

Anyone have thoughts on this?
  • Kailen Harper 143 posts since
    Jun 24, 2008



         Try looking at it from the Voice point of view. If possible we want to prevent the PC from seeing the Voice traffic. This prevents the PC from recording Voice calls illegally, the PC from having to deal with MOH broadcasts and allows you to make changes that effect only the Phones (DHCP, DNS and such).

    It also gives Phones their own DHCP ranges for manageability, and allows you to monitor the traffic seperately based on vlan. You can then also restrict access to the Voice servers to the phone Vlans. QoS can be applied at the VLAN level as well.


    I hope this helps.



  • Clay Maney 6 posts since
    Jan 29, 2010

    I believe the security implications of VLANs are purely secondary to IP phones.  The primary reason that it is recommended to put IP phones in their own VLAN is because of performance.  You just don't want any significant number of phones and PCs on the same VLAN.


    As for the rest, let me see if I can clarify it.  When a Cisco IP phone connects to a Cisco switch that is configured with voice and data VLANs, the phone gets assigned the voice VLAN and the PC gets assigned the data VLAN, right?  This means that the phone does not even see the broadcast that you mentioned from the PC, because it's not on the same VLAN!  Yes, physically the broadcast passes through the phone, but because it is on a different network (for all intents and purposes), there is no impact on the phone.  If you did not have this, then every time someone got a virus on their PC, the broadcasts would knock out all the phones.

  • Conwyn 7,907 posts since
    Sep 10, 2008

    Hi J


    If you have two switches connected with two cables you can force vlan-pc traffic down one cable and vlan-phone traffic down the other.


    Regards Conwyn

  • Paul Stewart  -  CCIE Security, CCSI 6,986 posts since
    Jul 18, 2008

    There is one more interesting thing in regards to this conversation that many don't realize.  The Cisco Phones actually span traffic that is related to the voice side of the phone out the pc port.  In other words, if you turn on Wireshark on a PC connected to the PC port of a Cisco Phone, you will see (and can listen to with G711) the voice traffic that is terminating on the phone.  I don't think broadcasts are spanned though.  In reality, the only broadcasts that I can think of that should see on the voice vlan is dhcp.  In any case, this is an opposite scenario than what you seem concerned.


    The other point is that the phones really don't see the the broadcasts from the PC vlan, they just pass them through.  This is the point Clay made.  The thing that is important to realize is that the Cisco Phone is 1) A Phone and 2). a 3 port switch.  If you turn the phone over, you only see two ports.  The third port is not physical, but what connects the phone's logic to the integrated switch.


    Regarding security, all this helps.  It is certainly nice to know what types of traffic are on each vlan.  This certainly helps us group our like traffic together.  Additionally, it can aid with IDS and filtering placement.  However, it is worth noting since those VLANs are trunked down to the port in each office, that where there's a will there's a way.  With Cisco switches there is a lot done with CDP, even sometimes trusting QoS based on the existence of a phone.  There is no reason that a really persistent person cannot make a pc or laptop look like a phone, access the trunk, voice vlan and be part of the trusted QoS.  All it takes is writing (or downloading) some code.  In any case, this can make it more difficult (and obvious) when it happens

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,397 posts since
    Oct 7, 2008

    Hmmmm...   I have to say I did not know that voice traffic leaked past the phone to the PC.  Now...  Why you would want to sniff your own phone's voice traffic is beyond me.  Eavesdropping on yourself seems a little strange.


    But on the other hand, it DOES provide a method to record your phone calls!   Hmmmmmm.


    Anyway, back to the original question.


    The broadcasts will indeed hit the phone, but the phone doesn't have an IP in the data VLAN.  So like any pure L2 switch, it will simply forward them.


    When we complain about broadcasts, it isn't really the "packets" themselves that cause problems.  It's that when they hit devices with an IP in that subnet then the rules are every station has to pause, unpack and act on the information.  Switches just pass them.  So no big deal.  If your phone DID have an IP in the same VLAN, then they would have to unpack, look at and (most likely) discard the information.


    But the CPUs on the phones aren't exactly incredible.   So anything you are doing to distract the phone's behavior may degrade voice traffic processing.





  • Paul Stewart  -  CCIE Security, CCSI 6,986 posts since
    Jul 18, 2008

    I think there are ways that Cisco Desktop Administrator can take advantage of this with local call recording (as you suggested).  I mostly use it for troubleshooting or understanding.  You can see the signaling traffic (scp) and the RTP streams.  Wireshark works better with SIP, but you can manually tag the RTP streams and listen to them.  One end of the conversation comes through the left speaker and the other end comes through the right speaker.  Pretty cool I think.  Also, CAIN can listen to G729 which is a codec that I think is officially protected by some Digium agreement.  I think Call Rex also has an implementation method that can use this feature.  In any case, a properly positioned network SPAN port can get the calls as well, but this comes in handy and is something to be aware of.  It can be disabled, but is enabled by default.  Below is an attached image I pulled from Cisco's website on the CCM config.

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,397 posts since
    Oct 7, 2008

    Just use VOMIT to replay captured calls. 

  • kevin 1 posts since
    Mar 30, 2012

    If you want to have a voip phone to have a voice vlan (voice) and have a passthrough with the phone to the pc with a different vlan (data). You will have to enable lldp which is Link Layer Discover Protocol, the command is LLDP run. Once that is enable configure Qos for the voice vlan. (it is opitional) On the port enable Switchport Access (Data vlan) and switchport voice (voice vlan). Now this switchport voice (voice vlan) command is on the up to date ios.


More Like This

  • Retrieving data ...

Bookmarked By (0)