From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Sep 29 2005 - 15:08:03 GMT-3
> Actually that answers a huge question I have yet to be able to
> formulate... Which was: Why do you have the option to place MQC
inside
> a frame-relay map-class and when would you want to use it?
Yes, but that's just one of the reasons. The main advantage is
that you can do arbitrary fancy queueing on a per-VC basis. Inside a
legacy FRTS map-class you can call the legacy priority queue, rtp
priority queue, and custom queue, but these are less preferable to the
flexibility of the MQC.
You can still do legacy shaping inside the map-class and then
call a policy-map for queueing options, but in that case the shaped rate
applies overall to all classes. Take the following example:
map-class frame-relay LEGACY_FRTS
frame-relay cir 768000
service-policy output MQC_POLICY
The above map-class shapes to a rate of 768Kbps, and calls an
MQC policy-map. With this configuration all traffic matched in the MQC
policy is shaped to a rate of 768Kbps as an *aggregate*.
On the other hand shaping inside the MQC called from a map-class
allows you to shape different classes to individual rates inside the
per-VC queue, such as follows:
class-map match-all ICMP
match protocol icmp
class-map match-all FTP
match protocol ftp
!
policy-map MQC_FRTS_POLICY
class ICMP
shape average 8000
class FTP
shape average 512000
class class-default
shape average 248000
!
map-class frame-relay MQC_FRTS
service-policy output MQC_FRTS_POLICY
The above map-class still shapes to an average aggregate rate of
768Kbps, but inside this rate classes ICMP, FTP, and default are shaped
differently.
Overall it really boils down to how granular you need your
policy to be. In the future I would imagine that the map-class
configuration will become obsolete, and per VC queueing will be applied
directly through service-policy application at the VC level. However in
the meantime it's kind of a band-aid solution they have where the only
way to apply MQC to a per-VC queue is through the legacy map-class.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
> Sent: Thursday, September 29, 2005 12:49 PM
> To: Brian McGahan
> Subject: RE: MQC bandwidth
>
> Thanks Brian,
>
> Actually that answers a huge question I have yet to be able to
> formulate... Which was: Why do you have the option to place MQC
inside
> a frame-relay map-class and when would you want to use it?
>
> I think the simple answer is that it gives us an option to shape on a
> per-DLCI basis and at the same time, provide fragmentation and
> interleaving on a per-DLCI basis. Otherwise, the other way to shape
is
> with FRTS but that only allows a per interface fragmentation without
> interleaving capabilities.
>
> Yes?
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Wednesday, September 28, 2005 5:59 PM
> To: Edwards, Andrew M; ccielab@groupstudy.com
> Subject: RE: MQC bandwidth
>
> Yes and no. The feature described in that link is fragmentation
> at the interface level without FRTS enabled. When FRTS is disabled
all
> VCs share the same output queue, whether they're on the main or
> subinterface.
>
> Specifically it says:
>
> "This new feature simplifies the configuration of low-latency,
> low-jitter quality of service (QoS) by enabling the queueing policy
and
> fragmentation configured on the main interface to apply to all
permanent
> virtual circuits (PVCs) and subinterfaces under that interface."
>
> The reason why it applies to all VCs is because all VCs share
> the same output queue when FRTS is disabled, onto which the
> fragmentation is applied.
>
> "Before the introduction of this feature, queueing and fragmentation
had
> to be configured on each individual PVC."
>
> This is true because previously fragmentation could only be
> applied through FRTS, which implies per VC queueing.
>
> "For interleaving to work, both fragmentation and the low-latency
> queueing policy must be configured with shaping disabled"
>
> This is also true because interface level fragmentation requires
> the usage of a single output queue for all VCs, which FRTS does not
> have.
>
> For fragmentation to be supported in conjunction with shaping
> the fragmentation parameters need to be defined inside a "frame-relay
> map-class" in which legacy or MQC based FRTS is applied.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
> > -----Original Message-----
> > From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
> > Sent: Wednesday, September 28, 2005 5:58 PM
> > To: Brian McGahan
> > Subject: RE: MQC bandwidth
> >
> > Well, I was reading on doccd that when shaping is enabled and FRF.12
> is
> > enabled, interleaving does not occur.
> >
> > "Subrate shaping can also be applied to the interface, but
> interleaving
> > of high-priority frames will not work when shaping is configured. If
> > shaping is not configured, each PVC will be allowed to send bursts
of
> > traffic up to the physical line rate.
> >
> > When shaping is configured and traffic exceeds the rate at which the
> > shaper can send frames, the traffic is queued at the shaping layer
> using
> > fair queueing. After a frame passes through the shaper, the frame is
> > queued at the interface using whatever queueing method is
configured.
> If
> > shaping is not configured, then queueing occurs only at the
interface.
> >
> >
> >
> >
>
------------------------------------------------------------------------
> > --------
> >
> > Note For interleaving to work, both fragmentation and the
low-latency
> > queueing policy must be configured with shaping disabled."
> >
> >
> >
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft
> > /122t/122t13/frfrintq.htm
> >
> > Yes....?
> >
> > -----Original Message-----
> > From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > Sent: Wednesday, September 28, 2005 4:55 PM
> > To: Edwards, Andrew M
> > Subject: RE: MQC bandwidth
> >
> > What exactly do you mean that it doesn't support interleaving?
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > > -----Original Message-----
> > > From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
> > > Sent: Wednesday, September 28, 2005 5:54 PM
> > > To: Brian McGahan
> > > Subject: RE: MQC bandwidth
> > >
> > > Does the fact that the IOS can maintain multiple shaping queues
> > explain
> > > why FRF.12 doesn't support interleaving?
> > >
> > > Thanks,
> > >
> > > Andy
> > >
> > > -----Original Message-----
> > > From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > > Sent: Wednesday, September 28, 2005 2:18 PM
> > > To: Stefan Grey; ccielab@groupstudy.com
> > > Subject: RE: MQC bandwidth
> > >
> > > Stefan,
> > >
> > > Assuming you are referring to Frame Relay QoS it depends if you
> > are
> > > doing per-VC queueing or not. By default there is one shared
> > output
> > > queue for the interface regardless of how many VCs or
subinterfaces
> > you
> > > have. In this case QoS is applied to the main interface since
there
> > is
> > > only one output queue, and hence only one "bandwidth" value that
is
> > > significant.
> > >
> > > With legacy and MQC based Frame Relay Traffic Shaping each VC is
> >
> > > assigned a separate output queue that in turn contends for the
> > transmit
> > > ring of the interface. Since there are separate output queues you
> can
> >
> > > apply separate QoS attributes onto then, either at the main
> interface,
> >
> > > subinterface, or VC level. In this case the available bandwidth
for
> a
> >
> > > particular queue is based on the "mincir" value, either as defined
> by
> > > the "frame-relay mincir" command in legacy FRTS or the "shape
> > adaptive"
> > > command in the MQC. By default this value is half of the
configured
>
> > > "cir" or "average" rate.
> > >
> > > If you have a specific practice lab task that you want more
> > > information about for QoS feel free to post it, otherwise check
here
> > for
> > > more information:
> > >
> > >
> >
>
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a
> > > 00800a4754.shtml
> > >
> > > HTH,
> > >
> > > Brian McGahan, CCIE #8593
> > > bmcgahan@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com
> > > Toll Free: 877-224-8987 x 705
> > > Outside US: 775-826-4344 x 705
> > > 24/7 Support: http://forum.internetworkexpert.com
> > > Live Chat: http://www.internetworkexpert.com/chat/
> > >
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf
> > > Of
> > > > Stefan Grey
> > > > Sent: Wednesday, September 28, 2005 11:25 AM
> > > > To: ccielab@groupstudy.com
> > > > Subject: MQC bandwidth
> > >
> > > >
> > > > Hello group,
> > > >
> > > > Question:
> > > >
> > > > "Output queue calculations for the MQC are based on the
configured
>
> > > > bandwidth value of the interface and not the speed the interface
> is
> > > > clocked at.
> > > Be
> > > > sure to set the appropriate bandwidth value when configuring the
> MQC
> > > on an
> > > > interface."
> > > >
> > > > When we configure CBWFQ on the subinterface should we configure
> the
> > > > reference bandwidth on the subinterface itself or on the
physical
> > > > interface.
> > > > Where does router look for reference??
> > > >
> > > >
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:17 GMT-3