From: ccie2be (ccie2be@nyc.rr.com)
Date: Sun Nov 14 2004 - 16:24:48 GMT-3
Pretty cool stuff, eh?
Thanks for confirming all this.
At this point I think I'm pretty solid on all this MQC, map-class, acl stuff
with one exception.
I can't figure out when I would need to configure MQC and map-classes for a
f/r interface and NOT put the MQC's service-policy command inside the
map-class.
I know this is a valid configuration but do NOT know (or can't think of) of
a scenario where this should be done.
For example, in what scenario would this be the "proper" configuration?
int s0
encap fram
fram class FRTS
int s0.102
service-policy <input | output> NOT-INSIDE-MAP-CLASS
or, for example, this
int s0
encap fram
service-policy <input | output> NOT-INSIDE-MAP-CLASS
int s0.102
fram class FRTS
The only thing I can think of has to do with inheritance. In the first
example,
all dlci's inherit the map-class, but only the dlci's on sub-interface
s0.102 are
affected by the MQC.
And,in the 2nd example, it's the reverse.
Am I thinking about this correctly?
Thanks, Tim
----- Original Message -----
From: "Bob Sinclair" <bsin@cox.net>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Sunday, November 14, 2004 2:07 PM
Subject: Re: MQC QoS - map class or service-policy
> Tim,
>
> I was able to confirm this experimentally. The telnet filter applies to
> just one DLCI, all the DLCIs on a subinterface, or all the DLCIs on a
> physical interface, depending on where the map-class is applied.
>
> Bob Sinclair
> CCIE #10427, CCSI 30427, CISSP
> www.netmasterclass.net
>
> ----- Original Message -----
> From: "ccie2be" <ccie2be@nyc.rr.com>
> To: "Bob Sinclair" <bsin@cox.net>; <ccielab@groupstudy.com>
> Sent: Sunday, November 14, 2004 1:24 PM
> Subject: Re: MQC QoS - map class or service-policy
>
>
> > Wow, how cool is that?
> >
> > Thanks for getting back to me on this.
> >
> > And, yes, that was exactly what I was asking about.
> >
> > Now, if that's true and I believe you when you say it is, this should
also
> > be true.
> >
> > When the map-class with the service-policy inside is applied on the
> > physical
> > interface,
> > whatever is inside that map-class is inherited by all the dlci's
> > regardless
> > of whether
> > those dlci's are terminated at the phy or sub-interface level. ( I
don't
> > know if you tested
> > whether this is true for just the physical interface or if you also
tested
> > whether this is true
> > on sub-interfaces.)
> >
> > But, if this is true for both the phy and sub-interfaces, then logically
2
> > other conclusions follow:
> >
> > 1) Therefore, it's possible to use a service-policy to filter whatever
> > traffic is specified
> > with the MQC without having to apply an acl wherever there's an assigned
> > ip
> > address.
> >
> > What makes this interesting (to me, at least), is that the other day I
> > verified that an acl
> > applied directly on the physical interface does NOT affect traffic on
> > sub-interfaces. In
> > other words, an acl on a f/r phy interface is NOT inherited by
> > sub-interfaces.
> >
> > 2) Now, it's possible to filter traffic from just one individual dlci on
a
> > multipoint interface
> > (phy or p2m sub, it doesn't matter) with multiple dlci's.
> >
> > For example, let's say you have a f/r interface with 2 dlci's: 1 dlci
> > connects to an ISP and
> > the other dlci connects to your internal network. And, your network
> > policy
> > states that certain
> > traffic from your ISP is not allowed IN but that same type of traffic
from
> > your internal is allowed IN.
> >
> > (Of course, I know this issue is easily avoided by using sub-interfaces,
> > but
> > I'm trying to think
> > like those sadists who write the R & S lab, where the easy solution
isn't
> > allowed)
> >
> > If you just created the appropriate acl to implement that policy,
there's
> > no
> > place to apply the acl
> > without affecting the traffic from both dlci's.
> >
> > But, now, by combining MQC and map-classes, you can use the MQC to
filter
> > the traffic not
> > allowed from the ISP and using map-classes, you can apply it just to the
> > dlci connecting to your ISP.
> >
> > What do you think?
> >
> > Later in the week I'll be able to test this, but for now, I don't have
> > routers that support this type of thing.
> >
> > Thanks again, Tim
> >
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Bob Sinclair" <bsin@cox.net>
> > To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
> > Sent: Sunday, November 14, 2004 12:17 PM
> > Subject: Re: MQC QoS - map class or service-policy
> >
> >
> >> Tim,
> >>
> >> If I understand you correctly, your question is "can we apply an input
> >> filter as a service-policy within a shaping, frts, map-class?" The
> >> answer
> >> appears to be yes. I created exactly the config you suggested, and it
is
> >> shaping outboung and filtering inbound telnet. Wonders never cease!
> >>
> >> 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"
> >> <bsinclair@netmasterclass.net>; <jean.paul.baaklini@accenture.com>;
> >> <ccielab@groupstudy.com>
> >> Sent: Sunday, November 14, 2004 8:45 AM
> >> Subject: Re: MQC QoS - map class or service-policy
> >>
> >>
> >> > One other question:
> >> >
> >> > Is something like this possible?
> >> >
> >> > map-class frame-relay Block-Inbound <--- Normally used to shape
> > outbound
> >> > traffic
> >> > frame cir xxx
> >> > service-policy input Block-Telnet <--- Notice direction is IN
> >> >
> >> > int s0
> >> > frame-relay traffic-shaping
> >> > frame class Block-Inbound
> >> >
> >> > I wonder because typically map-classes are used to shape outbound
> > traffic.
> >> > So, if a service-policy to block certain inbound traffic
> >> > is inside a map-class frame-relay that normally shapes outbound
> >> > traffic,
> >> > is
> >> > that a config that actually works. I can't test this with the old
> > routers
> >> > I
> >> > have, so maybe someone can comment on this.
> >> >
> >> >
> >> >
> >> >
> >> >> Hi Bob,
> >> >>
> >> >> Recently, I've been trying to sort out this issue of where the
> >> >> service-policy should be applied in the context of a f/r interface
and
> >> > found
> >> >> your post.
> >> >>
> >> >> So far, this is how I think about these 2 constructs. Please correct
> >> >> me
> >> >> if
> >> >> anything I say is not completely true.
> >> >>
> >> >> Starting first with the simple cases:
> >> >>
> >> >> FRTS without MQC
> >> >> Use this when traffic shaping settings apply equally to all
> >> >> traffic
> >> >> types (http, smtp, etc)
> >> >> Use multiple map-classes when FRTS settings are different for
> >> > different
> >> >> dlci's
> >> >> Apply at the appropriate level of int - either phy, p2m sub, or
> >> >> p2p
> >> > sub
> >> >> Map-classes applied at phy level are inherited by sub-int unless
> >> >> overrided
> >> >>
> >> >> MQC without FRTS map-classes
> >> >> Use this if different types of traffic (http, smtp, etc) get
> >> > different
> >> >> treatments
> >> >> Apply at the appropriate level of int - either phy, p2m sub, or
> > p2p
> >> > sub
> >> >> Can not be applied to an individual dlci of a phy or p2m sub.
> >> >> Service-policy applied at phy level are inherited by sub-int
> > unless
> >> >> overrided
> >> >>
> >> >> Now, it starts to get more complicated
> >> >>
> >> >> MQC with FRTS (Service-policy inside map-class)
> >> >> Use this when you need to prioritize by traffic type within a
> > dlci
> >> >> Like before, use multiple map-classes when FRTS settings are
> >> > different
> >> >> for different dlci's
> >> >> Apply at the appropriate level of int - either phy, p2m sub,
or
> > p2p
> >> >> sub
> >> >> Map-classes applied at phy level are inherited by sub-int
unless
> >> >> overrided
> >> >>
> >> >> BTW, one interesting and potentially very useful application of the
> > above
> >> >> construct is this can be used to apply an acl to
> >> >> a particular dlci on a p2m interface either phy or p2m sub that
> >> >> doesn't
> >> >> affect any traffic of the other dlci's. For example, let's say
> >> >> a f/r physical interface is using 3 dlci's and 1 dlci connects to an
> > ISP
> >> > and
> >> >> the other 2 connect to other routers in your network. And, you want
> >> >> to
> >> >> block telnet access from the ISP but not block telnet access on the
> > other
> >> > 2
> >> >> dlci's. Using MQC, telnet traffic is specified in a class-map,
dropped
> > in
> >> > a
> >> >> policy-map and applied with service-policy within a map-class that
> >> >> applied
> >> >> to a particular dlci. (I don't know for sure this will actually work
> >> > because I don't know if it's possible to
> >> >> have a service policy INPUT inside a map-class.)
> >> >>
> >> >> MQC with FRTS (Service-policy NOT inside map-class)
> >> >> I have no idea when I should use this ????
> >> >>
> >> >> If anybody can explain when this last scenario should be use and
give
> >> >> a
> >> >> concrete example or 2, that would be very, very helpful.
> >> >>
> >> >> OK, time to get to studying.
> >> >>
> >> >> TIA, Tim
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Bob Sinclair" <bsinclair@netmasterclass.net>
> >> >> To: <jean.paul.baaklini@accenture.com>; <ccielab@groupstudy.com>
> >> >> Sent: Monday, September 13, 2004 12:19 PM
> >> >> Subject: Re: MQC QoS - map class or service-policy
> >> >>
> >> >>
> >> >> > JP,
> >> >> >
> >> >> > A couple differences of note:
> >> >> >
> >> >> > If you want different parameters on different VCs of a multipoint
> >> >> interface
> >> >> > then you will need to apply them in a map-class using frts.
> >> >> >
> >> >> > You will need to use a service-policy directly on the interface
(or
> >> >> > GTS)
> >> >> if
> >> >> > you want different shaping parameters for different types of
traffic
> > on
> >> > an
> >> >> > interface.
> >> >> >
> >> >> > HTH,
> >> >> >
> >> >> > Bob Sinclair
> >> >> > CCIE #10427, CISSP, MCSE
> >> >> > www.netmasterclass.net
> >> >> >
> >> >> > ----- Original Message -----
> >> >> > From: <jean.paul.baaklini@accenture.com>
> >> >> > To: <ccielab@groupstudy.com>
> >> >> > Sent: Monday, September 13, 2004 7:07 AM
> >> >> > Subject: MQC QoS - map class or service-policy
> >> >> >
> >> >> >
> >> >> > > Hi Group,
> >> >> > >
> >> >> > > When configuring MQC QoS on routers meshed through a Frame-Relay
> >> >> > > network.
> >> >> > >
> >> >> > > What's the difference between applying the service-policy
command
> >> >> > > directly to the interface or within a frame-relay class command?
> >> >> > >
> >> >> > > Cheers,
> >> >> > > JP
> >> >> > >
> >> >> > >
> >> >> > > This message is for the designated recipient only and may
contain
> >> >> > > privileged, proprietary, or otherwise private information. If
you
> >> > have
> >> >> > > received it in error, please notify the sender immediately and
> > delete
> >> >> the
> >> >> > > original. Any other use of the email by you is prohibited.
> >> >> > >
> >> >> > >
> >> >
This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:45 GMT-3