From: ccie2be (ccie2be@nyc.rr.com)
Date: Mon Nov 22 2004 - 13:58:04 GMT-3
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
> >> >
> >> >
This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:48 GMT-3