From: Bob Sinclair (bsin@cox.net)
Date: Mon Nov 22 2004 - 16:32:43 GMT-3
Tim,
The discard-class and pipe mode commands appear to be associated with the
MPLS parallel universe:
http://www.cisco.com/warp/customer/105/diffserv_tunnel.html#pipe
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Bob Sinclair" <bsin@cox.net>; "Group Study" <ccielab@groupstudy.com>
Sent: Monday, November 22, 2004 1:51 PM
Subject: Re: MQC Matching on DLCI
> Hey Bob,
>
> That's very clever. I think that would work just fine.
>
> Have any idea about the match discard-class and set discard-class
> commands?
> The documentation was completely useless for me. I had no idea what they
> were talking about. They also mentioned something about the set
> discard-class only being useable with Pipe mode and I had never heard of
> that mode.
>
> Any idea what they're talking about?
>
> 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 1:36 PM
> Subject: Re: MQC Matching on DLCI
>
>
>> Tim,
>>
>> Perhaps you could create an input policy that matches on dlci 101 and
>> associates with a qos group. The create an output policy with two
> classes:
>> a) match qos group, and match dlci 102 and b) match qos group. and match
>> dlci 103.
>>
>> Bob Sinclair
>> CCIE #10427, CCSI 30427, CISSP
>> www.netmasterclass.net
>>
>> ----- Original Message -----
>> From: "ccie2be" <ccie2be@nyc.rr.com>
>> To: "Bob Sinclair" <bsin@cox.net>; "Group Study" <ccielab@groupstudy.com>
>> Sent: Monday, November 22, 2004 11:58 AM
>> Subject: Re: MQC Matching on DLCI
>>
>>
>> > Bob,
>> >
>> > Yep, that last example was fairly straighforward. Now, I'm trying to
>> > figure
>> > out if this is possible and exactly how this would be configured.
>> >
>> > Suppose you have a hub f/r router with 3 spokes, 1, 2, and 3, all
>> > terminating on a p2m interface.
>> >
>> > Configure the hub router such that traffic from spoke 1 going to spoke
>> > 2
>> > has
>> > action 2 done and traffic from spoke 1 going to spoke 3 has action 3
> done.
>> >
>> > My problem is that I can't think of a way to match on next-hop address.
>> > If
>> > there were such a matching criteria, then this would be easy. I could
> just
>> > configure this.
>> >
>> > class-map 1-to-2
>> > match fr-dlci 101
>> > match <next-hop of spoke-2>
>> >
>> > class-map 1-to-3
>> > match fr-dlci 101
>> > match <next-hop of spoke-3>
>> >
>> > policy-map Actions
>> > class 1-to-2
>> > set <Action-2>
>> > class 1-to-3
>> > set <Action-3>
>> >
>> >
>> > int s0
>> > encap fram
>> > service-policy out Actions
>> >
>> > I don't know of any way to code "match <next-hop of spoke X>", so I
> don't
>> > know if this can be done.
>> >
>> > Any thoughts?
>> >
>> > 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 11:16 AM
>> > Subject: Re: MQC Matching on DLCI
>> >
>> >
>> >> Tim,
>> >>
>> >> Absolutely. The policy will set precedence to X for all traffic
> outbound
>> >> DLCI 102 on the hub, regardless of its source.
>> >>
>> >> Bob Sinclair
>> >> CCIE #10427, CCSI 30427, CISSP
>> >> www.netmasterclass.net
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "ccie2be" <ccie2be@nyc.rr.com>
>> >> To: "Bob Sinclair" <bsin@cox.net>; "Group Study"
> <ccielab@groupstudy.com>
>> >> Sent: Monday, November 22, 2004 10:37 AM
>> >> Subject: Re: MQC Matching on DLCI
>> >>
>> >>
>> >> > Bob,
>> >> >
>> >> > Let's say R1 has 1 dlci, 102 , to R2 adn another one to R3, 103.
>> >> >
>> >> > Couldn't this be done?
>> >> >
>> >> > class-map DLCI-102
>> >> > match fr-dlci 102
>> >> >
>> >> > policy-map IP-PREC
>> >> > class DLCI-102
>> >> > set ip-prec X
>> >> >
>> >> > int s0
>> >> > encap fram
>> >> > fram map ip x.x.x.2 102 broadcast
>> >> > fram map ip x.x.x.3 103 broadcast
>> >> > service-policy output IP-PREC
>> >> >
>> >> > Now, traffic to R2 will have the ip prec set to X while the dlci to
> R3
>> >> > will
>> >> > just have the default precedence, don't ya think?
>> >> >
>> >> > 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 10:18 AM
>> >> > Subject: Re: CAR vs Police
>> >> >
>> >> >
>> >> >> Tim,
>> >> >>
>> >> >> I too have trouble visualizing it! I went back and checked my lab
>> > notes,
>> >> >> and what I actually did was to set precedence on the hub for
>> >> >> traffic
>> >> >> transiting between spokes. The policy was applied on input
>> >> >> matching
>> >> >> on
>> > a
>> >> >> DLCI. I also set precedence using an input policy and matched that
>> >> >> precedence in an output policy on the same multipoint. I cannot
> think
>> > of
>> >> > a
>> >> >> way to match input DLCI in an outbound policy, as you can with an
>> >> >> input
>> >> >> interface match.
>> >> >>
>> >> >> Good catch!
>> >> >>
>> >> >> Bob Sinclair
>> >> >> CCIE #10427, CCSI 30427, CISSP
>> >> >> www.netmasterclass.net
>> >> >>
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "ccie2be" <ccie2be@nyc.rr.com>
>> >> >> To: "Bob Sinclair" <bsin@cox.net>; "Group Study"
>> > <ccielab@groupstudy.com>
>> >> >> Sent: Monday, November 22, 2004 10:04 AM
>> >> >> Subject: Re: CAR vs Police
>> >> >>
>> >> >>
>> >> >> > 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
>> >> >> >
>> >> >> >
>> > _______________________________________________________________________
>> >> >> > 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
>> >
>> > _______________________________________________________________________
>> > 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