Mailing List Archive

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.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

This list is awesome. Is anyone consolidating it? I'm still catching up
on the thread....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 1:05 AM, Carsten Bormann wrote:
> On Feb 17, 2012, at 07:50, Paul Graydon wrote:
>
>> what OSI means
> Yet another common misconception popping up:
>
> -- You can talk about the OSI model in the present tense
>
> (That said -- yes, it is still useful as a set of simple terms for certain combinations of functions.
> It is also still useful as a way to calibrate your gut feeling of what is going on in a network.
> Just never expect OSI terms to have a precise meaning in today's networks.
> 1978 is now a third of a century ago...
> If you need precision, you need to spell out what you mean in today's terms.)
>
> Grüße, Carsten
>
>
>

Actually I taught in a three year tech program for a while and although
trouble shooting was not in the curriculum, and as far as I know it
isn't anywhere, several of us adjunct faculty did teach it and got
reprimanded for it as part of our classes. So much for the education
industry understanding the needs of business. I taught basic PC
hardware and NT networking at the time. We would actually have the
students assemble a PC and then in a subsequent class bring up a
network. I got pretty good at nailing then with bugs while they were on
breaks. Heck, they had to go out to smoke. They would come back with a
network or PC that was no longer working. I would then have them
explain what they saw, what they thought was wrong, justify it BEFORE
they could take any corrective action. I also used some classroom
scenarios - they could ask me anything that they could physically learn
if they could tell me how they would check that. I let them run bad
rabbit trails if it looked like it would cement the right way. It
taught some step by step processes.

BTW, the best trouble shooting course I have ever taken was the Kepner
Trego Problem Analysis/Decision Analysis class. Caterpillar used it but
I have not seen it run anywhere in years. It is hard-nosed and may not
be glitzy enough for today. If you have a junior tech who isn't getting
there, I suggest - get their book and see if it helps. NO, I do not
sell them or have stock in the company and NO, it will not do any good
unless he reads it. I still use methodologies I learned in the class.


Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt@pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055

-----Original Message-----
From: Leo Bicknell [mailto:bicknell@ufp.org]
Sent: Friday, February 17, 2012 9:29 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

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.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

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.
>

+1

Mario Eirea
________________________________________
From: Leo Bicknell [bicknell@ufp.org]
Sent: Friday, February 17, 2012 9:29 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

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.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

Hammer, you are at least 75% right. You will get flamed and in most
cases, the 35 year age is close to right.

But then in Programming where I spent most of my IT time since Feb 1963,
few current programmers have skills that they need to be really
successful. Same thing.

It is the fault of the educational system like one school district here
that teaches Alice, VB and then two days of C++ to High School Kids.
Heck, they will fiddle with Alice on their own. They need some exposure
to one of the SQL's and how to build some tables, maybe a good script
language, some command line on SQL+ and unix or PostgresSQL and linux if
the school can't afford the unix licenses.

The fun and games is more important than the substance and it goes into
the colleges in spades.

BTW, I am a school board member who votes 1:8 often on things.... But
let me give you a perspective, one of the board members called Golf an
"Essential Life Skill." Maybe, but how about balancing a checkbook...

Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt@pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055


-----Original Message-----
From: -Hammer- [mailto: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.
>

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.
>

On 2/17/2012 1:05 AM, Carsten Bormann wrote:
> On Feb 17, 2012, at 07:50, Paul Graydon wrote:
>
>> what OSI means
>
> Yet another common misconception popping up:
>
> -- You can talk about the OSI model in the present tense
>
> (That said -- yes, it is still useful as a set of simple terms for certain combinations of functions.
> It is also still useful as a way to calibrate your gut feeling of what is going on in a network.
> Just never expect OSI terms to have a precise meaning in today's networks.
> 1978 is now a third of a century ago...
> If you need precision, you need to spell out what you mean in today's terms.)
>

Actually, I find it makes a perfect troubleshooting guideline in today's
world; at least up to layer 4. I'm not saying it's a perfect match to
troubleshooting a variety of MPLS problems, but it is a reminder that
there are dependencies which must be checked.

In dealing with transport companies, the model is still a good
representation of their service levels. It isn't uncommon to find their
products defined as layer 2 services (ranging from tdm/sonet services to
ethernet switching services), layer 3 services (often handled by their
ISP department), and MPLS services (which can range from p2p transport
to l3vpn).

Which brings up my final point. Until we quit naming things l2vpn or
l3vpn, OSI still applies. :P


Jack

I agree with this 100%.

Having worked with many people over the last 40 years, the good trouble shooters understood how things
were suppose to work. This helps immeasurably in determining where to start looking.

On 02/17/2012 10: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.
>>
>
>


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark@netwolves.com
http://www.netwolves.com

>From: Owen DeLong owen@delong.com

>Sigh... NAT is a horrible hack that served us all too well in address conservation. Beyond that, it is merely a source of pain.

I understand why you say that - NAT did yeoman's work in address conservation.  However, it also enabled (yes, really) lots of topologies and approaches which are *not* designed upon the end-to-end model.  Some of these approaches have found their way into business proceses. 

An argument you and others have made many times boils down to "but if we never had NAT, think how much better it would be!" 

To this, the response "so what?" is not unreasonable - organizations which have built up processes and products around the non-end-to-end model may or may not see a benefit in changing their ways.  Asserting that there is something wrong with existing, succesful business practices is not, by itself, compelling. 

While you and I may find this type of packet header manipulation distasteful, there's lots of organizations for which it's normal operations.  The more NAT for v6 gets fought, the more folks will fight to preserve it.  Time could be better spent demonstrating why NAT isn't needed in X or Y use case, and providing configuration snippets / assistance for non-NAT-based solutions to those various groups.

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

----- Original Message -----
> From: "Ridwan Sami" <rms2176@columbia.edu>

> There is no legitimate reason for a user to use BitTorrent (someone
> will probably disagree with this).

Yeah, no.

You've clearly never tried to download a Linux installer DVD.

Cheers,
-- jr 'among dozens of other legitimate uses' a
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

On Feb 17, 2012, at 9:29 AM, -Hammer- wrote:

> This list is awesome. Is anyone consolidating it? I'm still catching up on the thread....


I was thinking of making a checklist out of it.

- Jared

>> There is no legitimate reason for a user to use BitTorrent (someone
>> will probably disagree with this).

There is no democratic basis -for- copy"right", so far for "legitimate".

Well said. An American tragedy.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 9:01 AM, Brandt, Ralph wrote:
> Hammer, you are at least 75% right. You will get flamed and in most
> cases, the 35 year age is close to right.
>
> But then in Programming where I spent most of my IT time since Feb 1963,
> few current programmers have skills that they need to be really
> successful. Same thing.
>
> It is the fault of the educational system like one school district here
> that teaches Alice, VB and then two days of C++ to High School Kids.
> Heck, they will fiddle with Alice on their own. They need some exposure
> to one of the SQL's and how to build some tables, maybe a good script
> language, some command line on SQL+ and unix or PostgresSQL and linux if
> the school can't afford the unix licenses.
>
> The fun and games is more important than the substance and it goes into
> the colleges in spades.
>
> BTW, I am a school board member who votes 1:8 often on things.... But
> let me give you a perspective, one of the board members called Golf an
> "Essential Life Skill." Maybe, but how about balancing a checkbook...
>
> Ralph Brandt
> Communications Engineer
> HP Enterprise Services
> Telephone +1 717.506.0802
> FAX +1 717.506.4358
> Email Ralph.Brandt@pateam.com
> 5095 Ritter Rd
> Mechanicsburg PA 17055
>
>
> -----Original Message-----
> From: -Hammer- [mailto: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.
>>
>

On 2/17/2012 9:18 AM, Steve Clark wrote:
> Having worked with many people over the last 40 years, the good trouble
> shooters understood how things
> were suppose to work. This helps immeasurably in determining where to
> start looking.
>

Ran into this not too long ago with a transport problem. The behavior I
was seeing was indicative of the transport not stripping their outer
tag. They put wireshark on a windows laptop and sent me the traffic
captures. While I didn't know that M$ decided to do something silly like
removing a single tag, all indicators were that the M$ stack "fixed"
whatever was broken prior to wireshark. We took a capture from another
device and proved the problem.

Which is a common transport problem I often see, "Our configuration
looks right, it must be on your end."


Jack

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.
>>
>

If you do, please share it. Thank you.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 9:36 AM, Jared Mauch wrote:
> On Feb 17, 2012, at 9:29 AM, -Hammer- wrote:
>
>> This list is awesome. Is anyone consolidating it? I'm still catching up on the thread....
>
> I was thinking of making a checklist out of it.
>
> - Jared

Original poster who started thread said he would.

On Fri, Feb 17, 2012 at 10:51 AM, -Hammer- <bhmccie@gmail.com> wrote:

> If you do, please share it. Thank you.
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 9:36 AM, Jared Mauch wrote:
>
>> On Feb 17, 2012, at 9:29 AM, -Hammer- wrote:
>>
>> This list is awesome. Is anyone consolidating it? I'm still catching up
>>> on the thread....
>>>
>>
>> I was thinking of making a checklist out of it.
>>
>> - Jared
>>
>
>

On Fri, 17 Feb 2012 08:29:42 -0600
-Hammer- <bhmccie@gmail.com> wrote:

> This list is awesome. Is anyone consolidating it? I'm still catching
> up on the thread....

I'm collecting all responses, many of which have been sent to me off
list. I was waiting for the thread to eventually end before
summarizing it. Thanks everyone.

John

On 2/17/2012 10:04 AM, John Kristoff wrote:
> I was waiting for the thread to eventually end

Greatest misconception of all.


Jack

>
> It depends on how you define "work well".
>
> As the RFC says:
>
> indication of some significantly disruptive event in the network,
> such as a router failure or a routing change to a path with a
> smaller
> MTU.
>
> it can not react against PMTU changes very well.
>
> It is seemingly working well means there is not much PMTU changes,
> which means we had better assumes some PMTU (1280B, for example) and
> use it without PMTUD.
>
> Masataka Ohta

It depends on the OS and the method being used. If you set the option to "2" on Linux, it will do MTU probing constantly and react to MTU changes. Also, the MTU for a given path only "lives" for 5 minutes anyway (by default) and is "rediscovered" with Linux. (value in /proc/sys/net/ipv4/route/mtu_expires) but other operating systems may behave in other ways.

I agree that if one tries hard enough, they can ensure a broken path and there are always people who seem to devote a lot of energy to that end. There's nothing that can be done about them but there is much the OS can try to do to defeat them at their task.

I definitely understand and agree with what you saying. Actually, most my friends are over 50 years old... I do agree with you on the generational statement. My argument was that many people over 35 have no idea what they are doing, and some under 35 do know what they are doing. On thing is for sure, experience goes a long way. The importance is knowing the fundamentals and putting it all together (a skill that has been lost in recent times)

I have a lot to say about the current generation of people growing up in this country, but that's a whole other thread in a whole other list. :-)

Mario Eirea

________________________________________
From: -Hammer- [bhmccie@gmail.com]
Sent: Friday, February 17, 2012 10:51 AM
To: Mario Eirea
Cc: nanog@nanog.org
Subject: Re: Common operational misconceptions

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.
>>
>

On 2/17/2012 10:18 AM, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good
> trouble shooters understood how things
> were suppose to work. This helps immeasurably in determining where to
> start looking.
>

This is dead on and why I always start classes with a refresher on the
OSI model. While the model isn't perfect it lets technicians and
engineers construct a reasonable model of how things *ought* to be
working. While you certainly will run into devices that bend or even
break the rules (sometimes for good reasons) its much easier to
understand the exceptions if you know the normal operation for a
repeater, bridge, or router.

--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Fri, Feb 17, 2012 at 10:33:12AM -0500, Jay Ashworth wrote:
> ----- Original Message -----
> > From: "Ridwan Sami" <rms2176@columbia.edu>
>
> > There is no legitimate reason for a user to use BitTorrent (someone
> > will probably disagree with this).
>
> Yeah, no.
>
> You've clearly never tried to download a Linux installer DVD.

Nevermind that Bram Cohen is preparing to tackle TV with a
BitTorrent-related protocol (no further details known yet).

Sent from my iPhone

On Feb 17, 2012, at 7:48, Jack Bates <jbates@brightok.net> wrote:

>
>
> On 2/17/2012 9:18 AM, Steve Clark wrote:
>> Having worked with many people over the last 40 years, the good trouble
>> shooters understood how things
>> were suppose to work. This helps immeasurably in determining where to
>> start looking.
>>
>
> Ran into this not too long ago with a transport problem. The behavior I was seeing was indicative of the transport not stripping their outer tag. They put wireshark on a windows laptop and sent me the traffic captures. While I didn't know that M$ decided to do something silly like removing a single tag, all indicators were that the M$ stack "fixed" whatever was broken prior to wireshark. We took a capture from another device and proved the problem.
>
> Which is a common transport problem I often see, "Our configuration looks right, it must be on your end."
>
>
> Jack
>


If i had a dollar for everytime i've heard that from a telco, i'd be a
rich man...