Re: Common operational misconceptions

[Owen DeLong <owen () delong com>]

Now, come on... If you're in the 40-50 range, you should have put octal before hex. :p

Owen
(Who grew up on a PDP-11 in his high-school and still remembers 1777300 and its significance to anyone who has used a 
larger PDP system)

On Feb 17, 2012, at 7:51 AM, -Hammer- wrote:

> Mario,
>    I was kinda having fun and kinda not. My point is that the 40-50 year olds that were doing this 30 years ago grew 
> up understanding things in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those confused). Hex. etc. 
> Move on to the OSI model and it's the same thing. Voltage. Amplitude. Binary. etc. I think that this generation that 
> I'm referring to is a great generation because we were at the beginning of the Internet blooming. There are folks on 
> this forum that go back further. Into DARPA. Before DARPA was just chapter 1 one every single Cisco Press book. They 
> have a unique understanding of the layers. I had that understanding in my 20s. The technology is so complicated these 
> days that many folks miss those fundamentals and go right into VSS on the 6500s or MPLS over Juniper. In the end, it 
> all comes in time.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 9:12 AM, Mario Eirea wrote:
> > Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how 
> > the system works. That is, how different things interact with each others to achieve a specific goal. The biggest 
> > problem I see is that many people understand understand the individual parts but when it comes to understanding the 
> > system as a whole they fall miserably short.
> >
> > A short example, probably not the best but the one that comes to mind right now:
> >
> > Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They 
> > don't understand why the router cant communicate with it at first and then starts working. The people "understand" 
> > ARP, but cant correlate one event with another.
> >
> > I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this 
> > problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.
> >
> > Mario Eirea
> > ________________________________________
> > From: -Hammer- [bhmccie () gmail com]
> > Sent: Friday, February 17, 2012 9:52 AM
> > To: nanog () nanog org
> > Subject: Re: Common operational misconceptions
> >
> > Let me simplify that. If you are over 35 you know how to troubleshoot.
> >
> > Yes, I'm going to get flamed. Yes, there are exceptions in both directions.
> >
> > -Hammer-
> >
> > "I was a normal American nerd"
> > -Jack Herer
> >
> >
> >
> > On 2/17/2012 8: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 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 times.
> > >
> > > 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.