Mailing List Archive

On Fri, 17 Feb 2012 10:49:13 PST, Owen DeLong said:
> Now, come on... If you're in the 40-50 range, you should have put octal
> before hex. :p

IBM S/360 definitely preferred hex. And EBCDIC.

I give I give. I should have. But I left a bunch of stuff out and the
folks that I'm referring to know it. One of the fun things I do with
network guys is ask them about canonical bit ordering across routers.
Always causes the room to go quiet. Them someone of the appropriate age
group will speak up after he's done laughing.

The best thing I have ever figured out to tell less experienced (I
didn't say younger) folks is to start at the bottom of the stack and
work your way up. That's the way many of us troubleshoot. Is the cable
on the floor? That's bad. If not, is the ARP entry incomplete? That's
bad. If not, is the route missing? That's bad. If not, can you reach the
route? Try this radical command that was invented by Steve Jobs while
working on his first IPhone (They won't know who Vint Cerf or anyone
else is and by using Steves name they will trust you)(I run Android):
telnet 1.2.3.4 1433
What? It answered? So the SQL service is running? Then it ain't the
network dude....
So many times people don't pick up on that. But when they do, it's like
a light bulb went off and they see the world differently. Like
subnetting....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 12:49 PM, Owen DeLong wrote:
> 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.
>>>>
>

Well put and great example Owen.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 12:59 PM, Owen DeLong wrote:
> This reminds me of what I think is the biggest root misconception of the 20th and 21st centuries:
>
> Rapid step-by-step training can replace conceptual education on the fundamentals.
>
> In other words, we have moved from the old-school of teaching people why things work and how they work to a newer school of teaching people how to complete specific tasks. This has had the following negative effects, IMHO:
>
> 1. When the only tool you have is a hammer, you try to mold every problem into a nail.
> 2. When you only know a procedure for doing something and don't understand the fundamentals
> of why X is supposed to occur at step Y, then when you get result A instead of X, your only options
> are to either continue to step Z and hope everything turns out OK, or, go back to an earlier step
> and hope everything works this time.
> 3. Troubleshooting skills are limited to knowing the number of the vendor's help desk.
>
> I once worked with a director of QA that epitomized this. It was a small company, so, as director, he was directly responsible for most of the tasks in the QA lab. He was meticulous in following directions which was a good thing. However, when he reached a step where he did not get the expected result, he was limited to telling the engineers that the test failed at step X and would not make any effort to identify or resolve the problem and would literally block the entire QA process waiting for engineering to resolve the issue before he would continue testing. Worse, he would not test independent pieces of the system in parallel, so, when he blocked on one system failing, he wouldn't test the others, either. Further investigation revealed that this was because he didn't actually know which systems were or were not dependent on each other. He was so completely immersed in the procedural school of thought that he was literally unwilling to accept conceptual knowledge or develop an understanding of the theory and principles of operation of any of the systems.
>
> Owen
>
> On Feb 17, 2012, at 8:13 AM, Mario Eirea wrote:
>
>> 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
>>
>

I find a lot of new folks have a hard time with the difference in
port numbers and protocol numbers.

I just went through this with a CC<something-more-than NA>, but with
virtually no hands-on experience a few minutes ago. Very disturbing
when a person can take the higher level tests, but still can't
understand the basics. All they do is use the certification testing
programs and memorize everything they can. :-(


grrr....
scott

> From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Fri Feb 17 13:11:28 2012
> To: Owen DeLong <owen@delong.com>
> Subject: Re: Common operational misconceptions
> From: Valdis.Kletnieks@vt.edu
> Date: Fri, 17 Feb 2012 14:04:45 -0500
> Cc: "nanog@nanog.org" <nanog@nanog.org>
>
> On Fri, 17 Feb 2012 10:49:13 PST, Owen DeLong said:
> > Now, come on... If you're in the 40-50 range, you should have put octal
> > before hex. :p
>
> IBM S/360 definitely preferred hex. And EBCDIC.

And the _real_ number crunchers used ones-complement arithmetic. Which led to
to mahines that couldn't add -- they did addition by 'complement and subtract'.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2/17/12 11:04 AM, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 17 Feb 2012 10:49:13 PST, Owen DeLong said:
>> Now, come on... If you're in the 40-50 range, you should have put octal before hex. :p
>
> IBM S/360 definitely preferred hex. And EBCDIC.
>

GCOS - 36 bits and Octal and BCD (ASCII added later)
DEC 10 and 20 - 36 bits and Octal
PDP-8 - Octal

- --tep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREDAAYFAk8+qEEACgkQPu53fhcIEuBr9gCfU46kCDPbmgSVQGAw5nnOsrNO
hJ4AnRpr4Ig46x5JZlcK+kL43JGFcbCS
=cSWb
-----END PGP SIGNATURE-----

Owen DeLong <owen@delong.com> writes:

> 1. When the only tool you have is a hammer, you try to mold every problem into a nail.

Ack.

> 2. When you only know a procedure for doing something and don't understand the fundamentals
> of why X is supposed to occur at step Y, then when you get result A instead of X, your only options
> are to either continue to step Z and hope everything turns out OK, or, go back to an earlier step
> and hope everything works this time.

But procedures are important. How else can you get enough exper^Widiots
working for little money. "Big Macs vs. The Naked Chef" is great:

http://www.joelonsoftware.com/articles/fog0000000024.html


> 3. Troubleshooting skills are limited to knowing the number of the vendor's help desk.

There are no problems! Can't be. And if there are they hire external
experts. BTDT. Those are well paid jobs.

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------

> missing? That's bad. If not, can you reach the route? Try this radical
> command that was invented by Steve Jobs while working on his first IPhone
> (They won't know who Vint Cerf or anyone else is and by using Steves name
> they will trust you)(I run Android):
> telnet 1.2.3.4 1433
> What? It answered? So the SQL service is running? Then it ain't the network
> dude....

steve jobs knew how to operate a computer?

the guy that renamed apple computer to "apple" :P

i thought he just knew how to come up with overheating cases and shiney
designs to put -around- the computers (well until the chips fell out of
their sockets due to the heat or they caught fire :P they had woz for the
computer stuff remember :P

the guy that first turned a perfectly open computer platform
manufacturer capable of keeping the ibm pc out of the market
for many decades to come into a gadget for the managers desk,
and then came back to turn a unix workstation manufacturer into an
electronics toys (iphones) company.

the question is: where would apple have been all those years, if steve
jobs wasn't around to screw it up every time :P

(and where are the BMCs in their mac-mini "servers" ;)

2 video chips.. but no bmc..hmm.

> > 3. Troubleshooting skills are limited to knowing the number of the
> vendor's help desk.
>
> There are no problems! Can't be. And if there are they hire external
> experts. BTDT. Those are well paid jobs.

I see that a lot and there is often an organizational reason for it. If a tech says "I have a ticket open with the vendor" and provides the ticket and status updates on a regular basis, he's covered as far as the people higher up in the organization are concerned. If the C(X)O wants to know what's going on, the manager can shift the focus to the vendor and say we are waiting for a fix from them.

A tech trying to troubleshoot it and fix it themselves is going to be hounded every five minutes for status updates and won't be able to get any work done because every five minutes (I kid you not, I have worked where that is a requirement) he has to pull his head out of what he is doing and answer a bunch of questions from the PHBs. And you always get "how long is it going to be" and you want to say "10 minutes longer than it would have been if you hadn't interrupted me" but you bite your tongue.

On Fri, Feb 17, 2012 at 19:18, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
....
> And the  _real_ number crunchers used ones-complement arithmetic.

Not to mention 0 had a sign (and 0 did not compare
as equal to -0).

> A tech trying to troubleshoot it and fix it themselves is going to be
> hounded every five minutes for status updates and won't be able to get
> any work done because every five minutes (I kid you not, I have worked
> where that is a requirement) he has to pull his head out of what he is
> doing and answer a bunch of questions from the PHBs. And you always
> get "how long is it going to be" and you want to say "10 minutes longer
> than it would have been if you hadn't interrupted me" but you bite your
> tongue.
>

Though the flip side of that is that if someone has been neck deep in a problem for hours, you should force them to take a break, go get a drink of water, step outside for fresh air or a smoke if they do, or just talk to a colleague for a moment and review the problem. In my case, the stepping away for a few minutes has sometimes allowed the answer to the problem to suddenly snap into focus or in the process of describing it to someone else the forming of the thoughts to describe it often allows a new aspect of the problem to become visible that you hadn't noticed before.

As someone who was born in 1984 I respectfully disagree. ;-)




On Fri, Feb 17, 2012 at 9:52 AM, -Hammer- <bhmccie@gmail.com> wrote:
> 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.
>>
>



--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

I have found that the best solution to persistent hounding goes about like this:

"Sir, I'm doing everything I can to resolve the problem as quickly as possible. However, I can focus on giving you status updates every 5 minutes, or, I can focus on resolving the problem. I cannot do both. which would you prefer?"

As to the internal vs. external question, most organizations I've worked for have just wanted the problem solved. They didn't so much care whether I was taking a lot of time to solve it or the vendor was taking a lot of time to respond to me, they wanted the problem fixed and I was the one they could fire.

As such, it was in my interest to usually learn most of the systems better than the tech support folk at the other end of the phone.

YMMV

Owen

On Feb 17, 2012, at 11:35 AM, George Bonser wrote:

>> A tech trying to troubleshoot it and fix it themselves is going to be
>> hounded every five minutes for status updates and won't be able to get
>> any work done because every five minutes (I kid you not, I have worked
>> where that is a requirement) he has to pull his head out of what he is
>> doing and answer a bunch of questions from the PHBs. And you always
>> get "how long is it going to be" and you want to say "10 minutes longer
>> than it would have been if you hadn't interrupted me" but you bite your
>> tongue.
>>
>
> Though the flip side of that is that if someone has been neck deep in a problem for hours, you should force them to take a break, go get a drink of water, step outside for fresh air or a smoke if they do, or just talk to a colleague for a moment and review the problem. In my case, the stepping away for a few minutes has sometimes allowed the answer to the problem to suddenly snap into focus or in the process of describing it to someone else the forming of the thoughts to describe it often allows a new aspect of the problem to become visible that you hadn't noticed before.
>
>

> GCOS - 36 bits and Octal and BCD (ASCII added later)
> DEC 10 and 20 - 36 bits and Octal
> PDP-8 - Octal

704 - was i think 36-bit but the mind fades
704x/709x - 36 bit
1401 - variable word length with BCD+zone-bit encoding per char

randy

On Friday, February 17, 2012 01:30:30 AM Carsten Bormann wrote:
> Ah, one of the greatest misconceptions still around in 2012:

> -- OSI Layer numbers mean something.
> or
> -- Somewhere in the sky, there is an exact definition of what is layer 2, layer 3, layer 4, layer 5 (!), layer 7

Misconception: Layers are not recursive.

Thanks to tunneling/MPLS/other encapsulation techniques, they are.

as a 33 year old, I'm looking forward to hitting 35 so I can finally
understand what you guys are talking about! Will I get some sort of glow
or achievement?

think I'll get a raise when I can add 'troubleshooting' to my resume? :)

On Fri, Feb 17, 2012 at 2:42 PM, Ray Soucy <rps@maine.edu> wrote:

> As someone who was born in 1984 I respectfully disagree. ;-)
>
>
>
>
> On Fri, Feb 17, 2012 at 9:52 AM, -Hammer- <bhmccie@gmail.com> wrote:
> > 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.
> >>
> >
>
>
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
>
>

I just pulled the humorous point about Mary the accountant out, pasted its link into an email and sent it to our staff with the suggestion they read it. I was going to past it here but decided to let someone who wants to read it go to the site, they may learn something by accident if they do.

I have been unable to get our group to read anything else, maybe they will read this very well written document. It really is a "comm oriented" Cliff Notes of Kepner Trego Problem Analysis. I would love them to read the text book, but will settle for anything.


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: Marcel Plug [mailto:marcelplug@gmail.com]
Sent: Friday, February 17, 2012 12:01 PM
To: -Hammer-
Cc: nanog@nanog.org
Subject: Re: Common operational misconceptions

I often struggle with the concept of teaching someone how to
troubleshoot. We have young guys coming in all the time and it is
often an area in which they need to hone their skills. I found this
article a while back and I keep it bookmarked, its the best article
I've seen that lays it all out pretty clearly.

http://packetlife.net/blog/2010/mar/10/the-science-of-network-troubleshooting/

-Marcel

I'm guessing, but I believe the author would fall into the under 35 category ;-)

On Fri, Feb 17, 2012 at 10:51 AM, -Hammer- <bhmccie@gmail.com> 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.
>>>
>>
>

On Fri, Feb 17, 2012 at 18:06, George Bonser <gbonser@seven.com> wrote:
....
> Fry's wanted $55 for a 1 meter LC-LC multi-mode patch cord yesterday at the store on Arques in Sunnyvale.

Admittedly high, but in the same store, one set of rows to the
left (as you were looking at the fibres) they sell 12-24 rack
screws for something like $10/bag of 12. Now *that* is
markup.

Still buzzing over that cheap auto insurance eh? :) Wait till people
stop carding you.....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 1:42 PM, Ray Soucy wrote:
> As someone who was born in 1984 I respectfully disagree. ;-)
>
>
>
>
> On Fri, Feb 17, 2012 at 9:52 AM, -Hammer-<bhmccie@gmail.com> wrote:
>> 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.
>>>
>
>

