From: ccie2be (ccie2be@nyc.rr.com)
Date: Sun Nov 14 2004 - 16:10:50 GMT-3
Thanks, Scott.
Live and learn !!!
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Bob Sinclair'" <bsin@cox.net>;
<ccielab@groupstudy.com>
Sent: Sunday, November 14, 2004 2:00 PM
Subject: RE: MQC QoS - map class or service-policy
> Your observation about the ACL is correct. That's because Acls are an
> interface-related configuration, and therefore there is no inheritance.
> Frame relay map classes are inherently PVC-related, and therefore do get
> inherited along with any associated configurations.
>
> So it does make life fairly interesting. :)
>
> Cheers,
>
> Scott
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> ccie2be
> Sent: Sunday, November 14, 2004 1:25 PM
> To: Bob Sinclair; ccielab@groupstudy.com
> 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