From: ccie2be (ccie2be@nyc.rr.com)
Date: Sun Nov 14 2004 - 15:24:56 GMT-3
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.
> >> > >
> >> > >
> > _______________________________________________________________________
> >> > > Please help support GroupStudy by purchasing your study materials
> > from:
> >> > > http://shop.groupstudy.com
> >> > >
> >> > > 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:45 GMT-3