From: P729 (p729@cox.net)
Date: Thu Apr 22 2004 - 21:56:11 GMT-3
Please see inline...
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Kenneth Wygand" <KWygand@customonline.com>; "Group Study"
<ccielab@groupstudy.com>
Sent: Thursday, April 22, 2004 1:15 PM
Subject: Re: QoS on 3550
> Good job Ken,
>
> Now, just to spell out your findings.
>
> 1) To set any QoS values (cos, ip prec, dscp, or tos) on incoming frames
to a
> regular layer 2 access port on a 3550, mls qos has to be enabled. If mls
qos
> isn't enabled, setting qos values either does no good or just can't done.
>
> 2) Per an earlier post, if mls qos is enabled, any qos values that were
set in
> the packet prior to reaching the 3550 will, by default, be reset to "best
> effort". If this behavior isn't wanted, the port must be changed from
> untrusted to trusted.
>
> 3) Any QoS settings made to incoming frames (or pkt's) on a regular layer
2
> port are carried intact to the outgoing port whether or not the outgoing
port
> is a regular layer 2 port or a trunk.
CoS is passed along a trunk, stripped out an access port. ToS is left intact
in
either case.
>
> If anyone disagrees with these conclusions, please let us know which
> conclusions you disagree with and why.
>
> Thanks, Tim
> ----- Original Message -----
> From: Kenneth Wygand
> To: ccie2be ; Group Study
> Sent: Thursday, April 22, 2004 2:41 PM
> Subject: RE: QoS on 3550
>
>
> I just tried this out. You need to enable "mls qos" to do anything with
COS
> or TOS values. COS or TOS will not "pass through" the switch unless you
have
> this configured globally.
>
>
>
> Yes, COS does automatically map to IP Precedence values by default
through
> "mls qos cos-to-dscp" (COS 5 maps to DSCP 40 which is backwards compatible
> with IP Precedence 5.
>
>
>
> Yes, you can set the _raw_ value of the TOS field through an extended
ping.
> However since this is the raw value, IP Precedence of 5 is represented
through
> "160" and DSCP EF is represented through "184" (you need to do the binary
> conversion).
>
>
>
> I think I answered all the questions here. If anyone else has any other
> questions, let me know and I'll try to answer!
>
>
>
> Thanks!
>
>
>
> Kenneth E. Wygand
> Systems Engineer, Project Services
>
> CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
> Network+, A+
> Custom Computer Specialists, Inc.
>
> "I am not really smart. I just stick with problems longer."
> -Albert Einstein
>
>
>
> Custom Computer Specialists, Inc.
>
> "Celebrating 25 Years of Excellence"
>
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Thursday, April 22, 2004 12:52 PM
> To: Kenneth Wygand; Group Study
> Subject: Re: QoS on 3550
>
>
>
> Hey Ken,
>
>
>
> I don't think this can be fully tested by marking pkts on the 2500. I
think
> you have to test this on the 3550.
>
>
>
> Can you set this up? rtr1 ----> sw1--trunk sw2 ---> rtr2 or
rtr1 -->
> sw --> rtr2
>
>
>
> Try setting the 3550 port connected to rtr1 to mark icmp pkts to cos 5.
> Then configure logging on rtr2 connected to the 3550 using an access-list
that
> logs all icmp pkts with a ip prec = 5. (On the 3550, frames marked with
cos =
> 5, I think are automatically mapped to ip prec = 5.)
>
>
>
> I think, but I'm not sure, that mls qos has to be enabled on the 3550
for
> this to work. Maybe you can confirm this.
>
>
>
> Now, ping the 2nd rtr, and see what pkts are logged.
>
>
>
> After testing what happens with frames marked on the 3550 with cos
settings,
> try changing the marking to ip prec, and then dscp, and repeating
experiment.
> If you do this, don't forget to change the log access-list on the 2nd rtr
so
> that you can see what the 3550 does in each case.
>
>
>
> HTH, Tim
>
> ----- Original Message -----
>
> From: Kenneth Wygand
>
> To: ccie2be ; Group Study
>
> Sent: Thursday, April 22, 2004 12:21 PM
>
> Subject: RE: QoS on 3550
>
>
>
> I'm trying to test this out as we speak. I'm trying to set the IP
> Precedence in a route map assigned to a local policy in a 2500 series
router,
> but I'm receiving the following. is this because I cannot set ISL or DOT1Q
> encapsulation on a 2500-series router? I believe I should be able to set
the
> TOS bit on any platform because there is a TOS field in all IP packets.
>
>
>
> <snip>
>
> ip local policy route-map SETFLASH
>
>
>
> route-map SETFLASH permit 10
>
> set ip precedence flash
>
>
>
> r1#ping 10.0.0.2
>
> *Mar 1 00:12:43.951: %SYS-5-CONFIG_I: Configured from console by
console
>
>
>
> Type escape sequence to abort.
>
> Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
>
>
>
> *Mar 1 00:12:47.163: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> match
>
> *Mar 1 00:12:47.167: IP: route map SETFLASH, item 10, permit
>
> *Mar 1 00:12:47.171: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> reject
>
> ed -- normal forwarding.
>
> *Mar 1 00:12:49.163: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> match
>
> *Mar 1 00:12:49.167: IP: route map SETFLASH, item 10, permit
>
> *Mar 1 00:12:49.167: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> reject
>
> ed -- normal forwarding.
>
> *Mar 1 00:12:51.163: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> match
>
> *Mar 1 00:12:51.167: IP: route map SETFLASH, item 10, permit
>
> *Mar 1 00:12:51.171: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> reject
>
> ed -- normal forwarding.
>
> *Mar 1 00:12:53.163: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> match
>
> *Mar 1 00:12:53.167: IP: route map SETFLASH, item 10, permit
>
> *Mar 1 00:12:53.167: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> reject
>
> ed -- normal forwarding.
>
> *Mar 1 00:12:55.163: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> match
>
> *Mar 1 00:12:55.167: IP: route map SETFLASH, item 10, permit
>
> *Mar 1 00:12:55.167: IP: s=10.0.0.1 (local), d=10.0.0.2, len 100,
policy
> reject
>
> ed -- normal forwarding.
>
> Success rate is 0 percent (0/5)
>
> </snip>
>
>
>
> Any ideas?
>
>
>
> Kenneth E. Wygand
> Systems Engineer, Project Services
>
> CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
> Network+, A+
> Custom Computer Specialists, Inc.
>
> "I am not really smart. I just stick with problems longer."
> -Albert Einstein
>
>
>
> Custom Computer Specialists, Inc.
>
> "Celebrating 25 Years of Excellence"
>
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Thursday, April 22, 2004 11:57 AM
> To: Group Study
> Subject: QoS on 3550
>
>
>
> Hi guys,
>
>
>
> I'm trying to understand something which has me confused.
>
>
>
> Recall these facts:
>
>
>
> At layer 2, only ISL or 802.1q trunks have fields to carry layer 2 QoS
> info.
>
>
>
> Regular ethernet frames don't and can't carry any QoS info.
>
>
>
> Given the above,
>
>
>
> Q1) Can cos be set on frames coming into or going out of regular
access
> port on a 3550?
>
>
>
> Q2) If so, how does this work?
>
>
>
> Q3) Can someone confirm that's there's no problem or Gotcha's on
setting
> layer 3 QoS on frames coming into or leaving a regular access port?
>
>
>
> Thanks in advanced, Tim
>
> [GroupStudy removed an attachment of type image/gif which had a name of
image001.gif]
>
> _______________________________________________________________________
> 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:53 GMT-3