From: ccie2be (ccie2be@nyc.rr.com)
Date: Mon Nov 22 2004 - 12:04:50 GMT-3
Hey Bob,
All in all, this MQC stuff is turning to be very flexible and powerful.
But, I can't visualize how to configure that matching inbound and setting
outbound thing you mentioned. A service policy is one way either inbound or
outbound. Any chance you can show me an example of what you're saying?
Thanks, Tim
----- Original Message -----
From: "Bob Sinclair" <bsin@cox.net>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
Sent: Monday, November 22, 2004 9:37 AM
Subject: Re: CAR vs Police
> Tim,
>
> I have had a chance to lab up matching on DLCIs, and it does behave as you
> indicate: applies to outbound traffic if the policy is applied outbound,
> and vice versa. What caught my eye: you can match inbound DLCI and set
> outbound, even when both DLCIs are on a single multipoint. Another
> illustration that the multipoint hub does a complete decapsulation -
routing
> process - encapsulation.
>
> Bob Sinclair
> CCIE #10427, CCSI 30427, CISSP
> www.netmasterclass.net
>
>
> ----- Original Message -----
> From: "ccie2be" <ccie2be@nyc.rr.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Bob Sinclair" <bsin@cox.net>; "Anas
> Tarsha" <ra3i@yahoo.com>; "Group Study" <ccielab@groupstudy.com>
> Sent: Monday, November 22, 2004 8:58 AM
> Subject: Re: CAR vs Police
>
>
> > Well, I think I found the answer to my questions regarding CAR vs Police
> > using MQC.
> >
> > With the new features now available, there is NO functionality in CAR
that
> > isn't available with MQC.
> >
> > See this link:
> >
> >
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ft3level.htm
> >
> > As this link shows, it's now possible to nest police commands with MQC.
> >
> > And, it's also possible to match traffic based on dlci, so therefore a
> > policy can be applied to the traffic of one particular dlci.
> >
> >
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftpcdlci.htm
> >
> > I assume that when matching traffic based on dlci, whether the dlci
> > matched
> > is the incoming or outgoing depends on whether the service-policy is
> > applied
> > to outgoing or incoming traffic, but I can't confirm that until I get
some
> > rack time.
> >
> > Any thought?
> >
> > Tim
> > ----- Original Message -----
> > From: "ccie2be" <ccie2be@nyc.rr.com>
> > To: "Bob Sinclair" <bsin@cox.net>; "Anas Tarsha" <ra3i@yahoo.com>;
"Group
> > Study" <ccielab@groupstudy.com>
> > Sent: Sunday, November 21, 2004 5:35 PM
> > Subject: Re: CAR vs Police
> >
> >
> >> Hi Bob,
> >>
> >> As I going over all the old GS posts on policing, I came this one
> > comparing
> >> CAR and Police.
> >>
> >> According to the DQoS by Odem, one of the differences is that with CAR
> >> you
> >> can configure nested rate-limit commands but not with MQC. Since
there's
> >> been alot of new features added to MQC, I wonder if that still holds
> >> true.
> >>
> >> For example, according to Odem, you couldn't enable MQC on a per dlci
> > basis,
> >> but since now you can match on dlci, you can.
> >>
> >> So, I wonder if a config like this would fly
> >>
> >> policy-map VOICE
> >> class VOICE
> >> police 128000
> >>
> >> policy-map ALL-TRAFFIC
> >> class class-default
> >> police 256000
> >> service-policy VOICE
> >>
> >> Any thoughts?
> >>
> >> Thanks, Tim
> >>
> >> ----- Original Message -----
> >> From: "Bob Sinclair" <bsin@cox.net>
> >> To: "Anas Tarsha" <ra3i@yahoo.com>;"Group Study"
<ccielab@groupstudy.com>
> >> Sent: Saturday, December 06, 2003 9:51 PM
> >> Subject: Re: CAR vs Police
> >>
> >>
> >> > Anas,
> >> >
> >> > I would agree that Cisco could do a better job of explaining the
> > policing
> >> > mechanism in the MQC, but I think I would disagree that it permits
> >> buffering
> >> > during congestion. There are Bc and Be parameters, but according to
> >> > the
> >> > documentation this does not buffer packets to shape the traffic. The
> > best
> >> > explanation I have found is at the link below, which says that the
> > policer
> >> > does not buffer, but "drops packets less aggressively" during
> > congestion.
> >> > Could you check it out and see what you think of it?
> >> >
> >> >
> >>
> >
http://www.cisco.com/en/US/partner/tech/tk543/tk545/technologies_q_and_a_item09186a00800cdfab.shtml#Q24
> >> >
> >> > Thanks!
> >> >
> >> > -Bob Sinclair
> >> > CCIE #10427, CISSP, MCSE
> >> >
> >> >
> >> > bsinclair@netmasterclass.net
> >> > ----- Original Message -----
> >> > From: "Anas Tarsha" <ra3i@yahoo.com>
> >> > To: "Bob Sinclair" <bsin@cox.net>; "ccie2be" <ccie2be@nyc.rr.com>;
> > "Group
> >> > Study" <ccielab@groupstudy.com>
> >> > Sent: Saturday, December 06, 2003 9:07 PM
> >> > Subject: Re: CAR vs Police
> >> >
> >> >
> >> > > Also theoretically there is a major difference between
> >> > > CAR and policing, a difference which Cisco hardly
> >> > > explains it well in my opinion. CAR is a rate-limit
> >> > > mechanism to limit the input or output transmission
> >> > > rate on an interface or subinterface based on a
> >> > > configured value. All the exceeding traffic is dropped
> >> > > in case the exceeding action is dropping. Policing is
> >> > > more like a shaping mechanism. As the name implies,
> >> > > shaping does not drop packets in case of congestion,
> >> > > it buffers them. You will see delay but no data loss.
> >> > > So this is the major difference, CAR does not buffer.
> >> > >
> >> > > Anas
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:48 GMT-3