Maybe ;-)

I don't think it's an age thing, though.

The number of people who have a real interest in technology, and how
things work "under the hood" hasn't changed much. I know people 10
years younger than me who can keep up with the best of us, and people
10 years older who are complete failures at technology. People like
us have always been a fairly small number.

What has changed, though, is that there are a lot more young people
who think they have technology skills; perhaps as a side effect of
growing up in a world where the Internet has always been there.
Naturally, we have a lot of people filling IT spots that aren't
qualified and lack the basic knowledge of how complex systems are
built. To troubleshoot effectively, you need to be able to break
down systems into their components and isolate the problem; and a lot
of people just don't have the background to be able to do that because
they never cared to do so. It's just a paycheck to them.

Those of us in my age group were lucky enough to be around for the
transition from dial-up BBS, to dial-up Internet, to broadband. As a
networking geek I don't think I could ask for a better year to be
born, really. It's always been exciting.

These days I'm playing with DWDM and a state wide R&E network in a
state that established dark fiber as a public utility; doesn't get
much better than that.

I'd say the future is pretty bright. ;-)




On Fri, Feb 17, 2012 at 3:26 PM, -Hammer- <bhmccie@gmail.com> wrote:
> Still buzzing over that cheap auto insurance eh? :) Wait till people stop
> carding you.....
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 1:42 PM, Ray Soucy wrote:
>>
>> As someone who was born in 1984 I respectfully disagree. ;-)
>>
>>
>>
>>
>> On Fri, Feb 17, 2012 at 9:52 AM, -Hammer-<bhmccie@gmail.com>  wrote:
>>>
>>> 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.
>>>>
>>
>>
>



