From: Roberto Fernandez (rofernandez@us.telefonica.com)
Date: Wed Jun 14 2006 - 12:51:10 ART
Sami,
Let break it down to the components you will find then all the
combinations. Here we have two things:
1- The actual indication to the switch of the presence of a "special"
VLAN (the voice VLAN)
2- The QoS treatment the switch will give to that port (both for the
data and the access VLANs)
The simplest way for a switch port to work is having a VLAN configured
and dumb host connected to it. In this case the switch's default
behavior would be trying to convert the port to a trunk, issuing a few
DTP (Dynamic Trunking Protocol) frames. But as said before, the host is
dumb and doesn't care for DTP. The switch quickly gives up and the port
becomes "dynamic access" in the mean time the switch also tries CDP
hoping to find a Cisco cousin at the other side.
Let bring now a phone and connect it to that switchport. Down to the
basics a phone could be no different to the dumb host, but the phones we
care about are a little bit more; must phones are small switches. And if
you look at them you will see, they usually have two Ethernet ports: One
for the uplink and one to connect a device (commonly the PC). From now
on we will speak fo phones that can talk to the switch, (Cisco phones of
course)
When you connect one of those Cisco phones to the switch, you will
clearly have now two devices originating traffic. The phone itself,
originating voice traffic; and the PC originating data traffic. Having
two kinds of traffic usually leads to the requirement of differentiating
them and treating them differently through some QoS technology. When the
switch recognizes the Cisco phone the will engage in some exchange of
configurations.
Summarizing, we have now:
1- A fairly smart Layer3 Switch
2- A no so dumb IP phone which in turn connects another device
3- The need to differentiate at the switch, traffics originating on the
phone and the PC.
Well, let start recognizing which traffic belongs to the phone and which
to the PC. Cisco has two methods
a) 802.1q
b) 802.1p
a) The 802.1q is really straight forward, when you issue the "switchport
voice vlan XX" command it is actually a command aimed to the phone. The
switch is telling to the phone: "tag the voice traffic you are sending
with XX 802.1q VLAN header" the phone will follow the instruction and by
default will assign also a CoS of 5 to those frames. The traffic coming
from the PC will come untagged and the switch will need to know which
VLAN assign to it, well this is the "switchport access vlan YY"
b) The 802.1p works in principle very similar "switchport voice vlan
dot1p" is similarly an instruction to the phone, and the default values
are the same (data on VLAN 0 and Cos of 5 for the 802.1p
Now let add the QoS options, remember we have two traffics already
recognized and the configuration until now is as follow (using 802.1q):
Interface Fastethernet 0/1
switchport access vlan XX
switchport voice vlan YY
Well, by default the switch won't care about what is coming and will
apply assume a CoS of 0 of everything coming into the port be it tagged
or not, this command "mls qos trust qos" will trust what the phone is
applying to tagged frames (this is the same for 802.1q or 802.1p kind of
tags. To be able to use mls qos commands at the interface we need to
enable it globally also. We have now:
!
mls qos
!
Interface Fastethernet 0/1
switchport access vlan XX
switchport voice vlan YY
mls qos trust qos
!
and the switch now cares about what the phone is tagging as voice. If we
do not care about the PC hanging from the phone, we could are done; but
we do... let say this is an important PC a VP's PC and we want to give
him something better than the default CoS of 0, well we can change the
default CoS of the switchport:
mls qos cos 3
now let say the VP is smart enough to make his PC mark traffic as CoS 5,
but 5 is only voice and maybe the CEO... then you can instruct your
phone to override his marks
switchport priority extend cos 3
and no matter what he does his data will come as Cos 3
or it could be the CEO, then you let them mark himself as he wants
switchport priority extend trust
So depending the treatment you want to give to the PC you can finish
your configuration with a combination of changing the default CoS for
the port and a remote trust of override option for the PC port. Let say
it is the CEO and we trust his marks, but if he forgets to mark, we will
give him CoS 3.
!
mls qos
!
Interface Fastethernet 0/1
switchport access vlan XX
switchport voice vlan YY
mls qos trust qos
mls qos cos 3
switchport priority extend trust
!
Well, this is a little bit long, and doesn't cover other options fur
trusting (DSCP, IP-Precedence, Cisco-Phone) but HTH with the basics,
going through the configuration guide and then the command reference
(for more options) will give you the rest.
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225see/scg/s
wvoip.htm#wp1034347
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225see/cr/cl
i1.htm#wp1862788
Best Regards,
Roberto
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Sami
Sent: Wednesday, June 14, 2006 4:07 AM
To: ccielab@groupstudy.com
Subject: Voice VLAN
Group,
Voice VLAN story is really giving me hard time. We have so many experts
on
this list , can't somebody explain what is the right way of configuring
Voice VLAN. I read three different workbooks CCO doc site and each has
their own solution.
This one from InternetworkExpert,
interface FastEthernet0/7
switchport access vlan 7
switchport voice vlan 10
switchport priority extend cos 1
mls qos trust cos
these guys say since 3550 port is in dynamic mode , switch automatically
form a trunk with Cisco Phone and don't require to configure port as a
trunk
or access mode and no spanning tree portfast.....
I know in real life things work in a diffrent way , could some one
please
calrify which way Cisco expect us to configure Voice VLAN stuff in lab
so we
don't loose point in tussel of Trunk /Access/Advanced CDP/portfast
etc...stuff.
Many thanks !!
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:32 ART