Re: Trunking VLANs through an IP Phone

Wow, the silence is deafening. I guess everyone is too busy vendor
bashing or insulting 3rd world countries for this to be of
interest....

On Wed, Mar 10, 2010 at 12:44 PM, Patrick Galligan <pgalligan_at_gmail.com> wrote:
> 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
Received on Fri Mar 12 2010 - 10:16:49 ART