Re: Trunking VLANs through an IP Phone

i saved your text in my documents
to be honest it is impressive work hence the silence

On Thu, Mar 11, 2010 at 7:16 PM, Patrick Galligan <pgalligan_at_gmail.com>wrote:

> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Mar 11 2010 - 20:14:22 ART