From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Mon Aug 30 2004 - 15:00:57 GMT-3
I disagree. Putting configuration statements there just for the
sake of it shows a lack of understanding of the technology. With this
logic why not just put all commands in and see what happens?
This is the same case of trying to apply general rules to
configuration, like always use loopback peerings in BGP or always use
the no peer neighbor-route command. While there certainly are
appropriate cases for these configurations, the key to passing the lab
is to understand the WHY of using them.
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
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Thomas Larus
> Sent: Sunday, August 29, 2004 5:56 PM
> To: john matijevic; 'Richard Dumoulin'; ccielab@groupstudy.com
> Subject: Re: RE : Cisco Press Routing and Switchling Lab book
>
> John and Richard:
>
> Having the broadcast keyword at the end of all of your frame relay map
> statements is "bad form," but it is not necessarily a bad thing,
> altogether.
>
> Richard was one of the technical reviewers for my new book, along with
Joe
> Rothstein, and you can imagine how helpful it was for these two
network
> engineers to work through the scenarios with their keen eye for
detail.
> Both Richard and Joe noticed that I had used "broadcast" where it was
not
> needed, and since they both mentioned this, I improved my config files
by
> removing "broadcast" where it was not needed. Thus, I confess to
being
> one
> of those practice scenario writers who, left to his own devices, would
put
> "broadcast" on frame relay map statements where it is not needed, and
> would
> also engage in many other acts of "overconfiguration." I firmly stand
by
> most of my overconfiguration, but I recongnize that this particular
bit of
> "overconfiguration" or "bad form" can make one look bad.
>
> Still, there is something to to be said for this kind of
> overconfiguration.
> If you do it this way, you do not have to worry about making a mistake
and
> leaving off the broadcast keyword where it is needed. What if you are
> configuring your frame relay cloud in the Lab exam, and you try to be
> careful about putting "broadcast" only where it is needed, but you are
not
> quite careful enough, for you leave it off the DLCI that really needed
it?
> It is very easy to make this sort of mistake, and it is a mistake that
> could
> really cause practical problems.
>
> It does not take much imagination to see how a mistake like this could
> cause
> you to lose many points and much time.
>
> All in all, it may actually be safer to overconfigure, and have
something
> in
> your configs that reeks of "bad form."
>
> I am not a proctor, so I cannot be certain that there might not be a
> downside to this sort of "bad form" or "overconfiguration." Perhaps
some
> picky proctor would look at this sort of overconfiguration and say,
"this
> candidate's use of the 'broadcast' keyword where it is not needed
suggests
> to me that the candidate may not fully understand what is going on
here."
> However, what I have read of Cisco's official word on the Lab exam
> suggests
> that the Lab is graded largely on practical results. Sometimes I
think
> that
> real world "good form" and "best practices" are largely incompatible
with
> the world of CCIE lab preparation.
>
> Best regards,
>
> Tom Larus, CCIE #10,014
> Author of the CCIE Warm-Up e-books from www.ipexpert.com, and also
"Basic
> Cisco Secuirty Exercises for Pix Firewall, IOS Firewall, and Access
> Control
> Server," at http://www.lulu.com/content/59374
>
>
> ----- Original Message -----
> From: "john matijevic" <matijevi@bellsouth.net>
> To: "'Richard Dumoulin'" <Richard.Dumoulin@vanco.fr>;
> <ccielab@groupstudy.com>
> Sent: Sunday, August 29, 2004 1:26 PM
> Subject: RE: RE : Cisco Press Routing and Switchling Lab book
>
>
> > Hello Richard,
> > I have configured with and without the broadcast keyword as you have
> > mentioned. I really have not noticed a difference. One could argue
that
> > it uses unnecessary bandwidth in the real world. However, there are
> > many lab vendor books that due use the broadcast keyword. The point
> > being is that this book has so many valuable tools and lessons
learned.
> > I think by going through the labs and going through the entire book,
you
> > will find that it is of the highest quality. There are other minor
> > errors with the book, I was just making overall assessment when I
posted
> > this email. Again, I really love this book. I think it is the best
> > resource available, and if you need rack time I am offering my rack
and
> > forum area for support.
> >
> > Sincerely,
> >
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > CEO
> > IgorTek Inc.
> > 151 Crandon Blvd. #402
> > Key Biscayne, FL 33149
> > Hablo Espanol
> > 305-321-6232
> > http://home.bellsouth.net/p/PWP-CCIE
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> > Richard Dumoulin
> > Sent: Sunday, August 29, 2004 5:52 AM
> > To: john matijevic; ccielab@groupstudy.com
> > Subject: RE : Cisco Press Routing and Switchling Lab book
> >
> > One thing I have noticed is that the author configure "broadcast" in
the
> > frame-relay map's between spokes in a frame-relay hub and spoke
> > scenario.
> > I am not sure this is good practice and we all know that broadcasts
are
> > not
> > forwarded by the hub and it therefore does not make sense,
> >
> > --Richard
> >
> >
> >
**********************************************************************
> > Any opinions expressed in the email are those of the individual and
not
> > necessarily the company. This email and any files transmitted with
it
> > are confidential and solely for the use of the intended recipient.
If
> > you are not the intended recipient or the person responsible for
> > delivering it to the intended recipient, be advised that you have
> > received this email in error and that any dissemination,
distribution,
> > copying or use is strictly prohibited.
> >
> > If you have received this email in error, or if you are concerned
with
> > the content of this email please e-mail to:
> > e-security.support@vanco.info
> >
> > The contents of an attachment to this e-mail may contain software
> > viruses which could damage your own computer system. While the
sender
> > has taken every reasonable precaution to minimise this risk, we
cannot
> > accept liability for any damage which you sustain as a result of
> > software viruses. You should carry out your own virus checks before
> > opening any attachments to this e-mail.
> >
**********************************************************************
> >
> >
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:50 GMT-3