From: Dave Meyer (dave.meyer@db.com)
Date: Wed Aug 25 2004 - 15:58:05 GMT-3
Brian,
What is the purpose of the min cir in this example being that adaptive
shaping is disabled ?
Configuration Example 8: Frame Relay Traffic Shaping
interface Serial 0/1
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
frame-relay interface-dlci 128
class voice
!
map-class frame-relay voice
no frame-relay adaptive-shaping
frame-relay cir 256000
frame-relay bc 2560
frame-relay mincir 256000
In this example, Frame Relay traffic shaping is enabled on the main serial
interface 0/1 and DLCI 128 is placed into a voice shaping class. Map class
voice sets up a CIR of 256000 bps and a committed burst rate (Bc) of 2560
bits. This configuration means that the router will send 2560 bits every
2560/256,000 seconds (10 ms) and queue any excess bursts. The minimum CIR
is set to the same value as CIR, and adaptive shaping is disabled. The
Frame Relay excess burst (Be) value is not set and therefore defaults to
0, preventing any bursting over CIR. This is the recommended configuration
for traffic shaping when carrying VoIP.
Regards,
Dave
______________________________________________
Architecture & Engineering
Work: (973) 682-4435
Cell: (973)907-4963
----- Forwarded by Dave Meyer/NewYork/DBNA/DeuBa on 08/25/2004 02:52 PM
-----
"Brian Dennis" <bdennis@internetworkexpert.com>
Sent by: nobody@groupstudy.com
06/16/2004 03:43 PM
Please respond to "Brian Dennis"
To: "John Underhill" <stepnwlf@magma.ca>, "Brian McGahan"
<bmcgahan@internetworkexpert.com>, "studygroup" <ccielab@groupstudy.com>
cc:
Subject: RE: MINCIR vs CIR
John,
Do not take Cisco's terminology used in regards to the
IOS FRTS
commands and try to compare it to industry terminology. Yes, the
industry term for CIR is "the rate at which a Frame Relay network agrees
to transfer information under normal conditions, averaged over a minimum
increment of time", BUT that doesn't mean that this is the CIR value
that should be entered in the "frame-relay cir" command.
In regards to the Cisco IOS FRTS commands, the CIR
(frame-relay
cir) is the rate at which you want to send data at. It 'could' or
'could not' be the same as the service provider's CIR. It is up to you
to decide if you want to conform to the service provider's CIR or not.
If you think that you can send data above the service provider's CIR
then you configure the router's CIR (frame-relay cir) to that higher
rate. If you want to throttle down to the service provider's CIR upon
the receipt of BECN's, then configure the minCIR (frame-relay mincir) to
equal the service provider's CIR and enable adaptive shaping
(frame-relay adaptive-shaping). If you do not enable adaptive shaping,
the frame-relay mincir command has not effect.
It would have created a lot less confusion if Cisco would
have
named the "frame-relay cir" command, "frame-relay traffic-rate", or
something similar because as I mentioned this is the rate you want the
router to send data at. Cisco should have then changed "frame-relay
mincir" to "frame-relay cir". Also by default if the map-class has the
"frame-relay cir" AND the "frame-relay traffic-rate" commands
configured, adaptive shaping should have become enabled.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
John Underhill
Sent: Wednesday, June 16, 2004 11:06 AM
To: Brian McGahan; studygroup
Cc: Geert Nijs; Tom Rogers
Subject: Re: MINCIR vs CIR
Brian,
I don't necessarily disagree with you but..
Well for one, this would seem to run contrary to the rather murky way
Cisco
defines CIR in their docs:
CIR-committed information rate. The rate at which a Frame Relay network
agrees to transfer information under normal conditions, averaged over a
minimum increment of time.
This line: 'The rate at which a Frame Relay network agrees to transfer
information under normal conditions' implies an agreed upon, or
provisioned
rate.
Also, if you are oversubscribing the line for an extended period of
time,
your provider will usually either bill you for the traffic as part of
your
SLA, or simply drop the excess traffic.. so really it comes down to best
practices versus vendor symantics. If I were to set my CIR to AR rate, I
would create a backflow, and cause a great deal more congestion with
retransmissions then if I were to simply set MINCIR and CIR to the
agreed
upon provisioned rate.
Am I wrong?
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "studygroup" <ccielab@groupstudy.com>
Cc: "John Underhill" <stepnwlf@magma.ca>; "Geert Nijs"
<geert.nijs@simac.be>; "Tom Rogers" <cccie71@yahoo.com>
Sent: Wednesday, June 16, 2004 1:31 PM
Subject: RE: MINCIR vs CIR
> John,
>
> It's not listed in the standards because it's a Cisco specific
> implementation. minCIR is a value used in conjunction with adaptive
> frame-relay traffic-shaping to define the lowest possible value you
will
> shape down to in the case of a congestion notification. Congestion
> notification can occur due to receipt of a BECN notification, a
> foresight notification, or due to the exceeding of a defined output
> queue length.
>
> The logic of averaging a rate higher than what you are
> provisioned is that you are betting that the provider cloud is not
> congested 100% of the time. By configuring an average shaping rate
> (Cisco CIR) to higher than what is provisioned (provider CIR, Cisco
> minCIR), you are betting on the fact that the cloud will notify you of
> congestion with a BECN or foresight notification, at which time you
will
> slow down.
>
> The biggest confusion with Cisco's FRTS is their usage of the
> term CIR. Cisco's CIR value in the frame-relay map-class
configuration
> simply defines the rate at which traffic is moved from the
> traffic-shaping queue to the transmit ring of the interface. This
value
> does not relate to the provisioned rate for the circuit. For this
> reason they added the additional value of minCIR to have a field that
> may relate to the provisioned rate of the circuit.
>
>
> 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
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > John Underhill
> > Sent: Wednesday, June 16, 2004 11:19 AM
> > To: Geert Nijs; Tom Rogers; Brian McGahan; studygroup
> > Subject: Re: MINCIR vs CIR
> >
> > For one thing, it is unlikely that you will see mincir as part of
your
> > SLA,
> > the switch does not know what you have set mincir to, or how your
> router
> > will react to becns, but only drops traffic when it exceeds a
certain
> > rate,
> > (and not many providers are using cisco lmi, because they have to
> maintain
> > vendor neutral standards..). Mincir is not part of the lmi exchange
> > standard, because it is a local, discretionary value. If you have
> > purchased
> > 128k, and they start dropping traffic at 64k, it's time to put your
> > yelling
> > hat on and call the provider.
> > CIR = the bandwidth you have purchased.
> > FRF NNI agreement standard:
> > http://www.mplsforum.org/frame/Approved/FRF.2/FRF_2_2-final.pdf
> >
> > <Cisco Quote:>
> > When the congestion level exceeds a configured value called queue
> depth,
> > the
> > sending rate of all PVCs is reduced to the minimum committed
> information
> > rate (minCIR). As soon as interface congestion drops below the queue
> > depth,
> > the traffic-shaping mechanism changes the sending rate of the PVCs
> back to
> > the committed information rate (CIR). This process guarantees the
> minCIR
> > for
> > PVCs when there is interface congestion.</Quote>
> > Seems pretty plain to me.. Mincir is a congestion control mechanism.
> >
>
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_
> gu
> > ide09186a0080087b91.html
> >
> > Here is a good explaination of how frame is working, including all
the
> > standards, note in an illustration of an lmi frame, there is no
> 'mincir'
> > field.
> > http://www.protocols.com/pbook/frame.htm
> >
> >
> >
> > ----- Original Message -----
> > From: "Geert Nijs" <geert.nijs@simac.be>
> > To: "Tom Rogers" <cccie71@yahoo.com>; "Brian McGahan"
> > <bmcgahan@internetworkexpert.com>; "studygroup"
> <ccielab@groupstudy.com>
> > Sent: Wednesday, June 16, 2004 4:15 AM
> > Subject: RE: MINCIR vs CIR
> >
> >
> > > Higher average bandwidth maybe ??
> > >
> > > I know many people think that CIR is "the guaranteed rate". And,
in
> real
> > > life, many times, MINCIR is equal to CIR.
> > > But, as you can read in the white paper on the
internetworkingexpert
> > > site, MINCIR is the rate at which your service provider will start
> > > marking packets as DE.
> > >
> > > So, the question now is: why not try to sent at a higher rate and
> > > falling back to MINCIR when we receive BECNs ??
> > > Suppose there is no congestion in the Frame Relay cloud of the
ISP,
> the
> > > ISP marks packets with DE but they don't get dropped
> > > since there is no congestion. So we could sent at a higher
> rate.......
> > >
> > > So, when the lab says "Your ISP will mark every packet above
48kbps
> with
> > > the DE-bit",
> > > then, i must correct myself, and say that 48kbps is the MINCIR.
> > > I can try to send at a higher rate, and fall back to the MINCIR
when
> > > congestion occurs.
> > > In this case, my CIR and the frame-relay providers CIR are
> > > different.....
> > > Right ?
> > >
> > > Geert
> > >
> > > -----Oorspronkelijk bericht-----
> > > Van: Tom Rogers [mailto:cccie71@yahoo.com]
> > > Verzonden: woensdag 16 juni 2004 5:08
> > > Aan: Geert Nijs; Brian McGahan; studygroup
> > > Onderwerp: Re: MINCIR vs CIR
> > >
> > >
> > > Geert,
> > > If DE is going to set above minCIR, then what the point of
> > > having cir?
> > >
> > > Tom
> > >
> > > Geert Nijs <geert.nijs@simac.be> wrote:
> > >
> > > I am also confused about the deliniation between CIR and
> > > MINCIR. Can
> > > someone give some examples on how the lab
> > > would formulate these parameters ?
> > >
> > > If the lab specifies:
> > > "Your ISP provider will mark every packet above 48kbps
> > > with the DE-bit"
> > >
> > > Then CIR = 48 kbps ? Right ?
> > >
> > >
> > > If the lab specifies:
> > > "Your ISP provider will mark every packet above 48kpbs
> > > with the BECN-bit"
> > > (in the opposite direction is implicitely
> > > assumed here ??)
> > >
> > > Then MINCIR = 48 kbps ? Right ?
> > >
> > > Regards,
> > > Geert
> > >
> > > -----Oorspronkelijk bericht-----
> > > Van: nobody@groupstudy.com
> > > [mailto:nobody@groupstudy.com] Namens Brian
> > > McGahan
> > > Verzonden: dinsdag 15 juni 2004 19:27
> > > Aan: studygroup
> > > Onderwerp: RE: Bandwidth Vs MinCIR for CBWFQ
> > >
> > >
> > > The MINCIR value in the frame-relay map-class is simply
> > > used to
> > > define a worst case rate you will shape down to when the
> > > BECN bit is set
> > > in frames you receive from the frame-relay network.
> > >
> > > 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
> > >
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com
> > > [mailto:nobody@groupstudy.com] On Behalf
> > > Of
> > > > samccie2004@yahoo.co.uk
> > > > Sent: Monday, June 14, 2004 12:29 PM
> > > > To: studygroup
> > > > Subject: Bandwidth Vs MinCIR for CBWFQ
> > > >
> > > > Hi Group
> > > >
> > > > When asked to guarantee BW foe QOS using CBWFQ on
> > > interfaces
> > > encapsulated
> > > > with frame-relay. What is the correct way to do so.
> > > >
> > > > Do I apply Bandwidth statement as I would for a HDLC
> > > interafce or even
> > >
> > > > ethernet, or do I rely on shapping DLCI with a MIncir
> > > equal the BW
> > > > required.
> > > >
> > > > TIA
> > > >
> > > > Sam
> > >
> > >
> > >
>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:48 GMT-3