From: Bob Sinclair (bsin@cox.net)
Date: Sun Nov 14 2004 - 16:07:34 GMT-3
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.
>> >> > >
>> >> > >
>> > _______________________________________________________________________
>> >> > > 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
>> >> >
>> >> >
> _______________________________________________________________________
>> >> > 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
>> >>
>> >> _______________________________________________________________________
>> >> 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:45 GMT-3