These are sort of basic mistakes that I have made or my students have made in a lab environment:
No clock rate command on back-to-back serial link. No frame-relay intf-type dce on back-to-back Frame Relay. No OSPF neighbor command on back-to-back serial link. (Gurus: check this one!?) Assuming Frame Relay Inverse ARP will be on by default, (which it doesn't seem to be for older IOS versions, such as 11.0) Using the other side's DLCI instead of your own in the frame-relay map command. Using your own IP address instead of the other side's in the frame-relay map command. In PPP networks, using the local hostname for the username. Illogical, but a common mistake. Assuming copy start run will replace your running config instead of add to it. Testing access lists with traffic sourced by the router instead of traffic forwarded by the router. There are probably a zillion more, but for some reason I'm drawing a blank now. Good discussion! Priscilla > > -----Original Message----- > > From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] > > Sent: Friday, November 16, 2001 8:00 AM > > To: [EMAIL PROTECTED] > > Subject: How Good Labs go Bad (was RE: A very basic question : BGP > > [7:26470] > > > > > > 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. ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=26523&t=26523 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
