[150063] in North American Network Operators' Group
Re: Common operational misconceptions
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Feb 17 13:52:22 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4F3E7776.1010405@gmail.com>
Date: Fri, 17 Feb 2012 10:49:13 -0800
To: -Hammer- <bhmccie@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> -Hammer-
>=20
> "I was a normal American nerd"
> -Jack Herer
>=20
>=20
>=20
> 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.
>>=20
>> A short example, probably not the best but the one that comes to mind =
right now:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Mario Eirea
>> ________________________________________
>> From: -Hammer- [bhmccie@gmail.com]
>> Sent: Friday, February 17, 2012 9:52 AM
>> To: nanog@nanog.org
>> Subject: Re: Common operational misconceptions
>>=20
>> Let me simplify that. If you are over 35 you know how to =
troubleshoot.
>>=20
>> Yes, I'm going to get flamed. Yes, there are exceptions in both =
directions.
>>=20
>> -Hammer-
>>=20
>> "I was a normal American nerd"
>> -Jack Herer
>>=20
>>=20
>>=20
>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>=20
