My approach is to teach methodology. Design and troubleshooting scenarios and books can't teach every solution to every problem that might come up. They would be ridiculously long, for one thing, but also, it's impossible to predict what problem will come up. There's an infinite number of them.
Hence, I think it's best to focus on helping the reader develop skills to do design and troubleshooting for the problems he or she may run into. Teach methods and best practices. Help the reader develop a fundamental understanding of how networks and protocols really work, why they work the way they do, and the typical reasons that they fail, but don't try to answer every question. Some books try to give "cookbook" answers to questions, especially in the troubleshooting arena. But then you end up with silly things like Symptom: computer can't communicate on network Action: replace the cable Action: replace the NIC Action: check the configuration DUH! ;-) Although I know some people like that kind of thing, I think it's better to teach generic troubleshooting methods. Even a method as simple as "apply the OSI model from the bottom up" is a good start. Just my Friday-night tangential $0.00000010. Priscilla At 08:24 PM 4/19/02, Howard C. Berkowitz wrote: >At 7:10 PM -0400 4/19/02, Kevin Cullimore wrote: > >I'm pretty far away from the "purchasing lab scenarios or the time to > >practice them" point(so many printed words, only one lifetime), but one > >frustrating theme permeating all of the vendor-endorsed training I've been > >forced to attend (note: it was always the case that I would ask for training > >during my first 6-12 months of exposure to a technology, get denied, and > >then be required to attend the lowest possible level training a year later), > >is that they offer one or two solutions to a given troubleshooting/design > >problem. While they might come up with some acceptable reasons for their > >solution, wouldn't it be better to provide scenarios where multiple > >solutions exist for a given set of base requirements and the solutions > >manual outlines all acceptable options, comparing & contrasting them with > >one another, highlighting the merits of solutions that go above & beyond the > >original motives according to generally accepted principles of network > >design? > >Unfortunately, there's a problem in network design training. No one >vendor, even Cisco, makes every kind of component that could be >relevant to a solution. We've all seen posts here that really turned >out to be a Windows problem with a Windows solution, or perhaps could >be done most efficiently with a smart DSU rather than IP load >sharing, etc. > >To get this kind of broad view, you tend to be looking at books or >vendor-independent training. There are several ways to approach this. >I just pulled off my shelf "High Availability Networking with Cisco" >by Vincent C. Jones. The title is slightly misleading, but it's a >good book, because he does get into things such as power supply >issues and how several server vendors handle multiple NICs for >avoiding single points of failure. > >In my book, "WAN Survival Guide," I chose to be generally vendor >independent, and did things like showing how some reliability >problems might better be solved by adding server clusters than >continuing to increase network reliability. One of the case studies >is derived from a consulting client of mine who demanded they NEVER >lose Internet connectivity, so I designed redundant routers, hooked >to an AT&T dual ring SONET, and to another carrier with an MCI >upstream, reached over a different physical facility. > >Unfortunately, when I visited their computer room, I found out they >had one server. When I inquired what they would do if that went down >while the network stayed up, they cheerfully responded, "oh, we have >it backed up on tape." This really should have been one of those >commercials that said "Backup server, $20,000. Look on the client's >face when they realize their vulnerability, priceless. For everything >else, there's Mastercard." > >In my upcoming "Building Service Provider Networks," I go through a >variety of customer case studies. I picked the customers so they >would have different requirements and thus different solutions, but >in the discussion, I would point out alternatives. > >Unfortunately, publishers are finding people are only buying design >books related to security, and essentially certification cram books. >There's not nearly the market for design seminars as there was five >years ago. I suppose the new generation of CEOs is concerned with >getting the wrong answer quickly. >-- >"What Problem are you trying to solve?" >***send Cisco questions to the list, so all can benefit -- not >directly to me*** >******************************************************************************** >Howard C. Berkowitz [EMAIL PROTECTED] >Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com >Technical Director, CertificationZone.com http://www.certificationzone.com >"retired" Certified Cisco Systems Instructor (CID) #93005 > ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42048&t=41955 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
