folks,
keep one thing in mind in the process of the PC packets getting to the
switch infrastructure. the IP phone is a switch itself, so as packets come
in port 0 (PC) and go out port 1 (to switch) those layer 2 headers are
'touched'. So, as it gets forwarded upstream (onto a 802.1q trunk, which is
the only place that COS can exist) those packets can be marked
(rewritten) with the appropriate COS value.
On Wed, Jul 23, 2008 at 10:01 PM, Nick Marus <[EMAIL PROTECTED]> wrote:
> COS does exist in the 1q header in the 1p field, however the pc nic
> (most) has the ability to add this to the frame. (should see "qos packet
> scheduler" under you nic properties in windows) The 1q header can exist with
> out vlan tagging being set. unlike isl which re-encapsulates the ethernet
> frame inside an isl frame, adding the 1q header does not render the frame
> unreadable to non 1q devices. The 1q header is just inserted between the sa
> and the type/length field in the frame header. many devices that do not make
> use of 1q vlan tagging still use the 1p portion of the 1q header to mark
> their cos.
>
> A cisco switch that is setup for mode access will ignore the 1q vlan
> tagging and put the frame on the vlan that the switchport is configured
> to. But it will still look at the 1p portion of the 1q header if qos trust
> cos is configured on the port. Same thing goes for a computer attached to a
> phone. if the switch is configured to trust the cos marking of the device
> attached behind the phone, it will look at the 1p portion of the 1q header
> on the frames coming from the device attached to the phone and respect those
> values. otherwise it will have the phone remark those values before the
> frame gets to the switch and get prioritized.
>
> <http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094665.shtml#topic1>
>
>
>
>
>
> On Wed, Jul 23, 2008 at 6:57 PM, Mike Brooks <[EMAIL PROTECTED]> wrote:
>
>> Its my understanding that the CoS value is set in the 802.1p field
>> within an 802.1q tag. Therefore, in order to set a CoS value you need
>> have an 802.1q trunk. So a PC would not be able to set a CoS value,
>> unless its uplink was an 802.1q trunk port, rather than an access
>> port.
>>
>> So if the PC can't set the CoS value, why would you need to use the
>> "switchport priority extend cos 0" ?
>>
>> Please correct me if I am wrong.
>>
>> Regards,
>>
>> Mike Brooks
>> CCIE#16027 (R&S)
>>
>>
>> On 7/23/08, Nick Marus <[EMAIL PROTECTED]> wrote:
>> > Unless I misunderstand you, COS is applied to a packet and does not
>> require
>> > a 1q trunk. The connection between the pc and the phone is not 1q
>> usually.
>> > Just the connection between the phone and the switch. Most PC nic's can
>> be
>> > setup to mark it's packets with a cos value and effectively take
>> priority on
>> > your switched network over you voice and other high priority packets if
>> the
>> > switch is trusting and the phone is not remarking to 0.
>> >
>> >
>> > Nick
>> >
>> >
>> > On Wed, Jul 23, 2008 at 10:51 AM, Mike Brooks <[EMAIL PROTECTED]>
>> wrote:
>> > > Hi Everyone,
>> > >
>> > > I see that the standard practice on a switchport is to configure
>> > > "switchport priority extend cos 0" in order to allow the ip phone to
>> > > reset the cos value received from the PC to 0.
>> > >
>> > > My question is how would a PC ever set a "CoS" value if the link
>> > > between the ip phone and the PC is not an 802.1q trunk ?
>> > >
>> > > Can someone please help me understand this ? The only thing I can
>> > > think of is that the PC would somehow have to support an 802.1q trunk
>> > > to it, a trunk would have to be dynamically established between the
>> > > phone and PC. And, then the user would have to manipulate the CoS
>> > > value. Is this possible with a Cisco phone ?
>> > >
>> > > If this is the only case this would work then you would think that
>> > > Cisco would document these pre-requisites. Perhaps I am confused.
>> > >
>> > > Please help ;-)
>> > >
>> > > Regards,
>> > >
>> > > Mike Brooks
>> > > CCIE#16027 (R&S)
>> > >
>> >
>> >
>> >
>> > --
>> > Nick Marus
>> > [EMAIL PROTECTED]
>>
>
>
>
> --
> Nick Marus
> [EMAIL PROTECTED]
>
