From: P729 (p729@cox.net)
Date: Sat Apr 24 2004 - 19:47:32 GMT-3
Hi Tim,
The 3550 is one of those swithes that can operate in L2 mode "with L3
intelligence." The logic has gotten fast enough to look far enough into the
frame to start acting upon the L3 fields at L2 speeds.
Nothing special needs to be done to enable ACL's, but there are
platform-specific caveats that can severely affect performance and limit
flexibility. See:
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12119ea1/3550scg/swacl.htm
for more info.
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Group Study" <ccielab@groupstudy.com>; "P729" <p729@cox.net>
Sent: Saturday, April 24, 2004 2:01 PM
Subject: Re: QoS on 3550
> Hi Mas,
>
> When I said, "Regular ethernet frames don't and can't carry any QoS info."
> I should have said "ethernet frame HEADERS don't carry any QoS info.
>
> Also, this got me thinking and wondering about ip acl's in general on
> regular 3550 L2 access ports. For ip acl's to work on a 3550 L2 access
> port, does anything special need to be configured?
>
> Obviously, if the acl is for classifying frames for the purspose of QoS,
> then "mls qos" needs to be enabled. But, what if the acl is just for
> security, for example, deny telnet access from xyz to abc? Is anything
> special, in addition, to the acl needed for this to work?
>
> Thanks, Tim
>
>
> ----- Original Message -----
> From: "P729" <p729@cox.net>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
> Sent: Thursday, April 22, 2004 8:52 PM
> Subject: Re: QoS on 3550
>
>
> > Please see inline...
> >
> > Regards,
> >
> > Mas Kato
> > https://ecardfile.com/id/mkato
> >
> > ----- Original Message -----
> > From: "ccie2be" <ccie2be@nyc.rr.com>
> > To: "Group Study" <ccielab@groupstudy.com>
> > Sent: Thursday, April 22, 2004 8:56 AM
> > 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.
> >
> > Layer 2 QoS info = CoS (Class of Service), encoded into the 802.1p bits.
> > >
> > > Regular ethernet frames don't and can't carry any QoS info.
> >
> > Layer 3 QoS info = ToS (Type of Service) and can certainly be carried in
a
> > regular Ethernet frame. Related concepts include DiffServ
(Differentiated
> > Services) and DSCP (DiffServ Code Point), PHB (Per-Hop Behaviors) and
> > IP Precedence.
> >
> > >
> > > Given the above,
> > >
> > > Q1) Can cos be set on frames coming into or going out of regular
access
> > port
> > > on a 3550?
> >
> > CoS can be set or reset (marked) on frames entering an access port and
> used
> > internally for queue management, marking ToS, etc. CoS is passed along
if
> > the frame leaves the switch on a trunk or is stripped if it leaves on an
> > access
> > port.
> >
> > >
> > > Q2) If so, how does this work?
> >
> > Look into access port default CoS and trust states.
> >
> > >
> > > 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?
> >
> > Different switches, uh, do it differently--sometimes varying with
software
> > and/or
> > hardware revision. For example, some can trust CoS or override it, but
not
> > change (re-mark) it. Some can only mark certain values. Different
switches
> > also treat the marked traffic differently, for example, some
automatically
> > map CoS values to a queue and it can't be changes, while others don't do
> > any mapping by default.
> >
> > >
> > > Thanks in advanced, Tim
> > >
> > >
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:55 GMT-3