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
Received on Wed Mar 10 2010 - 12:44:08 ART