Trunking VLANs through an IP Phone


Can it be done? I asked a number of people about this and the answer was always no.

Being persistent, and having a real life problem to solve, I did a lot of digging to find out the answer is actually yes. If you are currently preparing for a lab, think about how you could do this before reading on for the solution. Pay attention to the 802.1Q frame format and the QOS commands available to you for Cisco switchports. Since this is not Cisco recommended or best practice design, I figured any proctors reading this might think it could be a good task for a lab :)

The problem we had to solve was that the customer had mandated a single port per room in the accommodation blocks being constructed for their project. This single port had to provide IPTV/VOD (video on demand), IP Phone and PC Internet/network access. The scale is large enough that 2 ports per room would add significant cost to the project.

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. Therefore, enabling trunking through the phone. 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. The switch type/model is not that relevant, as the command to enable this is available in a lot of switches, if not all of the current switches, and has been available for a long time.

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 are 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 one 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, and BPDU Guard are 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 prevents PC to PC traffic while allowing PC to Internet (or the rest of the network) traffic.

QOS was 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. You could argue that video doesn’t belong in the priority queue, but my opinion is that the people who will be in these rooms will care less about poor quality voice calls than a pixelated picture when they are watching FOX Sports or the latest blockbuster movie in HD. In any case, QOS can be configured either way.

The STB drops any tagged frames from the PC port by design, this protects against a number of L2 attacks from the PC. 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 files 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 re-mark 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 if the phone were to be overloaded, they are welcome to do that as it won’t affect anyone else ;)

I think I covered all the relevant issues with this solution, given the single port requirement, but feel free to offer any suggestions. Criticism is also welcome, we have already received enough about this not being best practice, and about the extend trust command not designed to do what we are using it for, so I am used to it :)

Cheers, Patrick

Blogs and organic groups at http://www.ccie.net

_______________________________________________________________________ Subscription information may be found at: http://www.groupstudy.com/list/CCIELab.html