From: P729 (p729@cox.net)
Date: Thu Apr 22 2004 - 22:05:36 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 4:18 PM
Subject: Re: QoS on 3550
> Ken,
>
> You raise a very interesting question - one that I had never considered
> before.
>
> Let me restate the question this way.
>
> Can the same type of filtering be done on a trunk port as can be done on a
> regular access port? (Obviously, it's easy to filter based on vlan)
>
> Also, can QoS behavior be set on a trunk port, for example, all voice vlan
> traffic s/b passed ahead of traffic from other vlans?
Yes and it can be done in as many different ways as there are Catalyst
series.
Related concepts are expedited or priority queueing, WRR (weighted round-
robin) queueing, drop thresholds, etc.
>
> (Actually, thinking about it, it seems like a trunk port would be a good
place
> to prioritize voice traffic, don't you think?)
>
> And, if yes, would filtering need to be configured any differently from
how it
> would be done on a regular access port.
>
> As, so often happens, 1 question breeds several more. Sorry about that.
>
> Tim
> ----- Original Message -----
> From: Kenneth Wygand
> To: ccie2be ; Group Study
> Sent: Thursday, April 22, 2004 6:44 PM
> Subject: RE: QoS on 3550
>
>
> Tim,
>
>
>
> Thanks for the summary my brain was unable to spill out after all this
> studying.
>
>
>
> I did not ultimately test number 3, sending COS-marked frames over a
Trunk
> port. Unfortunately I can't try this because I only have one 3550 and no
> devices that support trunking (2500 series). Actually, now that I think
about
> it, I have a 3620 that I can set trunking on, but can I check the QoS on
the
> trunk without first sending it back to an access port like I would if I
was
> using back-to-back 3550's?
>
>
>
> Points 1 and 2 are exactly correct!
>
>
>
> 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 4:16 PM
> To: Kenneth Wygand; Group Study
> 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.
>
>
>
> 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