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- [bhmc...@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.
>>> 
>> 


Reply via email to