Home page logo

nanog logo nanog mailing list archives

RE: Common operational misconceptions
From: "Kenneth M. Chipps Ph.D." <chipps () chipps com>
Date: Fri, 17 Feb 2012 12:43:24 -0600

Exactly right. They have some much information floating around in their
heads many of them cannot fit it together. But once they get on the job, all
of those little synapses rapidly connect, and then the light comes on.

Higher education is just like drivers education. You did not learn to drive
in drivers education. You learned how to drive by driving. Higher education
gives you the foundation on which to learn.

-----Original Message-----
From: Paul Graydon [mailto:paul () paulgraydon co uk] 
Sent: Friday, February 17, 2012 12:33 PM
To: nanog () nanog org
Subject: Re: Common operational misconceptions

On 02/17/2012 04:29 AM, Leo Bicknell wrote:
In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
Graydon wrote:
At the same time, it's shocking how many network people I come across 
with no real grasp of even what OSI means by each layer, even if it's 
only in theory.  Just having a grasp of that makes all the world of 
difference when it comes to troubleshooting.  Start at layer 1 and 
work upwards (unless you're able to make appropriate intuitive 
leaps.) Is it physically connected? Are the link lights flashing? Can 
traffic route to it, etc. etc.
I wouldn't call it a "misconception", but I want to echo Paul's 
comment.  I would venture over 90% of the engineers I work with have 
no idea how to troubleshoot properly.  Thinking back to my own 
education, I don't recall anyone in highschool or college attempting 
to teach troubleshooting skills.  Most classes teach you how to build 
things, not deal with them when they are broken.
The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
troubleshooting.  Not sure if they still do, or if trainers even bother to
mention it (mine did back when I did it several years ago)

The basic skills are probably obvious to someone who might design 
course material if they sat down and thought about how to teach 
troubleshooting.  However, there is one area that may not be obvious.
There's also a group management problem.  Many times troubleshooting 
is done with multiple folks on the phone (say, customer, ISP and 
vendor).  Not only do you have to know how to troubleshoot, but how to 
get everyone on the same page so every possible cause isn't tested 3 
Never trust what you can't prove yourself, that includes vendors and
customers.  Every now and then I forget this and find hours later that I've
wasted a whole bunch of time because I trusted when someone said something
that it actually was the case.  It's really often better to test something a
third time even if Vendor and Customer tell you something is a particular

I think all college level courses should include a "break/fix"
exercise/module after learning how to build something, and much of 
that should be done in a group enviornment.

Definitely.  I've learnt more in my time from breaking things than I've ever
learnt setting them up; however the education system is focused on breadth
of knowledge, not depth.  Students are expected to be able to regurgitate
ridiculous amounts of facts and figures, so that they pass standardised
tests, not understand how to actually use them.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]