From: Thomas Larus (tlarus@xxxxxxx)
Date: Fri Dec 07 2001 - 12:37:40 GMT-3
Thanks to everyone for their thoughtful responses! It's nice to have
this crucial point nailed down tight. Let the bandwidth statement
reflect the clock rate statement exactly. On a related note, it seems
like a good practice to specify accurate bandwidth on every interface,
which is not so hard when there are only six or seven routers involved.
Which brings me to a tangentially related point. I just recently used
the Cisco practice lab at NC State for five days, and it was really a
nice experience. Helpful lab technicians and great equipment (including
VoIP, ATM, Cat3920). No 4000 series, though, which I doubt is crucial
anyway except to be aware of the media-type issue on the Ethernet
interfaces.
My impression is that the NC State lab was intended to resemble the
actual CCIE lab, although not precisely. There were 6 routers on each
customer rack, including the termserver. There was also a seventh
router which served as a frameswitch. There was also a backbone rack
that you would configure ATM and voice over IP and some routing
protocols against. I strongly suspect that there are not 10 or twelve
routers used on the examinee's rack in the real lab exam (don't correct
me if I am wrong. I am not fishing for NDA info.) My point is, why do
so many of the practice scenario companies feel the need to use 8, 10,
and 12 router scenarios, unless it is primarily to sell us their rack
time? Most of us are lucky if we can afford to get 6 routers together
in our lab. If they are trying to make their scenarios more complicated
than the real exam, then it may actually be counterproductive, since
many of the people who tell us that they failed say they messed up
something simple. Therefore, excess complexity could end up distracting
us from the important goal of getting down pat all the common and
troublesome issues that so often occur in a six or seven router lab with
IGRP, RIP, OSPF and BGP.
It seems to me that a good way to approach lab study is to work with 6
routers and a frameswitch (I may have to make do with five and the
frame), and do a lot of the basic stuff that we all tend to screw up,
again and again, and again, while exploring and experimenting with many
of the finer points from the IOS 12.1 configuration guides and command
reference.
I just looked at the FAQ/errata from CCBOOTCamp's site, since I am
wrestling with the idea of attempting the lab without buying their
practice labs (which would make me practically the only person on this
list foolhardy enough to try this, it seems). They admit so many
mistakes and leftover commands from other scenarios and ways that could
have been more elegant that I wonder that proctors would hold examinees
to a "perfection" standard. (I do not mean to criticize the practice
labs, as I am sure they are great and perhaps the best out there. I am
only making the point that ALL the gurus (Caslow, etc.) make a lot of
mistakes in their books and scenarios, to the extent that I am beginning
to wonder if it is even possible to have three pages of config files
that don't have at least one glaring mistake. Even the Cisco IOS 12.1
docs seem to have some glaring mistakes. There is nothing wrong with
some mistakes, as they keep us sharp and on our toes, but I would be
troubled if the kinds of mistakes that we find in the expensive
solutions to practice labs and in the Cisco docs would cause one of us
to fail the CCIE because of the "no partial credit" rule.
I fear that the answer is that they would. Sorry for the length of this
post. Now it's time for people to line up like the passengers in the
movie Airplane and slap some sense into me.
Best regards,
Thomas Larus
----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Stephen Oliver
Sent: Friday, December 07, 2001 4:39 AM
To: Chris.Larson@ed.gov; ccielab@groupstudy.com
Subject: RE: "clock rate 1300000." What is the bandwidth, and why can't
y ou set it to something closer to the default BW on fast serial
interfaces ?
1.544Mbps is just a historical thing for serial links. If you want
accurate
metrucs you need to reflect the clocking of the interface in the
bandwidth
statement. As you thought the bandwidth is in kbps so 1300000 clock
rate is
1300kbps hence use
# bandwidth 1300
You need to set bandwidth on serial links to get an accurate metric.
Stevie.
>From: "Larson, Chris (Contractor)" <Chris.Larson@ed.gov>
>Reply-To: "Larson, Chris (Contractor)" <Chris.Larson@ed.gov>
>To: "'Thomas Larus'" <tlarus@mwc.edu>, ccielab@groupstudy.com
>Subject: RE: "clock rate 1300000." What is the bandwidth, and why
can't y
>ou set it to something closer to the default BW on fast serial
interfaces
>?
>Date: Thu, 6 Dec 2001 15:01:40 -0500
>
>Actually we have a 12.1(2)T on a 3640 that reports the serial interface
>bandwidth is 2048(E1 speeds). Of course we don't get E1's here in the
U.S.
>and it is a regular T and the Bandwidth parameter was never changed. I
>cannot explain the discrepency except that this parameter has nothing
to do
>with actual bandwidth and is only used to affect routing metrics or
costs
>so
>you should set it to however you want your metrics that use the
bandwidth
>parameter to see the link.
>
>
>
>
>-----Original Message-----
>From: Thomas Larus [mailto:tlarus@mwc.edu]
>Sent: Thursday, December 06, 2001 2:41 PM
>To: ccielab@groupstudy.com
>Subject: "clock rate 1300000." What is the bandwidth, and why can't you
>set it to something closer to the default BW on fast serial interfaces?
>
>
>The default bandwidth on the serial interfaces on 2500s is 1.544 mbps.
>However, when you set the clock rate, the closest value is 1300000.
>Could someone please explain the discrepancy? Clock rate 64000 gives
>you bandwidth of 64000 mbps. If I use clock rate 1300000, what should
>I put down as the bandwidth of the interface? 1300?
>
>The IOS 12.1 docs on the clock rate command does not explain this.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:40 GMT-3