From: John Underhill (stepnwlf@magma.ca)
Date: Wed Jun 16 2004 - 17:49:43 GMT-3
I take your point guys, poor nomenclature on Cisco's part, I agree..
thanks.
I still think that setting 'cisco-CIR' above the provisioned rate, is a bad
habit to get into. In my experience, telcos do not typically give away free
bandwidth, if anything, you lease a 128k line, you see traffic peaks at far
less, wether they are rate limiting or have oversubscibed their resources,
I'm not sure, but at three o'clock in the afternoon, you are never going to
get 128k out of that pipe. So if you set cisco-CIR to the access rate, say
1544k, aren't you just inviting BECNs, or for that matter creating more
congestion because of frame loss? What I am really trying to learn is not so
much what may be asked of you in the exam, but a 'best practices' use for
this technology.
----- Original Message -----
From: "Brian Dennis" <bdennis@internetworkexpert.com>
To: "John Underhill" <stepnwlf@magma.ca>; "Brian McGahan"
<bmcgahan@internetworkexpert.com>; "studygroup" <ccielab@groupstudy.com>
Sent: Wednesday, June 16, 2004 3:43 PM
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
> > > >
> > > >
> > > >
> >
> _______________________________________________________________________
> > > > 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
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:42 GMT-3