I've always believed that you need to teach your students (more so if they are engineers) how things work, so they'll be able to understand why they do things they way they do them. It seems to me, though, that the training courses I'm seeing veer ever more toward overviews and recipes ... but there are a few things you can do on your own.

When I was teaching an advanced OSPF course more than a decade ago, I tried to cover the procedures used by OSPF in as much detail as time allowed, hoping that students would catch the “spirit” of OSPF. Those who were willing to invest their mental energy during the three-day course (instead of answering phone calls, reading their e-mail or dropping out of class to attend “urgent” meetings) were rewarded with an in-depth understanding of OSPF, which allowed them to predict how OSPF would work in large networks, what network designs were good (or bad) and what could be done when things went the wrong way.

But there were always a few students who were looking for quick “recipes,” asking questions like “How many areas can you have on a single router?” My initial answer was always “It depends,” and then I would try to explain that the number of areas a router can support depends on (among other things) the speed of its CPU, the size of each area, the stability of the areas and the load placed on the router (assuming that it wasn’t a distributed platform). The students who were really trying to understand OSPF pretty quickly grasped these ideas, but the recipe seekers were (obviously) not happy until I had served them the canned answer provided by some Cisco document. (The “correct” answer in those days was “three,” in case you didn’t know.) The next obvious question was “How many routers can you have in an area?” – by which time I usually sighed and answered “Fifty.”

I wasn’t worried then about a minority of students seeking an easy way out, but it’s my impression that the industry as a whole is now following the same path. More and more often we teach people how to configure the boxes, without telling them how the boxes work or why we configure them the way we do. While it’s true that you don’t always need in-depth knowledge (for example, you don’t need to know how the motor or the brakes work in order to drive a car), our audience is rarely the end user (who doesn’t care what a network is anyway), but rather the engineers – who should be able to design, deploy and troubleshoot networks. And a good mechanic obviously benefits from knowing how brakes work, if he’s going to try to fix them.

So what can you do? When attending classroom training, always ask the “why” questions; for example, “Why do we configure the box the way we do?” If the instructor doesn’t give you a good answer, switch to a different training company the next time you attend a course. Instructors should know why things work the way they do. Read books. A lot of Cisco Press books cover the technology basics and in-depth details as well as box configuration. Read RFC standards. Most of them are well written and not difficult to read. Ask questions. Many experts are willing to answer interesting questions that show that the people asking them were involved in some prior mental process. And last but not least, experiment. Try to figure out how things work.