--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

On Feb 17, 2012, at 1:35 PM, Owen DeLong wrote:
> On Feb 17, 2012, at 6:52 AM, -Hammer- wrote:
>
>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>>
> Is this a statement or something to be added to the list of misconceptions that are commonplace out there?
>
> Not trying to be flip... Honestly asking the question. I can see it going either way, frankly. ;-)
>
> Owen



Clearly, it is a misconception.

The effect of aging on trouble-shooting skills is simply the opportunity for gaining experience.

(Personal anecdotes omitted here. You are welcome.)


James R. Cutler
james.cutler@consultant.com

I couldn't argue with any of that. Again, there are exceptions on either
side.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 2:40 PM, Ray Soucy wrote:
> Maybe ;-)
>
> I don't think it's an age thing, though.
>
> The number of people who have a real interest in technology, and how
> things work "under the hood" hasn't changed much. I know people 10
> years younger than me who can keep up with the best of us, and people
> 10 years older who are complete failures at technology. People like
> us have always been a fairly small number.
>
> What has changed, though, is that there are a lot more young people
> who think they have technology skills; perhaps as a side effect of
> growing up in a world where the Internet has always been there.
> Naturally, we have a lot of people filling IT spots that aren't
> qualified and lack the basic knowledge of how complex systems are
> built. To troubleshoot effectively, you need to be able to break
> down systems into their components and isolate the problem; and a lot
> of people just don't have the background to be able to do that because
> they never cared to do so. It's just a paycheck to them.
>
> Those of us in my age group were lucky enough to be around for the
> transition from dial-up BBS, to dial-up Internet, to broadband. As a
> networking geek I don't think I could ask for a better year to be
> born, really. It's always been exciting.
>
> These days I'm playing with DWDM and a state wide R&E network in a
> state that established dark fiber as a public utility; doesn't get
> much better than that.
>
> I'd say the future is pretty bright. ;-)
>
>
>
>
> On Fri, Feb 17, 2012 at 3:26 PM, -Hammer-<bhmccie@gmail.com> wrote:
>> Still buzzing over that cheap auto insurance eh? :) Wait till people stop
>> carding you.....
>>
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 2/17/2012 1:42 PM, Ray Soucy wrote:
>>> As someone who was born in 1984 I respectfully disagree. ;-)
>>>
>>>
>>>
>>>
>>> On Fri, Feb 17, 2012 at 9:52 AM, -Hammer-<bhmccie@gmail.com> wrote:
>>>> 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.
>>>>>
>>>
>
>

