Trunking VLANs through a Cisco phone?

Unanswered Question
Nov 10th, 2009


We may have a requirement to have 2 additional tagged VLANs pass through the phone to another device. Will a Cisco IP phone (7941G) pass through traffic which is tagged with a VLAN that is not the voice VLAN?

eg. Voice VLAN is 7, device connected to phone needs VLANs 10 and 20 and possibly the untagged VLAN. If I configure the switch port as a trunk and allow those 3 VLANs on the trunk, will the device connected to the phone get the traffic in VLANs 10 and 20?

Thanks :)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Paolo Bevilacqua Tue, 11/10/2009 - 08:28

By design phone will not pass tagged traffic.

You will need to run a separate cable for that.

patrickjgalligan Tue, 11/10/2009 - 21:13

Well I just labbed it up with a 2960 POE and it works. I trunked 3 VLANs to the phone, plus the native, untagged, VLAN. The device connected to the phone got traffic from all VLANs and could ping IP addresses in each VLAN :)

patrickjgalligan Wed, 11/11/2009 - 16:06
patrickjgalligan Tue, 03/09/2010 - 18:12

Just updating this as FYI:

Cisco switches have had  the option to tell the phone via CDP to accept frames with 802.1p priority  markings for a long time. Since the 802.1p marking is part of an 802.1Q  VLAN tag, accepting 802.1p tagged frames implies accepting 802.1Q tagged  frames. We have proven this in a proof of concept for a customer. Configuration as follows:

3750 POE edge switches running 12.2(52)SE though I have also tested this with earlier versions

7941 and 7942 phones connected to the switch

IPTV/VOD Settop Box (STB) connected to the IP Phone PC Port.

PC connected to the STB PC port (STB has 2 100Mbps ports, one for connection to the network and one for a PC to connect to for network access)

3750 switchports configured as a trunk and use "switchport priority extend trust" command to tell the phone to accept tagged frames. 3 VLANs go to the STB, 2 tagged and on untagged. One is for mgmt, one  for video streams and one for the PC network access. In total, 4 VLANs including the voice VLAN for the phone.

Port security, portfast trunk, BPDU Guard enabled.Port security limited to 1 for voice VLAN and STB streaming VLAN, limited to 2 for native VLAN as both the phone and STB MAC addresses appear in this VLAN during boot. Maximum for the port is arbitrary, we only need to protect against MAC address flooding so any number that will achieve this is ok. If you wanted to be really restrictive the limit would also be set to one for the PC VLAN.

DHCP Snooping, Dynamic ARP Inspection, IP Source Guard and VLAN access maps may also be used to provide relevant security. In our case we had an Internet gateway supplied by the IPTV vendor which behaves like a L2 firewall/proxy. PC's on each switchport were configured in a different VLAN, and the Internet gateway prevent PC to PC traffic while allowing PC to Internet (or the rest of the network) traffic.

QOS configured appropriately to ensure video streams and voice calls get priority over other traffic. In our case we put both video and voice in priority queue. Video streams are maximum 15Mbps so have no effect on voice.

STB drops any tagged frames from the PC port by design, this protects against a number of L2 attacks. STB can also throttle traffic from the PC.

Our demonstration included a fast motion HD IPTV stream (Winter Olympics) being multicast to the STB (unicast was also used for VOD, which was HD movie trailers), while a voice call was in progress, also while streaming a YouTube video, downloading a file via FTP and browsing on the PC.

I also performed a security audit from the PC to confirm that security was effective. Per VLAN port security protects against the PC being connected directly to the switchport and attempting to get connectivity or sniff the voice/STB VLANs. All other features were effective, as expected.

Given that we are trusting the 802.1p priority markings you could suggest that the PC might be able to launch a DOS attack on the priority queue. In theory this is correct. However, since the STB can throttle PC traffic we can limit this, and we can also remark any traffic on the PC VLAN at the switchport. Since the video streams are downstream, the PC traffic can be marked and queued appropriately by the network. So in reality the only DOS attack on the priority queue that would be effective would be on the user's own phone. If the user wants to DOS his/her own phone, which could potentially also affect their own video viewing experience, they are welcome to do that as it won't affect anyone else


This Discussion