From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Apr 28 2004 - 13:56:36 GMT-3
Good point, however, since today the lab doesn't use any L3 addressing that
isn't IP, there won't be any non-IP packets in lab.
Tim
----- Original Message -----
From: "William Chen" <kwchen@netvigator.com>
To: "Bob Sinclair" <bsinclair@netmasterclass.net>; "ccie2be"
<ccie2be@nyc.rr.com>; "Ng, Kim Seng David (David)" <ksng@avaya.com>;
<ccielab@groupstudy.com>
Sent: Wednesday, April 28, 2004 12:05 PM
Subject: Re: Cat3550 QOS confirmation
> Just want to add something to this point:
>
> >
> > if the ingress port is trusted (dscp or ip prec), it does NOT
> matter
> > what the cos value is or even if the cos value does not exists, the dscp
> or
> > ip prec will be used to derive the int dscp.
>
> If the frame is IP packet, the DSCP/Prec is trusted.
> However, if the frame is non-IP packet, the COS is trusted. If the frame
> don't have cos, the default cos is used.
>
> Check DocCD for confirmation.
>
> - William Chen
>
> ----- Original Message -----
> From: "Bob Sinclair" <bsinclair@netmasterclass.net>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Ng, Kim Seng David (David)"
> <ksng@avaya.com>; <ccielab@groupstudy.com>
> Sent: Wednesday, April 28, 2004 11:28 PM
> Subject: Re: Cat3550 QOS confirmation
>
>
> > Tim,
> >
> > I tested my previous conclusions on my box and got the result reported,
so
> I
> > am pretty confident in my conclusion that the command -mls qos cos X- is
> > ineffective without the command -mls qos trust cos- but I am always
> willing
> > to learn.
> >
> > I will grant you that the following quote is in the config guide:
> >
> > -QoS assigns the CoS value specified with the mls qos cos interface
> > configuration command to untagged frames received on trusted and
untrusted
> > ports.-
> >
> > Which certainly seems definitive and in accord with your view. I just
> have
> > not seen it act that way in practice. And I note that all configs I
have
> > seen that rely on -mls qos cos X- also have the command -mls qos trust
> > cos-
> >
> > This is definitely confusing, and I certainly take your point. I just
> have
> > to go with what I have seen.
> >
> > Comments inline below:
> >
> > Bob Sinclair
> > CCIE #10427, CISSP, MCSE
> > www.netmasterclass.net
> >
> >
> > ----- Original Message -----
> > From: "ccie2be" <ccie2be@nyc.rr.com>
> > To: "Bob Sinclair" <bsin@cox.net>; "Ng, Kim Seng David (David)"
> > <ksng@avaya.com>; <ccielab@groupstudy.com>
> > Sent: Wednesday, April 28, 2004 9:43 AM
> > Subject: Re: Cat3550 QOS confirmation
> >
> >
> > > Hi Bob,
> > >
> > > Are you 100% positive you didn't mis-speak? Because what you're
saying
> > > doesn't make sense to me. Here's the problem I have with what you
said.
> I
> > > tried to confirm my thinking with both the Flannagan book and the Cat
> 3550
> > > Config Guide but couldn't with 100% confidence. Maybe I terribly
> > > misunderstand this port trust concept but here's my current
> understanding.
> > >
> > > 1) When a frame comes into a Cat port and mls qos is enabled, by def,
> all
> > > ports are UNTRUSTED, so
> >
> > True
> >
> > >
> > > if the ingress port is cos trusted & the frame has a cos
value,
> > that
> > > cos value is used to derive the internal dscp value
> >
> > True
> >
> > >
> > > if the ingress port is cos trusted & the frame does NOT have a
> cos
> > > value (untagged frames), the def cos of 0 is assigned & used to derive
> > dscp.
> >
> > True
> >
> > >
> > > if the ingress port is trusted (dscp or ip prec), it does NOT
> > matter
> > > what the cos value is or even if the cos value does not exists, the
dscp
> > or
> > > ip prec will be used to derive the int dscp.
> >
> > True, I believe.
> >
> > >
> > > if the ingress is NOT trusted, it doesn't matter what the
cos,
> ip
> > > prec, or dscp value is, the default cos value is used to derive
internal
> > > dscp
> >
> > I think this may be the bone of contention. It appears to me that if
mls
> > qos is enabled and the port is not trusted, then CoS is zero, IP prec is
> > zero and DSCP is zero. Not set to the "default value for untagged
frames"
> >
> > >
> > > 2) The default cos value is, by default, = 0, but can be changed
> >
> > True, if a frame is untagged, and the port is trusted, the CoS will be
set
> > to the default 0.
> >
> > >
> > > Please let me know if anything I've said above is NOT correct. Also,
> > please
> > > see comments in-line. Thanks
> > >
> > > ----- Original Message -----
> > > From: "Bob Sinclair" <bsin@cox.net>
> > > To: "Ng, Kim Seng David (David)" <ksng@avaya.com>;
> > <ccielab@groupstudy.com>
> > > Sent: Wednesday, April 28, 2004 8:19 AM
> > > Subject: Re: Cat3550 QOS confirmation
> > >
> > >
> > > > David,
> > > >
> > > > The Cisco Catalyst QOS book by Flannagan suggests pretty strongly
that
> > the
> > > > default CoS is not applied unless you also trust COS on that port.
I
> > > > confirmed this on my lab 3550 running 12.1(19)EA1.
> > >
> > > **************************
> > > What cos is used when the port is NOT trusted? It seems to me there
are
> > > only 2 possibilities for determining the cos a) using the cos in
> incoming
> > > frame or b)assigning a default cos. Am I mistaken about this?
> > >
> > > **************************
> > > >
> > > > It is necessary to trust CoS before the default will be applied. I
> > tried
> > > > this on access port, but would expect the same result on a trunk or
> > voice
> > > > vlan.
> > > >
> > > > HTH,
> > > >
> > > > Bob Sinclair
> > > > CCIE #10427, CISSP, MCSE
> > > > www.netmasterclass.net
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Ng, Kim Seng David (David)" <ksng@avaya.com>
> > > > To: <ccielab@groupstudy.com>
> > > > Sent: Wednesday, April 28, 2004 5:31 AM
> > > > Subject: Cat3550 QOS confirmation
> > > >
> > > >
> > > > > Hello group,
> > > > >
> > > > > I would like to seek confirmation whether my understanding of the
> > > > following is correct. The following two configurations will produce
> the
> > > same
> > > > results i.e. the ingress data COS will be assigned "1" and ingress
> voice
> > > COS
> > > > (regardless of the original value of COS) will be overwritten to "1"
> > also.
> > > > >
> > > > > Config 1:
> > > > > ======
> > > > > mls qos
> > > > > !
> > > > > interface FastEthernet0/1
> > > > > switchport access vlan 20
> > > > > switchport voice vlan 100
> > > > > mls qos cos 1
> > > > >
> > > > > Explaination: Since by default the cat3550 ports are not trusted,
> all
> > > > ingress COS values will be overwritten to the default COS which is
> > > > configured as "1" here. As for untagged ingress data, it will
acquire
> > > > default COS of "1".
> > > > >
> > > > > Config 2:
> > > > > ======
> > > > > mls qos
> > > > > !
> > > > > interface FastEthernet0/1
> > > > > switchport access vlan 20
> > > > > switchport voice vlan 100
> > > > > mls qos cos 1
> > > > > mls qos trust cos
> > > > > mls qos cos override
> > > > >
> > > > > Explaination: Even though I configured COS trusting here, the
> > "override"
> > > > command will still overwrite all ingress COS to "1". As for untagged
> > > ingress
> > > > data, it will acquire default COS of "1".
> > > > >
> > > > > What I am trying to get here is that I do not need to have the
> > > "override"
> > > > command to overwrite the COS value if the port is already in an
> > > "untrusted"
> > > > state. Is my understanding correct?
> > > > >
> > > > > Thanks in advance
> > > > > David
> > > > >
> > > > >
> > _______________________________________________________________________
> > > > > Please help support GroupStudy by purchasing your study materials
> > from:
> > > > > http://shop.groupstudy.com
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> _______________________________________________________________________
> > > > Please help support GroupStudy by purchasing your study materials
> from:
> > > > http://shop.groupstudy.com
> > > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:57 GMT-3