GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: MINCIR vs CIR posted 08/25/2004
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


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@xxxxxxxxxxxxxxxxxxxxxx>
Sent by: nobody@xxxxxxxxxxxxxx
06/16/2004 03:43 PM
Please respond to "Brian Dennis"

 
        To:     "John Underhill" <stepnwlf@xxxxxxxx>, "Brian McGahan" 
<bmcgahan@xxxxxxxxxxxxxxxxxxxxxx>, "studygroup" <ccielab@xxxxxxxxxxxxxx>
        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@xxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxx>
To: "studygroup" <ccielab@xxxxxxxxxxxxxx>
Cc: "John Underhill" <stepnwlf@xxxxxxxx>; "Geert Nijs"
<geert.nijs@xxxxxxxx>; "Tom Rogers" <cccie71@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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@xxxxxxxx>
> > To: "Tom Rogers" <cccie71@xxxxxxxxx>; "Brian McGahan"
> > <bmcgahan@xxxxxxxxxxxxxxxxxxxxxx>; "studygroup"
> <ccielab@xxxxxxxxxxxxxx>
> > 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@xxxxxxxxx]
> > > 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@xxxxxxxx> 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@xxxxxxxxxxxxxx
> > > [mailto:nobody@xxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxx
> > >
> > > 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@xxxxxxxxxxxxxx
> > > [mailto:nobody@xxxxxxxxxxxxxx] On Behalf
> > > Of
> > > > samccie2004@xxxxxxxxxxx
> > > > 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
> > >
> > >
> > >
>
_______________________________________________________________________
> > > 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 e-mail and any attached files are confidential and
> > > may be legally privileged.
> > > If you are not the addressee, any disclosure,
> > > reproduction, copying, distribution,
> > > or other dissemination or use of this communication is
> > > strictly prohibited.
> > > If you have received this transmission in error please
> > > notify Simac immediately
> > > and then delete this e-mail.
> > >
> > > Simac has taken all reasonable precautions to avoid
> > > virusses in this email.
> > > Simac does not accept liability for damage by virusses,
> > > for the correct and complete
> > > transmission of the information, nor for any delay or
> > > interruption of the transmission,
> > > nor for damages arising from the use of or reliance on
> > > the information.
> > >
> > > All e-mail messages addressed to, received or sent by
> > > Simac or Simac employees
> > > are deemed to be professional in nature. Accordingly,
> > > the sender or recipient of
> > > these messages agrees that they may be read by other
> > > Simac employees than the official
> > > recipient or sender in order to ensure the continuity of
> > > work-related activities
> > > and allow supervision thereof.
> > >
> > >
>
########################################################################
> > > #############
> > >
> > >
> > >
>
_______________________________________________________________________
> > > 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
> > >
> > >
> > >
> > > ________________________________
> > >
> > > Do you Yahoo!?
> > > Yahoo! Mail
> > >
>
<http://us.rd.yahoo.com/mail/taglines/*http://promotions.yahoo.com/new_m
> > > ail/static/protection.html>  - You care about security. So do we.
> > >
> > >
>
_______________________________________________________________________
> > > 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

_______________________________________________________________________
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