When I bring up Linux ISOs to the believers of this misconception,
they generally argue that Linux ISOs can be obtained without
BitTorrent as well so blocking BT is okay. But I believe it is up to
the user to decide which protocol to use to obtain the data and if the
user wants to use BT but the network prevents this, the network is at
fault.

Other valid uses of BitTorrent include content intentionally
distributed via BT for free by Hollywood studios, television
broadcasters, and artists of Creative Commons works. There's also
Blizzard patches and other game patches. Some companies like Twitter
apparently use BitTorrent internally (https://github.com/lg/murder).

Quoting Jay Ashworth <jra@baylink.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

On Feb 17, 2012, at 11:04 AM, Valdis.Kletnieks@vt.edu wrote:

> On Fri, 17 Feb 2012 10:49:13 PST, Owen DeLong said:
>> Now, come on... If you're in the 40-50 range, you should have put octal
>> before hex. :p
>
> IBM S/360 definitely preferred hex. And EBCDIC.
>

Strictly an artifact of it's EBCDIC nature, as a matter of fact...

The BCD in EBCDIC stands for Binary Coded Decimal which inherently
requires Hex.

In fact, if you compare punched cards to EBCDIC, you'll find some remarkable
similarities...

For example C1 (12 1) is A (Hollerith A is a 12 punch plus a 1 punch).

Owen

On Wed, Feb 15, 2012 at 4:52 PM, Rich Kulawiec <rsk@gsp.org> wrote:
> ICMP is evil.
To that I would add under...
Security misconceptions
0. Security is just common sense.
a. More draconian/more complicated policies/practices
automatically result in a good
secure, usable environment.
i. For secure results, require users to set a
25-character complex password with 1-day
expire.
ii. For best results, get a checklist containing every
possible "security measure" that
can be implemented, and implement them in no particular order.
iii. For best results, ask a committee of accomplished
bureaucrats....

b. For best results, leave all settings at their default values.
i. A security focused analysis is not required to
design a secure system/network.
ii. If each device is secure, the overall system is
automatically secure.

c. Just install Product $X, Product $Y. Everything will be fine.
d. If that doesn't work, and we still get a security breach,
adding Product $Z will
definitely make it secure forever, without log checking
and security reviews.
e. A simple automated scan can detect all possible security issues.

1. Script kiddies don't want access to my router, because they
can't run malware
i. Routers always encrypt passwords in memory; the *s
displayed when you look at the password field in the webui prove it;
no worries throwing out old equipment.
ii. It's okay to re-use the admin password for a POP3 account,
no security risk there.

2. If your organization partitions its internal network from the
internet with a firewall....
a. The network will be invincible to attack. or
i. Private addressing ensures a LAN secure against
outside attack.
ii. SSL certificates don't matter, just click Continue.

b. Sources of possible abuse/intrusion will always be on
the outside. [or]
i. The perimeter firewall makes the LAN safe against
packet sniffers
ii. Use of Ethernet switches instead of hubs make the
LAN completely safe against packet sniffers.
iii. Managing local LAN devices (such as routers)
using telnet or plain HTTP
is safe and secure (because of i or ii).

iv. Plain e-mail is an excellent file transfer
protocol -- it's also a secure way to
transfer large files into or out of a
Firewall-secured LAN, since e-mail is private.

v. External USB drives are a safe, secure, convenient
way to bring data into
or out of the partitioned network. Antivirus
will thwart any attempt to
transfer malicious files of any type.

vi. FTP is a safe way to bring data into or out of a
secure network, and the data
is safe against interception because a password is
required to connect.

c. The one perimeter firewall will protect the network
against internal attacks,
and even outsiders gaining access to open wifi.
i. WEP or open access with MAC address filtering is
pretty secure.
ii. MAC address filtering on the core router will make
sure unauthorized devices
plugged in cannot possibly gain access to the LAN.
iii. MAC address filtering on the DHCP server will make
sure unauthorized devices
plugged in cannot possibly gain access to the LAN.

d. No need to worry about having a DMZ or separate network,
for hosting internet services behind a firewall.
i. If traffic is only allowed to port 80, shell
access cannot be obtained by exploit,
even if the PHP scripts have bugs, because port 23
is required for shell access.
ii. If traffic from the internet is alllowed to pass
to one host through a firewall,
any possible security risk is limited to
exclusively that one host.









> Firewalls will solve our security issues.
> Antivirus will solve our security issues.
...

$MAGIC_PRODUCT will solve our security issues.
For many different values of $MAGIC_PRODUCT
--
-JH