From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Jun 16 2004 - 16:43:08 GMT-3
John,
Admittedly, the terminology is quite confusing. It took me some time to get
it straight. So, here's how I think of it. Maybe this will help you.
When a SP agrees to a certain CIR, it's saying, in effect, it guarantees
that you can transmit that amount of data regardless of the congestion level
in their network. So, for example, if the SP provisions 256k, the SP's term
is CIR, when will you ever voluntarily send less than that guarnateed amount
of traffic assuming you have that amount of traffic to send?
The answer, of course, is NEVER. Therefore, what's the minimum amount of
traffic you're going to configure your router to send? In this case, it's
256k. Why? Because that's what you paid for and that's what the SP
guarantees. The Cisco term for this is minCIR.
The next question is when (or under what circumstances) will you send just
the minimum that the SP guaranteed? When your router hears via BECN's that
there's congestion in the SP network.
The implication here is that you're going to configure your router to always
send above the minCIR ( the SP's CIR) unless you get BECN's, in which case
you'll have the router throttle down the rate at which it sends traffic into
the network. In order to do this, you must configure the adaptive shaping
command.
Now, in the lab, unless you're told to configure the router to throttle
down, or "adapt", the rate at which the router sends data, there's no need
to configure either the minCIR or adaptive shaping.
Next, you have to know what rate to configure for the router's CIR. Keep in
mind this is NOT the SP's CIR. This CIR typically is an amount that's
higher than the SP's CIR because as you saw from before the SP's CIR is the
minCIR at which your router should send data. So, what value should you use
for this CIR? The wording may differ but, what you're looking for is
something along the lines of "Target" rate or "Average" rate or "Desired"
rate. Also, keep in mind, that this rate might not be given to you
explicitly. For example, if you're configuring FRTS on a hub router for a
dlci that goes to spoke router and the spoke router's port speed is 128k, if
your hub router sends data at any rate on average higher than that, it will
overwhelm the spoke router. And, you probably don't want to do that. Right?
Now, I'm not going to explain Bc or Be or Tc as these terms and some other
terms are explained elsewhere much better than I can do so. In particular,
go to www.Internetworkexpert.com and look for the FRTS presentation the 2
Brian's put together. This is probably one of the best explanations of FRTS
that exists anywhere and it has some great examples.
HTH
----- Original Message -----
From: "John Underhill" <stepnwlf@magma.ca>
To: "Brian McGahan" <bmcgahan@internetworkexpert.com>; "studygroup"
<ccielab@groupstudy.com>
Cc: "Geert Nijs" <geert.nijs@simac.be>; "Tom Rogers" <cccie71@yahoo.com>
Sent: Wednesday, June 16, 2004 2:06 PM
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:41 GMT-3