From: D. J. Jones (meganac@xxxxxxxx)
Date: Wed Dec 27 2000 - 11:08:42 GMT-3
I think I may have been in error Julie Ann. here is another link specific
to RSVP parms only. Your original thinking was correct. Could someone help
distinguish the difference between the two and under what circumstances they
should be used? I would think even under a situation in
which you were configuring for rsvp, that you should be able to specify a
maximum buffer size? Or would that be negotiated during the time
of reservation? ..dj
qos commands
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_
r/qrdcmd1.htm#xtocid2777413
frame relay commands
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/wan_
r/wrdfrely.htm#37411
----- Original Message -----
From: "Connary, Julie Ann" <jconnary@cisco.com>
To: "D. J. Jones" <meganac@home.com>
Cc: <ccielab@groupstudy.com>
Sent: Wednesday, December 27, 2000 5:35 AM
Subject: Re: frame relay traffic shaping and rsvp
> Thanks, that makes sense. I guess the software just knows to skip the 3rd
> parameter since 1000 is greater than 100.
>
> Julie Ann
>
> At 03:09 PM 12/26/2000 -0800, D. J. Jones wrote:
> >Julie Ann,
> >
> >I think what the fair-queue 64 256 1000 statement is saying is that you
will
> >have 64 allowed messages in each queue, 256 dynamic queues to be used for
> >best effort conversations and a maximum buffer size of 1000 bytes.
> >
> >The number of reserved queues which you may be thinking of only has a
range
> >from 0 to 100 and a default value of 2. If you were to use all of the
> >optional parms, then your statement would read:
> >
> >fair-queue 64 16 2 600
> >
> >If someone else reads this differently, please let me know..dj
> >
> >Here is a reference URL
> >
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/wan
_
> >r/wrdfrely.htm#37411
> >
> >----- Original Message -----
> >From: "Connary, Julie Ann" <jconnary@cisco.com>
> >To: <ccielab@groupstudy.com>
> >Sent: Tuesday, December 26, 2000 1:40 PM
> >Subject: frame relay traffic shaping and rsvp
> >
> >
> > > Hi All,
> > >
> > > I am working on a lab that calls for frame-relay traffic shaping and
rsvp.
> > >
> > > My question is that when fair queing is enabled, the solution says:
> > >
> > > fair-queue 64 256 1000
> > >
> > > Does this not set up 1000 rsvp queues ( fair-queue
> > > [congestive-discard-threshold[dynamic-queues[reservable-queues]]]] and
why
> > > would I need that many? Or am I misenterpreting the 1000?
> > >
> > >
> > > Also what experience do people have using frame-relay traffic shaping
with
> > > map-classes vs. using the
> > > traffic-shape rate command directly under the interface ( (From the
> >command
> > > reference for 12.0)?
> > >
> > > ------------------------------------------------
> > >
> > > traffic-shape rate
> > >
> > > To enable traffic shaping for outbound traffic on an interface, use
the
> > > traffic-shape rate interface configuration command. To disable traffic
> > > shaping on the interface,
> > > use the no form of this command.
> > >
> > > traffic-shape rate bit-rate [burst-size [excess-burst-size]]
> > > no traffic-shape rate
> > >
> > > Syntax Description
> > >
> > > bit-rate
> > > Bit rate that traffic is shaped to in bits per second.
> >This
> > > is the access bit rate that you contract with your service provider,
or
> >the
> > > service levels you intend to
> > > maintain.
> > > burst-size
> > > (Optional) Sustained number of bits that can be
> >transmitted
> > > per interval. On Frame Relay interfaces, this is the committed burst
size
> > > contracted with your service
> > > provider.
> > > excess-burst-size
> > > (Optional) Maximum number of bits that can exceed the
> >burst
> > > size in the first interval in a congestion event. On Frame Relay
> > > interfaces, this is the excess burst size
> > > contracted with your service provider. The default is
> >equal
> > > to the burst-size.
> > >
> > >
> > >
> > > Default
> > >
> > > Traffic shaping is disabled.
> > >
> > > Command Mode
> > >
> > > Interface configuration
> > >
> > > Usage Guidelines
> > >
> > > This command first appeared in Cisco IOS Release 11.2.
> > >
> > >
> > > Note Traffic shaping is not supported with optimum, distributed, or
flow
> > > switching. If you enable this command, all interfaces will revert to
fast
> > > switching:
> > >
> > >
> > > Traffic shaping uses queues to limit surges that can congest a
network.
> > > Data is buffered and then sent into the network in regulated amounts
to
> > > ensure that traffic will
> > > fit within the promised traffic envelope for the particular
connection.
> > >
> > > Use traffic shaping if you have a network with differing access rates
or
> >if
> > > you are offering a subrate service. You can configure the values
according
> > > to your contract
> > > with your service provider or the service levels you intend to
maintain.
> > >
> > > An interval is calculated as follows:
> > >
> > > If the burst-size is not equal to zero, the interval is the
> > > burst-size divided by the bit-rate.
> > >
> > > If the burst-size is zero, the interval is the excess-burst-size
> > > divided by the bit-rate.
> > >
> > > Traffic shaping is supported on all media and encapsulation types on
the
> > > router. To perform traffic shaping on Frame Relay virtual circuits,
you
> >can
> > > also use the
> > > frame-relay traffic-shaping command. For more information on Frame
Relay
> > > traffic shaping, refer to the "Configuring Frame Relay" chapter in the
> > > Wide-Area
> > > Network Configuration Guide.
> > >
> > > ------------------------------------------------------------
> > >
> > >
> > > Thanks,
> > > Julie Ann
> >
> ------------------------------------------------------------------------
> > > Julie Ann Connary
> > > | | Network Consulting Engineer
> > > ||| ||| Federal Support Program
> > > .|||||. .|||||. 13635 Dulles Technology
Drive,
> > > Herndon VA 20171
> > > .:|||||||||:.:|||||||||:. Pager: 1-888-642-0551
> > > c i s c o S y s t e m s Email: jconnary@cisco.com
> > >
> >
> ------------------------------------------------------------------------
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:26:11 GMT-3