Here's one that I run into nightly.  :-)

I usually don't have enough equipment or the right equipment to
practice labs exactly as written so I have to make a lot of
configuration tweaks and additional connections to make it work.  What
often happens is that later in the lab something that ought to work,
doesn't.  After troubleshooting for a while it often ends up being one
of the tweaks I'd made earlier.

The key to this is to really pay attention.  Follow instructions to the
letter, and if you can't, make sure you remember what you changed to
make it work or else it may come back to bite you later.

Another common one, often related to OSPF, is that something that was
working previously stops working after the router is reloaded.

I'll try to think of more.  I need more caffeine first.  

John

>>> "Howard C. Berkowitz"  11/16/01 7:00:28 AM >>>
Jason Carnevale got me thinking that there are a number of ways that 
labs, even more than real-world configurations, go bad.  I'd like to 
start a checklist of such things.

1.  There is no return path for your test signal (e.g., ping,
traceroute).
     Also a common real-world problem.

2.  A given routing scenario appears at first to work, but fails as
routers
     are added.  The real situation was that dynamic routing never
worked
     in the scenario, but you had connectivity through directly
connected
     subnets.

3.  Weird protocol combinations imposed by the limited number of
routers
     in a lab, in which protocols are asked to do things they were not
     designed to do (e.g., IGPs between AS). Multiple levels of
redistribution
     tend to fall into this area.

4.  You do not see expected routes due to completely correct
summarization
     or aggregation.

5.  Classful versus classless interactions.  The real world, at least
as
     defined by the Internet, is classless.

6.  Failure to specific ip subnet-zero.

7.  Attempts to maximize summarization even if you pick up address
ranges
     not intended to be part of the summary

8.  Attempts to minimize the number of lines in a configuration,
leading
     to confusing, error prone access lists, OSPF network
specifications,
     etc.

Additional suggestions are welcome, but try to make them general.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=26478&t=26478
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to