From: Scott Morris (swm@emanon.com)
Date: Tue Jan 27 2004 - 22:49:59 GMT-3
Many times there are items within the CCIE lab that would indicate the
preference of one path via another, and setting the bandwidth (depending on
routing protocol) could help in obtaining some of the metrics you want
through normal operation.
It is a "definite" during most QoS operations where bandwidth is reserved,
but it's something good to pay attention to otherwise.
On the flip side, if you get in the habit of setting bandwidth on all of
your serial lines, you are sure that you won't have points deducted because
of that action. :)
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Packet Man
Sent: Tuesday, January 27, 2004 7:01 PM
To: swm@emanon.com; ccielab@groupstudy.com
Subject: RE: Bandwidth command on actual ccie lab
Thanks, Scott,
I agree with you that the issue in that practice lab was more one of wording
than anything else. I suspect the thing to do in the lab in a similar
situation is to ask the proctor for clarification. Do you agree?
Earlier you said along the lines of ...it's always a good idea to explicitly
specify the bandwidth of the interface. In your opinion, if the lab
requirements don't say or imply to specify the bandwidth, do you think it's
a good idea to use the bandwidth command just the same?
Thanks
>From: "Scott Morris" <swm@emanon.com>
>To: "'Packet Man'" <ccie2b@hotmail.com>
>Subject: RE: Bandwidth command
>Date: Tue, 27 Jan 2004 17:36:06 -0500
>
>In that case, it would likely be more of a wording issue, but very
>important that you have gone through like you have to understand that!
>
>The other consideration is that often we get "hung up" on the wording
>of things because we may have spent a lot of time win the
>traffic-shaping/QoS stuff lately, so CIR automatically denotes one of
those...
>
>If you go out to many network admins and talk about CIR, they think
>link bandwidth. :)
>
>But hey... Life goes on!
>
>Scott
>
>-----Original Message-----
>From: Packet Man [mailto:ccie2b@hotmail.com]
>Sent: Tuesday, January 27, 2004 2:30 PM
>To: swm@emanon.com; ccielab@groupstudy.com
>Subject: RE: Bandwidth command
>
>Hi Scott,
>
>Thanks for your responses to this issue.
>
>Typically, I assume that if my solution is different from the lab
>solution, my solution is the wrong one and then I try to understand why
>solution is wrong and the provided solution is correct. Sometimes,
>it's apparent but other times it's not and other times the provided
>solution happens to be wrong. And, it usually takes a lot of
>convincing for me to conclude the provided solution is incorrect, but
>based on the responses from you and others, it looks to me that this is
the case with this lab.
>
>In this practice lab, the requirement was to "Assume a CIR of" various
>rates on various PVC's. In no place did any requirements say anything
>about what the purpose of the CIR was ie. the cir should be used be the
>routing protocol to determine path cost.
>
>Initially, so I thought, I would need to configure either GTS or FRTS
>to implement the assumed CIR's. But, when I looked at the solution,
>surprisingly, this is what was there.
>
>****************
>
>int s0
>no ip address
>encap frame-relay
>service-policy output
>
>int s0.x point-to-point
>bandwidth X <-------- X = CIR from lab requirement
>ip address x.x.x.x
>frame-relay interface-dlci xxx
>
>*****************
>
>Other requirements in the lab had to do with classifying traffic and
>setting various traffic policies such as setting ip prec and alloting a
>certain percentage of the bandwidth to the various traffic classes.
>
>I suppose it's a judgement call, but in this case, it seems to me that
>the bandwidth command doesn't fulfill the lab requirement, "Assume a
>CIR of X on PVC ..."
>
>What do you think?
>
>And, in the actual ccie lab, given the same requirement, would you
>configure some sort of traffic shaping or policing or would you
>configure the bandwidth command?
>
>Thanks in advanced
>
>
>
>
>
>
> >From: "Scott Morris" <swm@emanon.com>
> >To: "'Packet Man'"
> ><ccie2b@hotmail.com>,<David.Bartlett@reuters.com>,<ccielab@groupstudy
> >.c
> >om>
> >Subject: RE: Bandwidth command
> >Date: Tue, 27 Jan 2004 13:01:25 -0500
> >
> >Think about what it's used for any why... Think about the WHOLE picture.
> >Don't just assume the lab has it's head stuck someplace where the sun
> >doesn't shine just because one reply said the two aren't related. :)
> >
> >
> >Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
> >CISSP, JNCIS, et al.
> >IPExpert CCIE Program Manager
> >IPExpert Sr. Technical Instructor
> >swm@emanon.com/smorris@ipexpert.net
> >http://www.ipexpert.net
> >
> >
> >-----Original Message-----
> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> >Of Packet Man
> >Sent: Tuesday, January 27, 2004 12:20 PM
> >To: David.Bartlett@reuters.com; ccielab@groupstudy.com
> >Subject: RE: Bandwidth command
> >
> >Thank you. I thought the solution wasn't correct but I tend to
> >assume that the people who write these practice labs know this stuff
> >better than
>I
>do.
> >This just shows you that you can't always accept as fact what they say.
> >
> >
> > >From: David Bartlett <David.Bartlett@reuters.com>
> > >To: Packet Man <ccie2b@hotmail.com>, ccielab@groupstudy.com
> > >Subject: RE: Bandwidth command
> > >Date: Tue, 27 Jan 2004 16:42:02 +0000
> > >
> > >That's correct - the bw statement configured on an interface is
> > >only used by routing protocol best path calculations. To define
> > >actual CIR etc you would need to employ traffic shaping.
> > >
> > >David.
> > >
> > >-----Original Message-----
> > >From: Packet Man [mailto:ccie2b@hotmail.com]
> > >Sent: 27 January 2004 15:20
> > >To: ccielab@groupstudy.com
> > >Subject: Bandwidth command
> > >
> > >
> > >Hi all,
> > >
> > >I'm doing a practice lab which instructs me to set the CIR on
> > >various F/R p2p sub-interfaces. For example, it said to "Assume a
> > >CIR of 256k on the PVC to R3, a CIR of 128k to R2"... etc
> > >
> > >I was thinking about whether I should use GTS or FRTS, but in the
> > >solution configs, it used the bandwidth command to fulfill that
> > >requirement which I don't think is correct.
> > >
> > >Just to double check, I looked up the bandwidth command and this is
> > >what it said,
> > >
> > >
> > >Bandwidth Information
> > >The bandwidth command sets an informational parameter to
> > >communicate only the current bandwidth to the higher-level
> > >protocols; you cannot adjust the actual bandwidth of an interface using
this command.
> > >
> > >
> >
> >---------------------------------------------------------------------
> >---
> > >--------
> > >Note This is a routing parameter only; it does not affect the
>physical
> > >
> > >interface.
> > >
> >
> >---------------------------------------------------------------------
> >---
> > >--------
> > >
> > >Changing Bandwidth
> > >For some media, such as Ethernet, the bandwidth is fixed; for other
> > >media, such as serial lines, you can change the actual bandwidth by
> > >adjusting hardware. For both classes of media, you can use the
> > >bandwidth configuration command to communicate the current
> > >bandwidth to the higher-level protocols.
> > >
> > >***********************
> > >
> > >I have 2 questions:
> > >
> > >Based on the stated requirement, does using the bandwidth command
> > >fulfill the requirement?
> > >
> > >Does using the bandwidth command shape or police traffic that
> > >exceeds the amount specified in the bandwidth command?
> > >
> > >The way I read it, the only thing the bandwidth command does is
> > >tell
>the
> > >
> > >routing protocol what bandwidth value to use in calculating costs.
> > >Do you agree?
> > >
> > >Thanks in advance.
> > >
> > >_________________________________________________________________
> > >High-speed usersbe more efficient online with the new MSN Premium
> > >Internet Software.
> > >http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
> > >
> > >___________________________________________________________________
> > >____ 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
> > >
> > >
> > >-------------------------------------------------------------- --
> > > Visit our Internet site at http://www.reuters.com
> > >
> > >Get closer to the financial markets with Reuters Messaging - for
> > >more information and to register, visit
> > >http://www.reuters.com/messaging
> > >
> > >Any views expressed in this message are those of the individual
> > >sender, except where the sender specifically states them to be
> > >the views of Reuters Ltd.
> > >
> >
> >_________________________________________________________________
> >Let the new MSN Premium Internet Software make the most of your
>high-speed
> >experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
> >
> >_____________________________________________________________________
> >__ 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
> >
>
>_________________________________________________________________
>Check out the new MSN 9 Dial-up - fast & reliable Internet access with
>prime
>
>features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1
>
>
This archive was generated by hypermail 2.1.4 : Mon Feb 02 2004 - 09:07:51 GMT-3