Assumptions about the default behavior of various flavors of IOS. > -----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.
Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=26485&t=26485 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
