What I mean by not providing knowledge is the how to? and Why? They actually made a good effort, two CCIE's reviewed the book and one CCNP. So the technical expertise was there. In the case of this book was the failure to teach opposed to here are the answers MEMORIZE THEM, when you encounter the problem in your netowork GET THE ANSWERS FROM YOUR MEMORY. This method doesn't work because under intense pressure, your mind doesn't think of simple things(It does around 3a.m. in the morning, mainly because this is when your mind files things during the day into it's filing cabinet, referred to as REM sleep) As a memory expert, I can tell you troubleshooting is not a memory sport. The whole key is understanding the technology, learn the protocols, how the protocols interact with certain equipment. Shortly after reading this book, I purchased "Cisco Internetwork Troubleshooting" author: Laura Chappell. This book also had two CCIE's review the book Dan Farkas CCIE #3800 and Henry Benjamin. Laura has Novell background with over 15 years of experience, so I would say she qualifies to challenge the CCNP. Here are the sections that really killed the challenger FDDI, ATM, X.25 and overall troubleshooting methodology. Several TCP/IP, Netware, Appletalk, Fast Ethernet, VLAN, and ISDN troubleshooting techniques are discussed. Provides you with the logic used to resolve real life problems experienced every day. If you are reading this book most likely your aiming for the CCNP and/or CCIE. Believe me the CCIE is more than just book knowledge and hands on experience. It becomes a matter of technique, you are required to keep notes of how you resolved certain problems. So even if you resolve the problem by luck, if you can't explain to the proctor how you did it, and why the points are gone. I don't want to explain the entire book, because I would deprive you of learning, which essentially is what brain dumps do. Sure you may get the job because you eventually got a cert, but let the network go down at a major bank, and you can't resolve the problem(Get the picture). I have seen these type of problems first hand, asked the IS guys what have they attempted so far? (I can tell from the tone in the voice alot of guessing is going on). The last thing you want to happen is you don't have a logical reason for why the network was down the entire weekend! At a major corporation in Los Angeles this happened, as a consultant I witnessed the outsourcing of a entire IS department! My point use the debugging tools, keep good notes, ask the correct questions(especially dealing with TelCo's). To bad we had to waste our money, but at least we got a CD! (I like to think of the glass as being half full)